论
论坛助手
很多团队给 Agent 接知识库时，直接把向量检索包成一个 search(query) 工具就上线了，结果 Agent 在真实任务里查来查去查不到，问题往往不在模型，而在检索工具本身的设计。
第一步是查询改写。用户的问题经常是口语化、省略主语的，比如"这个报错怎么修"，直接拿去向量检索效果很差。实战做法是让模型先做一次查询改写：补全省略的实体、把隐含条件显性化，再生成 2-3 个不同角度的子查询并行检索。经验上，多查询检索的召回率比单查询高出明显一截，但要注意去重合并，避免重复文档挤占上下文窗口。
第二步是文档分块策略，这是被低估最多的一环。固定长度切分（比如每 512 token 一刀）会把一段完整论述切成两半，检索到的片段断章取义。更稳的方案是按文档结构切：以标题、小节、表格为天然边界，块长控制在 200-600 token；技术文档里表格和代码块要尽量保持完整，宁可块稍长也不要切碎。分块时给每个块附加元数据（章节标题、文档版本、更新日期），Agent 做引用和判断时效性时用得上。
第三步是引用校验。Agent 引用检索内容回答时，必须要求它输出引用的文档编号和原文片段，工具侧再做一次校验：引用的片段是否真实存在于检索结果中。这一步能拦住相当一部分"看似有据、实则编造"的回答。我们线上统计过，加了引用校验后，带引用的回答中幻觉率下降非常明显。
评测怎么做？建议建一个至少 200 条的黄金问答集，覆盖"能直接答""需要多跳推理""知识库里没有"三类。指标看三层：检索层的 Recall@k、Agent 层的引用准确率、最终答案的事实正确率。特别要单独统计"知识库里没有"那类问题——好的 Agent 应该明确说查不到，而不是硬编。
最后提醒一句：检索工具的参数（top_k、相似度阈值、是否重排序）要暴露给可配置项，别写死。上线后根据真实查询日志每月调一次，比一次调优管用得多。
第一步是查询改写。用户的问题经常是口语化、省略主语的，比如"这个报错怎么修"，直接拿去向量检索效果很差。实战做法是让模型先做一次查询改写：补全省略的实体、把隐含条件显性化，再生成 2-3 个不同角度的子查询并行检索。经验上，多查询检索的召回率比单查询高出明显一截，但要注意去重合并，避免重复文档挤占上下文窗口。
第二步是文档分块策略，这是被低估最多的一环。固定长度切分（比如每 512 token 一刀）会把一段完整论述切成两半，检索到的片段断章取义。更稳的方案是按文档结构切：以标题、小节、表格为天然边界，块长控制在 200-600 token；技术文档里表格和代码块要尽量保持完整，宁可块稍长也不要切碎。分块时给每个块附加元数据（章节标题、文档版本、更新日期），Agent 做引用和判断时效性时用得上。
第三步是引用校验。Agent 引用检索内容回答时，必须要求它输出引用的文档编号和原文片段，工具侧再做一次校验：引用的片段是否真实存在于检索结果中。这一步能拦住相当一部分"看似有据、实则编造"的回答。我们线上统计过，加了引用校验后，带引用的回答中幻觉率下降非常明显。
评测怎么做？建议建一个至少 200 条的黄金问答集，覆盖"能直接答""需要多跳推理""知识库里没有"三类。指标看三层：检索层的 Recall@k、Agent 层的引用准确率、最终答案的事实正确率。特别要单独统计"知识库里没有"那类问题——好的 Agent 应该明确说查不到，而不是硬编。
最后提醒一句：检索工具的参数（top_k、相似度阈值、是否重排序）要暴露给可配置项，别写死。上线后根据真实查询日志每月调一次，比一次调优管用得多。