刘欢の博客

1. Embedding（向量嵌入）+ 向量检索#

把文字用模型转成定长数字向量（本项目用 all-MiniLM-L6-v2，384 维）。语义相近的文字向量距离近。检索时把 query 转向量，算余弦相似度找最近。

• 优点：懂语义。「心梗」召回「心肌梗死」，「查订单」召回「订单查询接口」。
• 缺点：对精确专有名词、ID、代码符号不灵。getUserById 和 getUserByName 向量很近，但你要精确匹配。

2. BM25（关键词检索）#

传统词频统计算法（TF-IDF 升级版），看 query 词在文档中的频率与稀有度。

• 优点：精确匹配强，专有名词、函数名、错误码场景吊打向量。
• 缺点：完全不懂语义，换同义词就召回不到。

3. 混合检索（Hybrid）——本项目实际做法#

两者优势互补。本项目用加权求和：

1
# 向量分 × 0.6
2
all_page_scores[page_id] += score * vector_weight        # vector_weight = 0.6
3
# BM25 分先归一化(÷10 截断到1)，再 × 0.4
4
normalized_score = min(score / 10.0, 1.0)
5
all_page_scores[page_id] += normalized_score * bm25_weight  # bm25_weight = 0.4

这里有个关键的坑：BM25 原始分无上界（可能几十），向量相似度是 0~1，量纲不同不能直接相加，否则 BM25 会淹没向量分。所以代码先把 BM25 分 ÷10 截断到 1 归一化再加权——这是混合检索最常见的坑，我踩过并解决了。

业界还有更优雅的 RRF（Reciprocal Rank Fusion，倒数排名融合）：不看分数只看排名，score = Σ 1/(k+rank)，天然免疫量纲问题。我当前用的是加权归一化，RRF 是后续的演进方向。

核心思想：「完整保留 + 轻量索引」分层#

GAM 论文精髓一句话：别压缩历史（压缩就丢信息），而是完整存原文 + 单独建轻量索引快速定位。对应三个数据模型：

检索时先查又小又快的 Memo/索引定位 Page，再捞完整 Page 原文——既快又不丢细节。

双阶段：离线写入 + 在线检索#

离线 GAMMemorizer：Worker 执行完一个 session 后触发 process_session()：

1. 把工作记录喂 LLM，生成一句话 SessionMemo（摘要+关键实体+结果）；
2. 把完整内容切成带重叠的 Page（2000字符/页，200字符重叠，防切断语义）；
3. 自动打标签、存盘、更新索引。

在线 GAMResearcher——最亮的部分，是一个 Deep-Research 循环（不是查一次就用）：

1
Planning（LLM 规划搜索策略：用哪些 query、哪些检索器）
2
   ↓
3
Searching（向量 + BM25 + Page-ID 多工具检索 + 加权融合）
4
   ↓
5
Reflection（LLM 评估：信息够不够？置信度多少？）
6
   ↓ 不够且未到 3 轮 → 带新 query 再循环
7
   ↓ 够了(置信度≥0.7) 或到 3 轮上限 → 整合成连贯上下文给 Worker

这就是 Agent 版 RAG——传统 RAG 是「查一次直接用」，这套是「让 LLM 自己判断查得够不够，不够换角度再查」，带反思迭代，质量高很多。

工程成熟度细节：优雅降级 + 性能节流#

• 优雅降级（_init_default_retrievers）：三个检索器独立初始化，一个挂了不影响其他。向量检索依赖 sentence_transformers，装不上就只用 BM25；全挂了 fallback 到 page_store.search_pages()。这呼应了项目里「换被测系统核心代码零改动」的原则——无强依赖、层层兜底。
• 性能节流（last_cleanup_at）：历史多了每次启动全量扫会拖慢 Agent，用时间戳节流避免每次清理。这种细节是真踩过坑才会做的。