从Embedding到RRF混合检索密语CipherTalk向量检索引擎的实现与评测recallk/MRR【免费下载链接】CipherTalk查无此人项目地址: https://gitcode.com/gh_mirrors/ci/CipherTalk密语 CipherTalk 是一款现代化的微信聊天记录查看与分析工具它的核心亮点之一是为海量聊天记录构建了向量检索引擎通过 Embedding 模型把聊天片段转成语义向量再与关键词全文检索结合用 RRF倒数排名融合混合检索找出聊过类似话题的记录并配套一套 recallk / MRR 评测体系来量化该召回的消息片段有没有被召回。本文带你完整走一遍这条链路从片段切分、向量存储、RRF 融合到评测指标的设计思路不需要你有任何向量数据库背景。一、为什么聊天记录搜索需要向量检索你一定有过这种经历想找回他上次答应我什么事情但在搜索框里怎么都敲不出合适的关键词。问题出在微信消息本身——又碎又短。单条消息往往只有几个字语义非常稀薄而真正有信息量的是连续多轮对话这个上下文。如果只对单条消息做关键词匹配或单条嵌入跨多轮的话题根本召不回。CipherTalk 的解法是把嵌入的粒度从单条消息升级为会话片段chunk把连续消息按三个条件切成一段任一条件触发就断开buildChunks 实现字符预算单个片段合并文本不超过 600 字符切分常量定义最大条数一个片段最多容纳 15 条消息时间间隔相邻消息间隔超过 20 分钟视为新一段对话这样每个片段既包含多轮上下文又不至于长到把向量语义稀释掉。切分时还会记录片段的startSortSeq/endSortSeq区间和锚点消息片段中点后面混合检索去重和评测命中判定都会用到它们。二、第一步Embedding 如何把聊天变成向量有了片段下一步就是向量化。CipherTalk 的向量服务messageVectorService.ts有几个对新手很友好、对工程很讲究的设计1. 懒构建 增量更新不会在启动时给你的全部聊天记录建索引那既慢又贵。而是首次对某个会话做语义检索时才把该会话最近 1500 条消息切成片段并嵌入之后再检索只通过高水位上次嵌到哪条消息补建新增部分ensureSessionVectors。成本只压在你真正查过的那几个会话上。2. 纯标准件无原生扩展依赖向量以 Float32 二进制格式BLOB存进独立的chat_vectors.dbbetter-sqlite3建表语句。检索时把查询文本嵌入成向量与候选片段向量逐一算余弦相似度排序取 top-K连sqlite-vec这类原生扩展都不需要。如果中途换过嵌入模型维度不符的旧向量会被直接跳过避免静默的 0 分污染结果searchSession。3. 嵌入模型可配置嵌入服务embeddingService.ts走 OpenAI 兼容的/embeddings接口你可以在应用的设置 → 嵌入里配置模型、维度与 API Key。只要配置完整混合检索路径就会自动启用。三、第二步RRF 混合检索向量 关键词取长补短向量检索擅长意思相近但对精确词编号、人名、错别字原文不如全文检索FTS可靠。反过来也一样。所以 CipherTalk 的semantic_search工具走的是混合检索两路并行按排名融合。融合用的是 RRFReciprocal Rank Fusion倒数排名融合核心公式非常简单每个来源给候选打名次 rank贡献分 1 / (k rank)k 默认取 60最后按总分排序。RRF 的美妙之处在于只看名次、不看原始分数——向量的余弦分0~1和 FTS 的 BM25 分数可能很大根本不在一个量纲上直接加在一起毫无意义而转换成名次后就能公平比较。实现只有一个纯函数rrf.ts无依赖、可单测。混合路径的完整流程semanticSearch.ts并行两路向量路径嵌入查询 → 片段 KNN与关键词路径原文 FTS同时跑任一路失败另一路仍可兜底返回同区域合并如果某条关键词命中恰好落在某个向量片段的[startSortSeq, endSortSeq]区间内就借用该片段的 key——两条路命中同一区域时这个片段在 RRF 里会累加两次名次分双路加权同时避免同一区域重复出结果RRF 融合排序后取候选再可选地过一层 Rerank 精排输出带anchor锚点的命中列表。同样的 RRF 思路也用在通用检索引擎 retrievalEngine.ts 里它把 FTS 与 LIKE 两条关键词来源来源定义各自排名后融合再为 top 候选展开证据——取命中记忆条目的前后原文消息保证召回能落到可核对的聊天记录上。四、评测用 recallk 和 MRR 量化该召回的有没有召回写得漂亮不算数跑得出来才算数。CipherTalk 把检索评测单独拆成了L1 层evaluation/retrieval/不跑 Agent、不调 LLM 对话只测一件事——该召回的消息片段有没有被召回。因为这是 Agent 端到端L2评测的地基检索召不回模型再聪明也答不对。1. 出题用例 JSONL评测用例会话限定、查询文本、期望命中的证据消息示例用例{id:case_001,sessionId:wxid_example,question:他上次答应我什么事情,semanticQuery:对方曾经承诺要完成某件事情,expectedEvidence:[{localId:123,createTime:1710000000,sortSeq:456}]}出题建议见 evaluation/retrieval/README.md从自己真实聊过的事出 20~50 题覆盖具体承诺、话题讨论、模糊指代、时间相关等类型。注意真实用例存本地的baseline.local.jsonl不提交真实会话数据。2. 打分区间覆盖 两个核心指标打分逻辑是纯函数 score.cjs关键设计是命中判定按区间而非单点因为一个向量片段是合并多条消息的只要期望证据的sortSeq落在某命中片段的[startSortSeq, endSortSeq]区间内就算被覆盖chunkCoversEvidence。recallktop-k 片段覆盖了多少比例的期望证据衡量找全了没有MRRMean Reciprocal Rank首个命中片段名次的倒数均值第一个就命中得 1 分第 3 名命中得 1/3 分衡量找得快不快fullyCovered完全覆盖recall 1的题数。3. 一键跑评测npm run eval:retrieval -- --cases evaluation/retrieval/baseline.local.jsonl --k 10评测脚本run-retrieval-evaluator.cjs是自包含的直接只读打开已建好的chat_vectors.db用嵌入接口算查询向量余弦排序后交给score.cjs出指标全程不连原始微信库。它还会自动用 Electron 的 Node 重启自身以匹配 better-sqlite3 的 ABI无需手动设环境变量。这套机制的价值在于可回归改了片段切分参数600 字符够不够20 分钟阈值合不合适或换了嵌入模型之后重跑同一批用例对比meanRecall/MRR好坏一目了然而不是凭感觉好像变好了。五、模块地图与上手路径模块路径职责向量服务electron/services/search/messageVectorService.ts片段切分、懒建索引、余弦 KNN、chat_vectors.db关键词索引electron/services/search/chatSearchIndexService.ts原文message_index全文索引RRF 融合electron/services/retrieval/rrf.ts纯函数排名融合k 默认 60检索引擎electron/services/retrieval/retrievalEngine.ts多来源融合 证据展开混合检索工具electron/services/agent/tools/semanticSearch.tsAgent 的semantic_search混合路径嵌入配置electron/services/ai/embeddingService.tsOpenAI 兼容嵌入接口封装评测体系evaluation/retrieval/用例格式、打分纯函数、指标说明新手上手三步在设置 → 嵌入配好嵌入模型 → 在应用里对目标会话做一次语义检索触发懒建向量→ 从真实聊天出 20 道题跑一次eval:retrieval先拿到自己的 recall10 / MRR 基线再去调参对比。六、总结CipherTalk 的向量检索引擎给所有想做对话式检索的项目提供了一个干净的参照片段粒度解决消息短碎问题懒构建控制成本RRF让异构打分公平融合recallk / MRR 评测让每次改动都有数字背书。四条都不复杂但组合起来就是找得到、找得全、找得快、可验证的完整闭环。【免费下载链接】CipherTalk查无此人项目地址: https://gitcode.com/gh_mirrors/ci/CipherTalk创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
