上下文感知检索解决什么问题？
- 根因: 标准分块方法（固定大小或递归切分）不可避免地把紧密关联的上下文分离;
- 症状: 孤立文本块“该公司第二季度的收入增长了 3%”脱离原始上下文后变得模棱两可;
- 三个无法回答: 代词指代（“该公司”是哪家公司）、时间参照（报告发布于何时）、实体关系（与哪个产品线相关）;
- 后果: 这种上下文丢失在信息嵌入阶段就造成严重语义损失，直接导致检索准确率下降;
- 出处: Anthropic 提出的 Contextual Retrieval;
它的具体做法是什么？
- 核心思想: 在对文本块进行向量化索引之前，先利用 LLM 为其生成一段简短的、包含核心上下文的“前缀摘要”;
- 索引方式: 将前缀与原始文本块拼接后再索引;
- 例子: 系统可能生成前缀“[本段内容节选自 ACME 公司 2025 年 Q2 财务报告的‘关键业绩指标’章节]”;
- 效果: 原本模糊不清的文本块被重新“锚定”在其原始语义环境中;
它与上下文感知压缩有什么区别？
| 维度 | 上下文感知检索 | 上下文感知压缩（第二章） |
|---|
| 时机 | 索引期 | 运行期 |
| 对象 | 知识库里的文本块 | 当前会话的对话历史 |
| 动作 | 补前缀、加背景 | 按当前任务裁剪、丢弃无关内容 |
| 方向 | 加法（补上下文） | 减法（去冗余） |
| 目的 | 提升可检索性 | 节省窗口 |
为什么它同时增强稀疏检索和稠密检索？
- 对稀疏检索: 上下文前缀增加了丰富的、可精确匹配的关键词（“ACME”“2025 年第二季度”），利于 BM25 类检索，见 稀疏检索与 BM25;
- 对稠密检索: 前缀注入了关键语义背景，使生成的向量表示更精确地反映文本块的真实含义，见 稠密嵌入与向量索引;
实验给出了哪些关键数字？
- 对比设计: 并行构建两个知识库——一个用传统无上下文分块，一个用 LLM 生成上下文前缀，
compare_retrieval_methods 用同一查询在两边同时检索并排比较;
- 典型查询: “ACME 公司最近的收入增长情况如何？”;
- 无上下文侧: 可能匹配到许多包含“收入增长”关键词但来自不同公司、不同年份甚至只是泛泛行业分析的文本块，相关性低、充满噪声;
- 有上下文侧: 每个文本块都带有精确的“身份标签”，查询能准确命中既含关键词、上下文前缀又匹配“ACME 公司”“最近”等意图的文本块，得分显著更高;
- 成本: 代价是索引阶段额外 LLM 调用，但通过 prompt caching（对相同前缀的重复调用只需约 1/10 的成本）完全可控，每百万文档 token 约 1 美元;
- 收益: 据 Anthropic 研究数据，此技术结合 BM25 可将检索失败率降低 49%，再结合重排序器降幅达 67%;
应用到用户记忆上效果如何？
- 必要性的例子: 一段孤立的“好的，就订这个吧”毫无信息量，只有知道上文是“从上海到西雅图的 500 美元单程机票”才有意义;
- 做法: 在索引对话历史前增加“上下文生成”步骤，对每个对话块调用 LLM 生成包含关键背景信息的前缀摘要;
- 冲突处理的优势: 妻子先设立电汇、丈夫修改、妻子再改回来的场景中，三个对话块分别带上“[妻子 Patricia Thompson 正在设立初始电汇]”“[丈夫 James Thompson 正在修改之前的电汇]”“[妻子在丈夫修改后再次修改电汇]”前缀，时间、人物与意图为 Agent 判断指令优先级和最终有效性提供关键线索;
- 结论: 上下文增强后的记忆库在处理事实冲突时展现决定性优势;
双层记忆架构为什么能支撑主动服务？
- 设计: 用 Advanced JSON Cards 把少量关键事实结构化后常驻上下文，提供随时可见的“概览”；用上下文感知检索按需从海量原始对话中取回“细节”，见 用户记忆的四种存储格式;
- 案例（
layer3/01_travel_coordination.yaml）: 事实回顾——Agent 审视 JSON Cards，掌握“东京之行”与“护照信息”两个核心事实;
- 案例续: 关联推理——发现机票日期（一月）与护照过期日期（二月）非常接近，识别出潜在风险;
- 案例续: 细节验证（RAG）——通过上下文感知检索查找“护照”与“东京机票”相关原始对话确认细节;
- 案例续: 主动服务——综合结构化事实与对话细节，给出“护照即将过期，强烈建议加急续签”的主动建议;
- 与三层标尺的对应: 基础回忆靠可靠的存取即可满足，多会话检索靠检索技术补齐，主动服务最难——它要求系统同时握有全局概览与精确细节;
- 为什么缺一不可: 只靠常驻上下文会因容量受限而丢失细节，只靠检索又会因缺乏全局视野而发现不了跨会话的隐藏关联;