为编码智能体连接正确的文档：构建可导航的上下文层
内容提要
Redis团队为文档问答智能体改进检索方案：V1将文档作为单一实体，导致BF.RESERVE等命令查询混入无关结果；V2拆分为页面、文本块、命令三类实体，并以稳定page_id建立关联，使智能体可按问题选择检索路径。在62题评测中，nDCG@5由0.493升至0.658，recall@5由0.610升至0.743，各组均有改善；但工具调用增多，p95延迟占请求预算的比例由约40%升至72%。下一步是减少冗余调用并及时停止检索。
延伸解读
检索质量提升的代价：延迟与工具调用
V2在62题评测中nDCG@5从0.493升至0.658，recall@5从0.610升至0.743，各组均有改善。但更丰富的检索面要求智能体执行更多工具调用，p95延迟占25秒请求预算的比例从约40%升至72%。这意味着留给网络波动或额外检索步骤的余量明显缩小。文章指出下一步不是退回简单模型，而是减少冗余调用、在证据足够时及时停止检索，以平衡效果与响应速度。
实体拆分与稳定ID：让检索路径可导航
V1将页面、章节和命令统一为RedisioDoc实体，导致查询BF.RESERVE时混入Kubernetes等无关页面。V2拆分为RedisioChunk、RedisioPage、RedisioCommand三类实体，并以稳定page_id建立页面与文本块、页面与命令之间的显式关联。这样智能体可根据问题类型选择检索路径：命令问题直接查命令记录，宽泛问题先发现页面，再通过page_id获取具体证据。文章强调，关系只有在双方共享稳定标识时才有效，这也提升了引用、评估和调试的可靠性。
评估证据而非仅看答案：独立评测工具的价值
文章指出，强大的基础模型可能用通用知识填补检索缺口，使流畅答案掩盖弱检索。因此团队构建了独立评测工具，将适配器与评分逻辑分离，用同一黄金数据集比较不同检索目标。适配器负责调用系统、保留结果顺序并映射到稳定页面ID，评测框架则计算nDCG、recall等指标。这种做法把“是否检索到正确证据”与“模型是否用好证据”分开，避免仅凭答案观感判断改进效果。
Q&A
Redis团队为什么要把文档检索从单一实体拆分成多个实体？
V1将文档作为单一实体RedisioDoc，导致不同检索任务混在一起。例如查询BF.RESERVE命令时，结果混入了Kubernetes和REST API等无关页面，命令页面甚至未出现。拆分后，智能体可以根据问题类型选择不同的检索路径，提高检索准确性。
V2版本中文档被分成了哪几类实体？它们之间如何关联？
V2将文档拆分为三类实体：RedisioChunk（文本块）、RedisioPage（页面）和RedisioCommand（命令）。它们通过稳定的page_id建立显式关系链接，使智能体可以在页面、文本块和命令之间导航。
V2在检索效果上比V1提升了多少？
在62题评测中，nDCG@5从0.493提升到0.658，recall@5从0.610提升到0.743。所有问题组均有改善，其中简单查找和多步问题的提升最明显。
V2带来了哪些性能代价？
V2需要更多的工具调用，导致延迟增加。在p95延迟上，V1约占请求预算（25秒）的40%，而V2约占72%，留给网络延迟和其他步骤的余量更少。
团队如何独立评估检索质量而不依赖最终答案？
团队构建了一个独立的评估工具包，包含适配器和共享评估框架。适配器将不同检索系统的输出转换为统一的RetrievalTrace（有序页面ID列表），然后与黄金数据集对比，计算nDCG、recall等指标，从而单独衡量检索证据的质量。
下一步计划如何优化V2的检索效率？
下一步不是回退到简单模型，而是让导航更高效：减少不必要的工具调用，为命令问题设置直接路由，仅在需要时使用页面发现，并设定确定性标准让LLM在证据足够时停止检索。
