1. 为什么Agent场景的检索评估不能照搬传统RAG那套先说个我最近的真实经历。团队内部做了一个面向销售团队的问答Agent知识库塞了产品手册、历史报价单、客户会议纪要、竞品分析PPT还有几十份不同年份的合作伙伴协议。上线前我们用常规手段测了一轮——从每个文档抽几个问题看检索系统能不能把相关片段捞出来召回率和命中率都挺漂亮Top-5命中率接近90%。结果一到真实使用Agent频繁给错答案问2024年华东区的报价策略它把2021年的老方案翻出来了问某客户的续约条款它抓了一段关于另一家同名公司的内容。业务同事反馈说这Agent看起来聪明用起来坑人。问题出在哪后来复盘发现我们当时测的是标准RAG的检索质量而不是Agent场景下的检索质量。两者差别非常大。传统RAG的检索评估本质上是给一个独立问题找一段支撑文本标准答案往往是人工标注的golden passage。但到了Agent场景检索不再是查一道题而是嵌入一个多步推理链路Agent先要理解任务目标中间可能需要多轮检索来收集信息每轮检索的结果又会影响下一步决策。更关键的是Agent拿到的知识库是真实公司的混乱知识库——文档格式五花八门、信息冗余、版本冲突、权限交织。这种场景下检索系统要解决的核心问题已经从找到相关文档变成了在噪声中提供可决策的信息两者衡量的维度和评测方法完全不同。这篇文章我想认真聊聊这个主题Benchmarking retrieval for agents on messy real-world company knowledge——如何为处理真实公司杂乱知识的Agent系统设计一套靠谱的检索基准测试。文章里会覆盖为什么传统评估不适用、真实公司知识的乱具体长什么样、怎么构造评估集、怎么选指标以及我们实际跑benchmark时踩过的坑。适合正在做企业知识库Agent、RAG系统评估、或者想给内部知识工具引入更严格评测体系的工程师和算法同学参考。1.1 一个典型的翻车场景问题出在评估设计回到上面那个销售Agent。复盘时我们做了一个简单的压力测试把知识库里的文档全部倒进一个统一的测试集然后针对三个场景分别构造问题。第一个场景是标准问答问题本身写得干净答案集中在某一个文档片段里。比如我们给A客户的历史折扣是多少人工标好哪个文档哪一段是答案来源。用这套数据测系统的表现是不错的Top-5召回率接近85%。第二个场景是复合问题问题需要跨多个文档才能回答。比如对比A客户和B客户的续约条款差异答案需要从两份协议里分别抽取条款再对比。这时候系统的表现开始下滑Top-5召回率掉到了70%左右而且经常漏掉其中一份关键文档。第三个场景是真实使用中的模糊查询业务同事不会像测试集那样问得很精准而是问A客户那边的情况怎么样、最近的报价应该怎么给。这种问题本身充满了歧义需要Agent结合上下文猜测用户意图。测试结果惨不忍睹检索系统给出的Top-5片段里真正有用的可能只有一两个还常常被埋在不相关的内容中间。当时我们犯了一个典型错误用标准问答数据集的评测结果去推断真实Agent使用的效果。但Agent场景的数据分布完全不一样——模糊查询占大头、多文档复合问题比例高、知识库本身还有版本新旧和权限差别。用不匹配的benchmark测出来的分数自然无法反映真实效果。这也是这篇内容第一个想强调的结论评估Agent检索能力第一步不是选指标而是想清楚你的评测场景和真实使用场景是否吻合。场景不匹配后面所有的指标和调优都可能是自欺欺人。1.2 Agent对检索的容错率远低于人类用户还有一个更隐蔽的差异是容错率。人用搜索或知识库工具时检索结果只要差不多用户自己能判断哪条有用、哪条没用甚至能主动换关键词再搜一次。人有很强的纠错能力检索结果差一点最终效果也能补回来。Agent不一样。Agent的核心是自主决策它拿到Top-N个检索片段后一般会直接把这些片段放进上下文交给LLM推理。LLM的推理有一个特点它对上下文中的噪声非常敏感。如果检索结果里混入了高相关但错误的信息比如过期的报价、错误的版本条款LLM可能会一本正经地引用错误内容生成答案。这个过程没有人在中间把关错误会被直接放大到最终输出。我们在评测中还发现一个规律当Top-5里只有1条正确片段、其余4条都是干扰项时不同LLM的表现差异很大。有些模型能把正确信息挑出来并回答正确这类模型上下文鲁棒性好有些模型会被干扰项带偏。但检索系统本身并不知道下游模型是谁——同一个检索器配上不同模型最终效果天差地别。这意味着Agent场景下的检索评估不能只看检索结果本身有多准还要看这些结果对下游Agent决策的帮助有多大。单纯用检索阶段的命中率作为唯一指标忽略了LLM对检索结果的利用能力会高估或低估系统的真实能力。1.3 现有常见检索基准到底测不出什么这里顺便盘点一下常见的检索基准。像MS MARCO、Natural Questions、BEIR这类经典数据集对学术研究很有价值但它们和真实公司知识的Agent检索有几个关键差异第一文档分布不同。公开数据集里的文档一般经过清洗格式统一质量较高。真实公司知识库里有扫描版PDF、有PPT导出的图片、有几十年前的Word文档、有Excel表格、有飞书/Notion的导出页面甚至还有语音转文字的会议记录。这些文档的噪声水平远超公开数据集。第二问题分布不同。评测集里的问题往往人工精心构造表述清晰、答案唯一。真实使用中用户或Agent面对的问题往往模糊、嵌套、需要拆解。比如客户说价格太高想再谈谈我们有什么可以给的优惠空间——这个问题本身跨了销售策略、价格体系、历史案例三个领域不是一条检索就能解决的。第三信息冗余和冲突。真实知识库中同一主题通常对应多份文档而且里面的说法可能互相矛盾。公开数据集通常默认每道题对应一段正确答案很少处理同一问题有多个互相冲突的答案来源的情况。而这恰恰是真实企业场景的常态。所以说直接拿公开benchmark来评估Agent检索系统等于是用高考题去测一个在工地上干活的人——不是说没用而是场景错位得太厉害。为Agent场景设计检索benchmark第一步应该是设计场景而不是套指标。这个观点是这篇文章的核心主线后面的内容都是围绕这一点展开的。2. 乱才是常态真实公司知识的messiness拆解要在messy的知识库上做检索评估首先得把messy这个词拆明白。真实公司知识不像教科书——它不是一个干净的体系而是各种历史遗留、组织边界、人为习惯叠加出来的复杂产物。我在几个不同规模的公司知识库项目里摸爬滚打之后总结出真实公司知识混乱的几个主要维度。这些维度直接影响benchmark设计因为每个维度都需要在评测集里被采样到否则评测就会失真。2.1 载体形态的混乱远比你想象得严重先看载体形态。真实公司知识库的文档来源通常包括办公套件文档Word、PPT、Excel其中PPT尤其麻烦每页只有几句要点脱离上下文完全看不懂日历邀请和会议纪要通常不成文、口语化严重还有大量讨论后决定这种没有主语的话IM聊天记录导出碎片化程度最高一条消息往往只有几个字邮件归档包含大量转发链、签名档、历史对话正文和附件混杂老旧的内部Wiki页面很多是多年前写的格式混乱图片失效扫描件或图片转文字OCR的文档识别错误率高英文和数字常被识别错客户系统导出的结构化数据比如CRM里的字段备注一句话里塞进大量缩写不同载体形态对检索系统的处理要求完全不同。文本切分策略就是一个典型问题对PPT简单地按页切可能丢失上下文对IM聊天记录按消息切太碎按会话切又太长对邮件不处理转发链的话检索到的片段可能是别人的签名档。在benchmark设计时如果一个评估集只包含干净规整的文档就完全测不出检索系统应对这些复杂载体的能力。2.2 语义与上下文的割裂让相关变得很难定义第二个维度是语义割裂。公司知识里充满了内部上下文——术语、缩写、人名、项目代号。这些东西对外人来说是黑话但对公司内部员工来说是常识。举个例子一份文档里写Q3 P0项目需要KBU配合如果不知道KBU是某个业务单元这句话就是一堆字母。还有大量的指代现象文档里写着客户那边说同意我们的方案——客户是哪个客户方案是哪个方案这些信息在文档上下文里可能有也可能没有。语义割裂对检索评估最大的冲击是标注人员如果没有领域知识会很难判断一个检索结果到底相不相关。一段文本可能在字面上不包含查询关键词但经过推理它就是回答问题的关键依据。传统基于关键词匹配或字面语义相似度的标注方式在真实公司知识面前往往失效。2.3 知识的老化、矛盾与权限边界检索评估必须回答的问题第三个维度是知识的时间性和权威性。真实公司知识库里信息是分层级的有的文档是当前有效的制度有的是已被替代的草案有的是某次讨论的中间结论。一份文档在经过多次修订后旧版本不会自动消失而是静静躺在某个共享盘或协作工具的历史记录里。于是检索系统面临一个在公开数据集里几乎不存在的难题检索到的结果可能已经过期。系统需要判断文档的新旧、版本状态、甚至权威来源比如制度类信息应该优先引用正式发文而不是聊天记录里的一句讨论。在评估时如果不能对答案来源的时效性和权威性进行建模只是简单地看文本是否匹配就会出现检索得很准回答得很错的结果。权限边界也是真实场景里无法回避的问题。公司知识库的访问权限往往是按团队、层级、项目隔离的。同一个Agent服务不同团队时同一个查询在不同权限下应该检索到的内容范围不同。Benchmark如果忽略权限因素直接把全库作为候选集测出的检索能力在真实部署时可能完全不可用。我记得有一次我们在评估时遇到一个报错——public key retrieval is not allowed。那是在处理加密文档和访问控制时检索服务在拉取某些文档内容时被权限系统拦截。这个错误提醒了我们一件事真实环境中的检索永远是在权限约束下的检索评估集的设计也必须带上权限维度。员工的文档能否被检索到、能否被Agent引用本身就是检索系统能力的一部分。2.4 为什么公开数据集测不出messy问题的处理能力基于上面的拆解可以给出一个很清晰的结论公开数据集的文档经过数据清洗通常没有载体混乱、没有语义割裂、没有版本冲突、没有权限边界。用这样干净的数据测检索本质上测的是文本匹配能力。而真实公司知识场景需要的是在混乱中定位可信信息的能力。这两者之间差着好几个维度。这也是为什么我们需要一个专门针对messy real-world company knowledge的benchmark——不是为了跟别人的系统比分而是为了回答一个实际的问题当我给Agent接上一个真实的公司知识库之后它面对用户的任务请求到底能不能稳定、正确地找到应该依据的信息3. 构建针对乱的评估集数据、任务与标注方法聊完了为什么和乱在哪下面进入实操部分怎么搭建一套能真实暴露问题的benchmark。这部分我会讲评估集的数据来源、任务维度设计、标注方法三个层面。3.1 评估数据的选择宁缺毋滥但要覆盖混乱维度我们在做第一个版本时犯过一个很典型的错误为了追求数据量把知识库里所有文档都无差别地塞进评估集结果标注成本巨大而且很多文档根本没被真正用到。后来总结出几条实操原则第一选真实被问到的文档优先。从Agent真实使用日志中找出用户或Agent高频访问的文档和查询以这些为种子来构造评估集。这样保证评估集里的知识分布和真实使用场景一致。第二有意识覆盖混乱维度。评估集里不仅要干净的文档还要包含前面提到的各种类型会有PPT、会议纪要、邮件转发链、老旧文档、以及存在版本冲突的文档对。可以按比例控制比如60%常规文档、20%特殊格式、10%版本冲突场景、10%跨权限场景。第三设置不可答样本。真实知识库中有相当比例的问题其实是知识库里没有答案的。比如我们之前和某公司的分成比例是多少——知识库根本没有任何记录。传统检索评测很少包含这类unanswerable样本但对Agent来说正确地回答找不到相关信息和错误地给出猜测结果有天壤之别。评测集一定要加入合理比例的不可答问题才能真正测出系统的稳重程度。3.2 任务设计从单跳问答到多跳决策任务维度的设计是评估集的核心直接决定了你测的是检索的匹配能力还是Agent的信息利用能力。我们目前的评估集包含四类任务层层递进任务类型一单跳事实问答。问题可以直接在一段文档里找到答案特征是查得准不准。这类任务主要测基础检索能力也是传统评测的主力。虽然这类任务不能完全代表真实场景但它仍然是整个评估的地基。任务类型二多跳条件问答。回答需要结合多个文档的信息才能完成特征是找得全不全。比如2023年Q4我们与B供应商签署的合同里付款方式是哪种——需要先定位合同文档再结合合同条款判断。这类任务对检索系统的要求是多轮检索时每轮都不能掉链子。任务类型三时效性判断。知识库中存在多个版本或互相矛盾的文档模型需要判断在给定的时间上下文里哪个信息是有效的。比如我们现在的退款政策是什么——知识库里可能有2019版、2022版、还有某次讨论中提到的想改但没正式发布的版本。正确的答案应当基于最新生效版本。这类任务能直接测出检索系统对版本/时间维度的敏感性。任务类型四决策参考。没有唯一正确答案但Agent需要找出一组相关信息供决策参考。比如为了准备和X客户的续约谈判需要收集哪些背景信息和历史条款。这类任务最接近真实使用但也最难标注——没有标准答案只能从是否遗漏了关键信息来评判。这四个任务类型各有侧重但注意它们之间不是互相替代的关系。一个完整的benchmark应该包含全部四类这样能同时看到系统的匹配能力、召回能力、时效感知和信息完备性。3.3 评估集的质量保障标注、审核与去泄漏评估集的质量直接决定了评测结果的可信度。这里有几个很容易被忽略但极其重要的点。第一是标注规范。多跳任务和决策参考任务的标注难度远高于单跳问答标注人员需要具备领域知识。我们当时的做法是由有业务经验的人先标一轮再让领域专家审核一轮最后对不一致的部分进行仲裁。第二是数据泄漏问题。这一点在真实知识库场景中特别容易犯错——训练数据或索引数据如果不小心包含了评估集中的文档那检索得分会虚高到失真。我们踩过的教训是评估集必须从索引中完全剔除而且要用独立的文档存储空间。在评测不同版本系统时特别要注意旧版本的Agent是否在之前的实验中已经把评估集内容写入了上下文缓存。第三是需要做难度分层。评估集里的问题不能全都是简单问题或难题。我们使用的方式是让两个不同能力的检索器跑一遍评估集标注出那些强检索器能答对而弱检索器答错的问题作为困难样本并保证困难样本占比不过分偏低。否则整个评估集很容易出现一个现象所有系统得分都在90%以上无法区分优劣——这种评估集没有区分度对系统迭代的帮助接近于零。4. 评测指标怎么选检索分高不等于Agent好用评估集搭好之后下一个核心问题是指标设计。这个环节很能体现Agent场景检索评估和传统检索评估的分水岭。4.1 传统检索指标的幻觉在真实场景中可能失真最经典的检索指标是RecallK、MRR、NDCG。这些指标衡量的是正确答案是否出现在Top-K中以及排序的质量。它们有明确的数学定义也便于横向比较但在Agent场景下单用这些指标会遇到几个无法回避的问题第一个问题回忆一下前面强调过的真实公司知识里答案经常不是唯一的。多份文档可能给出不同甚至是矛盾的答案这时正确答案如何定义是全部算对还是只有符合当前版本的答案才算对如果按照后者那RecallK的位置标注就变成了一项需要领域知识判断的工作。第二个问题检索器返回了正确答案不代表Agent就能用它给出正确回答。有一类非常常见的情况是正确答案在Top-1但Top-2到Top-5里全是具有误导性的过期信息LLM最终被带偏输出错误答案。这种场景下传统的Recall1得分是满分但Agent的实际表现是失败的。评测分数和真实效果之间出现了巨大的鸿沟。第三个问题跨文档信息整合无法用传统指标衡量。多跳问题中单独看任何一个片段的排序都没问题但Agent需要的是这些片段之间的信息关系。传统指标无法衡量信息组合的效果。老实说我们在项目早期的评测中就被这些指标欺骗过——系统在指标上分数不错但实际使用时频繁出错。后来花了大量力气调整指标设计才逐步让评测结果和真实使用体验对齐。4.2 从检索得分到任务完成率把Agent的决策拉进评估闭环在经历了一轮指标失真的教训之后我们引入了一套新的评估框架——核心思想是从检索得分升级为任务完成率从片段级别评估升级为任务级别评估。这套框架包含三个层次的指标第一层是片段级别指标包括RecallK、MRR、NDCG。这一层指标不是没有用而是作为诊断工具使用——当系统的任务完成率不佳时通过这一层指标来定位问题出在检索阶段还是推理阶段。第二层是信息覆盖度指标。对于多跳任务和决策参考任务人工预先定义回答问题时需要收集的关键信息点必要信息项然后检查Agent最终回答中是否包含了这些信息点、是否有遗漏。这个指标可以认为是任务层面的召回率。第三层是任务完成率。对于每个评测问题定义成功标准一个二元判定Agent是否给出了符合要求的最终答案然后看整体通过率。例如对于单跳事实问答答案是否与标准答案一致用LLM裁判但因为答案是确定的可以用规则和模型结合判断对于时效性判断Agent是否正确选择了最新版本的信息来源对于不可答问题Agent是否明确说明信息不足而不是编造答案任务完成率是最终验收指标前两层指标是辅助排查指标。在实践中我们发现这个分层架构非常有用——既要看最终能不能做对也要在做不对时知道是检索还是推理的问题。只有一层指标的评测体系碰到问题就像黑盒排查效率太低了。4.3 上下文使用效率Agent场景独有的评测维度还有一个传统检索评估不太关注、但Agent场景非常关键的维度——上下文使用效率。Agent调用检索服务时返回的Top-K片段会全部塞进LLM的上下文窗口。片段越多、越长LLM的推理负担越大、延迟越高、成本也越高。更重要的是高噪声的长上下文还会稀释有效信息降低LLM的推理准确率。所以我们引入了两个指标一是必要信息浓缩率。衡量的是检索结果中真正被Agent最终回答利用的信息占检索结果总长度的比例。这个指标越高说明检索系统给的东西越精炼。在实践中我们发现同样的Recall水平下不同切片策略带来的信息密度可能差3倍以上。二是噪声敏感度。把正确片段随机噪声和正确片段高相似度但错误的干扰片段两种检索结果分别喂给同一Agent比较回答正确率的变化。变化越小的系统对噪声的鲁棒性越强。这个指标在benchmark设计中非常有价值因为它衡量的是检索系统在无法做到100%干净时的兜底能力。这三个层次的指标放在一起才能构成一个完整的Agent检索能力画像检索系统不仅要在标准情况下找得到还要在信息混乱的情况下找得稳并且能让Agent真正用得上。5. 跑benchmark时真正踩过的坑最后这部分我想分享一些实际的踩坑经验。这些坑很难从论文或文档里学到基本都是被真实项目教育之后才明白的。记录下来希望后人少走弯路。5.1 文本切分策略看似无关紧要实则决定性影响第一个影响巨大的坑就是切分策略。我们最开始用简单的固定长度切分比如按512个token切一段然后在评测中连续翻车。典型场景是这样的一次关于2023年华东区销售考核方案的查询正确答案明明在某个文档里但无论怎么调检索参数结果里就是找不到。后来人工检查发现这份文档是一个大表格里面混合了文字和结构化的数据。固定长度切分时把表格的行切得支离破碎——每一行前半部分在片段A后半部分在片段B两个片段单独看都无法构成完整的语义单元检索系统自然无法命中。后来我们试验了多种切分策略包括按标题结构切分、按段落切分、按语义边界切分以及针对表格进行结构化提取后再切分。最终效果差异很大。所以现在我们在benchmark设计中会单独把文档切分的合理性作为一个评估维度。具体做法是对同一份文档分别用不同切分策略索引然后比较同一组评估问题的得分差异。如果切分策略的改变能引起得分5个点以上的波动说明这个切分策略本身就是评估结果中的一个关键变量——不能简单当作预处理细节忽略掉。5.2 public key retrieval is not allowed权限带来的隐蔽坑第二个想说的坑是关于权限与加密文档的。标题里提到的某个热词某种程度上也反映了一个真实问题——在实际部署的检索系统中权限过滤、加密机制和检索服务常常会互相纠缠产生一些表面上很难定位的错误。举个例子在一次评估中某个团队的知识被加密保护检索服务的正常查询路径里拉取文档内容时会因为密钥管理策略返回public key retrieval is not allowed。我们最初的评测代码没有专门处理这类错误导致这些文档在检索结果中神秘消失看起来像检索效果差实际上是权限机制拦截了内容获取。这个错误既不在检索日志里暴露也不在评测报告的报错里体现排查了很长时间才发现根因。这类问题在benchmark设计中意味着两件事第一评估集一定要带上权限维度的样本并且要在评测方案里明确这些样本的检索过程是否被允许第二评测系统要有错误注入的检测机制——当检索服务因权限、加密、网络等原因无法访问某些文档时评测应该能明确记录是检索未命中还是检索被拦截否则会把系统问题误判为算法问题。从此以后我们把权限相关错误单独成一类日志在评测报告里分开统计不再混在未命中里了。5.3 评估集的脏与偏两个隐蔽失真的来源第三个坑是评估集自身的偏差。脏的问题在于标注不统一。我们的标注人员来自不同业务线对相关的定义不一致。两个人都标同一批问题最后仲裁率需要第三方定夺的比例逼近30%。后来我们录入了领域术语表和标注指南重新培训仲裁率才降到10%以下。这个数字提醒我们评估集本身是一个需要建设的数据产品没有严格的质量控制评测结果只能是一堆噪声。偏的问题在于覆盖不全。第一版评估集里我们漏掉了邮件转发链这类特殊格式文档结果整个系统在这类资料上的检索能力长期处于盲区直到有业务反馈查不到历史邮件才开始补救。这个教训告诉我们评估集的构建必须从真实使用日志驱动而不是从方便标注出发。凡是真实场景中出现过的文档类型、查询类型都要尽量在评估集中有对应样本。5.4 LLM采样随机性一个让A/B测试翻车的细节最后一个坑可能对正在做评估对比的人特别有价值——LLM的采样随机性会直接影响评测结果而且影响幅度远超多数人的预期。在同一组检索结果下同一个LLM的温度设为0.2时跑两次评测任务完成率可能波动3到5个百分点。这个波动幅度足以让两个系统的差异变得不显著——你辛苦做的优化可能被随机噪声掩盖了。为了对抗这个问题我们做了三件事第一在评测时对同一设置跑多次至少三次以上取均值或中位数而不是跑一次就下结论。第二对于确定性要求高的任务单跳事实问答、时效性判断我们直接在评测时给LLM设置更低的温度甚至用多次采样投票的方式获取答案。这类任务的得分差异应该主要来自系统能力而非采样运气。第三引入随机性下界的对照实验——先在完全固定的输入不调用检索器直接把正确答案硬编码进上下文下测一个LLM表现的下限和上限再测真实检索条件下的表现。如果真实表现已经很接近理想上下文表现说明检索系统已经不是瓶颈再优化检索效果有限。这个对照策略帮助我们更理性地判断优化的优先级。5.5 排名与选择最终评测结果怎么汇报才不算误导上面讲的都是工程细节最后想提一个结果汇报层面的建议——不要只汇报一个综合分数。我们的做法是将结论拆成三块汇报第一块是任务完成率总览按任务类型单跳、多跳、时效、决策参考分别汇报准确率这样能看到系统在哪类任务上偏弱。第二块是失败归因分析对每个失败样本判定失败原因是检索未命中、检索命中但被噪声淹没、还是LLM推理错误。第三块是维度诊断报告按文档类型、权限场景、时效性场景分别统计。这三块放在一起你才能对系统的真实能力有一个立体的、可信的了解而不是被一个漂亮的平均分欺骗。6. 再说点个人体会回头来看这个benchmark设计项目给我留下的最大体会其实是做Agent检索的评估最难的部分不在于设计精巧的指标而在于真实地还原使用场景。很多人一开始做评测会习惯性地先找一套现成的benchmark、跑一个熟悉的指标然后基于分数调优。但真实世界的知识检索尤其是公司内部的messy knowledge远不是一个问题-段落匹配的任务。它要求系统在混乱、冲突、过时、碎片化的信息中找出对当前决策真正有用的部分——这份能力只有通过还原真实场景的评估才能测出来。另外一个体会是评估工作应该是持续建设的而不是一锤子买卖。知识库在变、用户在变、Agent在变benchmark也需要跟着迭代——每过一段时间从真实使用日志里捞一批新问题补进评估集拿去重后替换掉已经饱和的旧问题。这样评测分数才有持续的指导意义。如果这篇文章能给你一个可落地的建议我想说如果你正在为自己的Agent系统搭建检索评估别急着选指标、跑分数。先花两周时间把你知识库里最乱的那部分挑出来构造一个让系统不那么好看的评测集。让评估集先难起来再谈怎么变好这条路径比反过来走要高效得多。以上是我在这个方向上踩过的一些弯路和攒下的一点经验。希望对大家有帮助。
1. 为什么Agent场景的检索评估不能照搬传统RAG那套先说个我最近的真实经历。团队内部做了一个面向销售团队的问答Agent知识库塞了产品手册、历史报价单、客户会议纪要、竞品分析PPT还有几十份不同年份的合作伙伴协议。上线前我们用常规手段测了一轮——从每个文档抽几个问题看检索系统能不能把相关片段捞出来召回率和命中率都挺漂亮Top-5命中率接近90%。结果一到真实使用Agent频繁给错答案问2024年华东区的报价策略它把2021年的老方案翻出来了问某客户的续约条款它抓了一段关于另一家同名公司的内容。业务同事反馈说这Agent看起来聪明用起来坑人。问题出在哪后来复盘发现我们当时测的是标准RAG的检索质量而不是Agent场景下的检索质量。两者差别非常大。传统RAG的检索评估本质上是给一个独立问题找一段支撑文本标准答案往往是人工标注的golden passage。但到了Agent场景检索不再是查一道题而是嵌入一个多步推理链路Agent先要理解任务目标中间可能需要多轮检索来收集信息每轮检索的结果又会影响下一步决策。更关键的是Agent拿到的知识库是真实公司的混乱知识库——文档格式五花八门、信息冗余、版本冲突、权限交织。这种场景下检索系统要解决的核心问题已经从找到相关文档变成了在噪声中提供可决策的信息两者衡量的维度和评测方法完全不同。这篇文章我想认真聊聊这个主题Benchmarking retrieval for agents on messy real-world company knowledge——如何为处理真实公司杂乱知识的Agent系统设计一套靠谱的检索基准测试。文章里会覆盖为什么传统评估不适用、真实公司知识的乱具体长什么样、怎么构造评估集、怎么选指标以及我们实际跑benchmark时踩过的坑。适合正在做企业知识库Agent、RAG系统评估、或者想给内部知识工具引入更严格评测体系的工程师和算法同学参考。1.1 一个典型的翻车场景问题出在评估设计回到上面那个销售Agent。复盘时我们做了一个简单的压力测试把知识库里的文档全部倒进一个统一的测试集然后针对三个场景分别构造问题。第一个场景是标准问答问题本身写得干净答案集中在某一个文档片段里。比如我们给A客户的历史折扣是多少人工标好哪个文档哪一段是答案来源。用这套数据测系统的表现是不错的Top-5召回率接近85%。第二个场景是复合问题问题需要跨多个文档才能回答。比如对比A客户和B客户的续约条款差异答案需要从两份协议里分别抽取条款再对比。这时候系统的表现开始下滑Top-5召回率掉到了70%左右而且经常漏掉其中一份关键文档。第三个场景是真实使用中的模糊查询业务同事不会像测试集那样问得很精准而是问A客户那边的情况怎么样、最近的报价应该怎么给。这种问题本身充满了歧义需要Agent结合上下文猜测用户意图。测试结果惨不忍睹检索系统给出的Top-5片段里真正有用的可能只有一两个还常常被埋在不相关的内容中间。当时我们犯了一个典型错误用标准问答数据集的评测结果去推断真实Agent使用的效果。但Agent场景的数据分布完全不一样——模糊查询占大头、多文档复合问题比例高、知识库本身还有版本新旧和权限差别。用不匹配的benchmark测出来的分数自然无法反映真实效果。这也是这篇内容第一个想强调的结论评估Agent检索能力第一步不是选指标而是想清楚你的评测场景和真实使用场景是否吻合。场景不匹配后面所有的指标和调优都可能是自欺欺人。1.2 Agent对检索的容错率远低于人类用户还有一个更隐蔽的差异是容错率。人用搜索或知识库工具时检索结果只要差不多用户自己能判断哪条有用、哪条没用甚至能主动换关键词再搜一次。人有很强的纠错能力检索结果差一点最终效果也能补回来。Agent不一样。Agent的核心是自主决策它拿到Top-N个检索片段后一般会直接把这些片段放进上下文交给LLM推理。LLM的推理有一个特点它对上下文中的噪声非常敏感。如果检索结果里混入了高相关但错误的信息比如过期的报价、错误的版本条款LLM可能会一本正经地引用错误内容生成答案。这个过程没有人在中间把关错误会被直接放大到最终输出。我们在评测中还发现一个规律当Top-5里只有1条正确片段、其余4条都是干扰项时不同LLM的表现差异很大。有些模型能把正确信息挑出来并回答正确这类模型上下文鲁棒性好有些模型会被干扰项带偏。但检索系统本身并不知道下游模型是谁——同一个检索器配上不同模型最终效果天差地别。这意味着Agent场景下的检索评估不能只看检索结果本身有多准还要看这些结果对下游Agent决策的帮助有多大。单纯用检索阶段的命中率作为唯一指标忽略了LLM对检索结果的利用能力会高估或低估系统的真实能力。1.3 现有常见检索基准到底测不出什么这里顺便盘点一下常见的检索基准。像MS MARCO、Natural Questions、BEIR这类经典数据集对学术研究很有价值但它们和真实公司知识的Agent检索有几个关键差异第一文档分布不同。公开数据集里的文档一般经过清洗格式统一质量较高。真实公司知识库里有扫描版PDF、有PPT导出的图片、有几十年前的Word文档、有Excel表格、有飞书/Notion的导出页面甚至还有语音转文字的会议记录。这些文档的噪声水平远超公开数据集。第二问题分布不同。评测集里的问题往往人工精心构造表述清晰、答案唯一。真实使用中用户或Agent面对的问题往往模糊、嵌套、需要拆解。比如客户说价格太高想再谈谈我们有什么可以给的优惠空间——这个问题本身跨了销售策略、价格体系、历史案例三个领域不是一条检索就能解决的。第三信息冗余和冲突。真实知识库中同一主题通常对应多份文档而且里面的说法可能互相矛盾。公开数据集通常默认每道题对应一段正确答案很少处理同一问题有多个互相冲突的答案来源的情况。而这恰恰是真实企业场景的常态。所以说直接拿公开benchmark来评估Agent检索系统等于是用高考题去测一个在工地上干活的人——不是说没用而是场景错位得太厉害。为Agent场景设计检索benchmark第一步应该是设计场景而不是套指标。这个观点是这篇文章的核心主线后面的内容都是围绕这一点展开的。2. 乱才是常态真实公司知识的messiness拆解要在messy的知识库上做检索评估首先得把messy这个词拆明白。真实公司知识不像教科书——它不是一个干净的体系而是各种历史遗留、组织边界、人为习惯叠加出来的复杂产物。我在几个不同规模的公司知识库项目里摸爬滚打之后总结出真实公司知识混乱的几个主要维度。这些维度直接影响benchmark设计因为每个维度都需要在评测集里被采样到否则评测就会失真。2.1 载体形态的混乱远比你想象得严重先看载体形态。真实公司知识库的文档来源通常包括办公套件文档Word、PPT、Excel其中PPT尤其麻烦每页只有几句要点脱离上下文完全看不懂日历邀请和会议纪要通常不成文、口语化严重还有大量讨论后决定这种没有主语的话IM聊天记录导出碎片化程度最高一条消息往往只有几个字邮件归档包含大量转发链、签名档、历史对话正文和附件混杂老旧的内部Wiki页面很多是多年前写的格式混乱图片失效扫描件或图片转文字OCR的文档识别错误率高英文和数字常被识别错客户系统导出的结构化数据比如CRM里的字段备注一句话里塞进大量缩写不同载体形态对检索系统的处理要求完全不同。文本切分策略就是一个典型问题对PPT简单地按页切可能丢失上下文对IM聊天记录按消息切太碎按会话切又太长对邮件不处理转发链的话检索到的片段可能是别人的签名档。在benchmark设计时如果一个评估集只包含干净规整的文档就完全测不出检索系统应对这些复杂载体的能力。2.2 语义与上下文的割裂让相关变得很难定义第二个维度是语义割裂。公司知识里充满了内部上下文——术语、缩写、人名、项目代号。这些东西对外人来说是黑话但对公司内部员工来说是常识。举个例子一份文档里写Q3 P0项目需要KBU配合如果不知道KBU是某个业务单元这句话就是一堆字母。还有大量的指代现象文档里写着客户那边说同意我们的方案——客户是哪个客户方案是哪个方案这些信息在文档上下文里可能有也可能没有。语义割裂对检索评估最大的冲击是标注人员如果没有领域知识会很难判断一个检索结果到底相不相关。一段文本可能在字面上不包含查询关键词但经过推理它就是回答问题的关键依据。传统基于关键词匹配或字面语义相似度的标注方式在真实公司知识面前往往失效。2.3 知识的老化、矛盾与权限边界检索评估必须回答的问题第三个维度是知识的时间性和权威性。真实公司知识库里信息是分层级的有的文档是当前有效的制度有的是已被替代的草案有的是某次讨论的中间结论。一份文档在经过多次修订后旧版本不会自动消失而是静静躺在某个共享盘或协作工具的历史记录里。于是检索系统面临一个在公开数据集里几乎不存在的难题检索到的结果可能已经过期。系统需要判断文档的新旧、版本状态、甚至权威来源比如制度类信息应该优先引用正式发文而不是聊天记录里的一句讨论。在评估时如果不能对答案来源的时效性和权威性进行建模只是简单地看文本是否匹配就会出现检索得很准回答得很错的结果。权限边界也是真实场景里无法回避的问题。公司知识库的访问权限往往是按团队、层级、项目隔离的。同一个Agent服务不同团队时同一个查询在不同权限下应该检索到的内容范围不同。Benchmark如果忽略权限因素直接把全库作为候选集测出的检索能力在真实部署时可能完全不可用。我记得有一次我们在评估时遇到一个报错——public key retrieval is not allowed。那是在处理加密文档和访问控制时检索服务在拉取某些文档内容时被权限系统拦截。这个错误提醒了我们一件事真实环境中的检索永远是在权限约束下的检索评估集的设计也必须带上权限维度。员工的文档能否被检索到、能否被Agent引用本身就是检索系统能力的一部分。2.4 为什么公开数据集测不出messy问题的处理能力基于上面的拆解可以给出一个很清晰的结论公开数据集的文档经过数据清洗通常没有载体混乱、没有语义割裂、没有版本冲突、没有权限边界。用这样干净的数据测检索本质上测的是文本匹配能力。而真实公司知识场景需要的是在混乱中定位可信信息的能力。这两者之间差着好几个维度。这也是为什么我们需要一个专门针对messy real-world company knowledge的benchmark——不是为了跟别人的系统比分而是为了回答一个实际的问题当我给Agent接上一个真实的公司知识库之后它面对用户的任务请求到底能不能稳定、正确地找到应该依据的信息3. 构建针对乱的评估集数据、任务与标注方法聊完了为什么和乱在哪下面进入实操部分怎么搭建一套能真实暴露问题的benchmark。这部分我会讲评估集的数据来源、任务维度设计、标注方法三个层面。3.1 评估数据的选择宁缺毋滥但要覆盖混乱维度我们在做第一个版本时犯过一个很典型的错误为了追求数据量把知识库里所有文档都无差别地塞进评估集结果标注成本巨大而且很多文档根本没被真正用到。后来总结出几条实操原则第一选真实被问到的文档优先。从Agent真实使用日志中找出用户或Agent高频访问的文档和查询以这些为种子来构造评估集。这样保证评估集里的知识分布和真实使用场景一致。第二有意识覆盖混乱维度。评估集里不仅要干净的文档还要包含前面提到的各种类型会有PPT、会议纪要、邮件转发链、老旧文档、以及存在版本冲突的文档对。可以按比例控制比如60%常规文档、20%特殊格式、10%版本冲突场景、10%跨权限场景。第三设置不可答样本。真实知识库中有相当比例的问题其实是知识库里没有答案的。比如我们之前和某公司的分成比例是多少——知识库根本没有任何记录。传统检索评测很少包含这类unanswerable样本但对Agent来说正确地回答找不到相关信息和错误地给出猜测结果有天壤之别。评测集一定要加入合理比例的不可答问题才能真正测出系统的稳重程度。3.2 任务设计从单跳问答到多跳决策任务维度的设计是评估集的核心直接决定了你测的是检索的匹配能力还是Agent的信息利用能力。我们目前的评估集包含四类任务层层递进任务类型一单跳事实问答。问题可以直接在一段文档里找到答案特征是查得准不准。这类任务主要测基础检索能力也是传统评测的主力。虽然这类任务不能完全代表真实场景但它仍然是整个评估的地基。任务类型二多跳条件问答。回答需要结合多个文档的信息才能完成特征是找得全不全。比如2023年Q4我们与B供应商签署的合同里付款方式是哪种——需要先定位合同文档再结合合同条款判断。这类任务对检索系统的要求是多轮检索时每轮都不能掉链子。任务类型三时效性判断。知识库中存在多个版本或互相矛盾的文档模型需要判断在给定的时间上下文里哪个信息是有效的。比如我们现在的退款政策是什么——知识库里可能有2019版、2022版、还有某次讨论中提到的想改但没正式发布的版本。正确的答案应当基于最新生效版本。这类任务能直接测出检索系统对版本/时间维度的敏感性。任务类型四决策参考。没有唯一正确答案但Agent需要找出一组相关信息供决策参考。比如为了准备和X客户的续约谈判需要收集哪些背景信息和历史条款。这类任务最接近真实使用但也最难标注——没有标准答案只能从是否遗漏了关键信息来评判。这四个任务类型各有侧重但注意它们之间不是互相替代的关系。一个完整的benchmark应该包含全部四类这样能同时看到系统的匹配能力、召回能力、时效感知和信息完备性。3.3 评估集的质量保障标注、审核与去泄漏评估集的质量直接决定了评测结果的可信度。这里有几个很容易被忽略但极其重要的点。第一是标注规范。多跳任务和决策参考任务的标注难度远高于单跳问答标注人员需要具备领域知识。我们当时的做法是由有业务经验的人先标一轮再让领域专家审核一轮最后对不一致的部分进行仲裁。第二是数据泄漏问题。这一点在真实知识库场景中特别容易犯错——训练数据或索引数据如果不小心包含了评估集中的文档那检索得分会虚高到失真。我们踩过的教训是评估集必须从索引中完全剔除而且要用独立的文档存储空间。在评测不同版本系统时特别要注意旧版本的Agent是否在之前的实验中已经把评估集内容写入了上下文缓存。第三是需要做难度分层。评估集里的问题不能全都是简单问题或难题。我们使用的方式是让两个不同能力的检索器跑一遍评估集标注出那些强检索器能答对而弱检索器答错的问题作为困难样本并保证困难样本占比不过分偏低。否则整个评估集很容易出现一个现象所有系统得分都在90%以上无法区分优劣——这种评估集没有区分度对系统迭代的帮助接近于零。4. 评测指标怎么选检索分高不等于Agent好用评估集搭好之后下一个核心问题是指标设计。这个环节很能体现Agent场景检索评估和传统检索评估的分水岭。4.1 传统检索指标的幻觉在真实场景中可能失真最经典的检索指标是RecallK、MRR、NDCG。这些指标衡量的是正确答案是否出现在Top-K中以及排序的质量。它们有明确的数学定义也便于横向比较但在Agent场景下单用这些指标会遇到几个无法回避的问题第一个问题回忆一下前面强调过的真实公司知识里答案经常不是唯一的。多份文档可能给出不同甚至是矛盾的答案这时正确答案如何定义是全部算对还是只有符合当前版本的答案才算对如果按照后者那RecallK的位置标注就变成了一项需要领域知识判断的工作。第二个问题检索器返回了正确答案不代表Agent就能用它给出正确回答。有一类非常常见的情况是正确答案在Top-1但Top-2到Top-5里全是具有误导性的过期信息LLM最终被带偏输出错误答案。这种场景下传统的Recall1得分是满分但Agent的实际表现是失败的。评测分数和真实效果之间出现了巨大的鸿沟。第三个问题跨文档信息整合无法用传统指标衡量。多跳问题中单独看任何一个片段的排序都没问题但Agent需要的是这些片段之间的信息关系。传统指标无法衡量信息组合的效果。老实说我们在项目早期的评测中就被这些指标欺骗过——系统在指标上分数不错但实际使用时频繁出错。后来花了大量力气调整指标设计才逐步让评测结果和真实使用体验对齐。4.2 从检索得分到任务完成率把Agent的决策拉进评估闭环在经历了一轮指标失真的教训之后我们引入了一套新的评估框架——核心思想是从检索得分升级为任务完成率从片段级别评估升级为任务级别评估。这套框架包含三个层次的指标第一层是片段级别指标包括RecallK、MRR、NDCG。这一层指标不是没有用而是作为诊断工具使用——当系统的任务完成率不佳时通过这一层指标来定位问题出在检索阶段还是推理阶段。第二层是信息覆盖度指标。对于多跳任务和决策参考任务人工预先定义回答问题时需要收集的关键信息点必要信息项然后检查Agent最终回答中是否包含了这些信息点、是否有遗漏。这个指标可以认为是任务层面的召回率。第三层是任务完成率。对于每个评测问题定义成功标准一个二元判定Agent是否给出了符合要求的最终答案然后看整体通过率。例如对于单跳事实问答答案是否与标准答案一致用LLM裁判但因为答案是确定的可以用规则和模型结合判断对于时效性判断Agent是否正确选择了最新版本的信息来源对于不可答问题Agent是否明确说明信息不足而不是编造答案任务完成率是最终验收指标前两层指标是辅助排查指标。在实践中我们发现这个分层架构非常有用——既要看最终能不能做对也要在做不对时知道是检索还是推理的问题。只有一层指标的评测体系碰到问题就像黑盒排查效率太低了。4.3 上下文使用效率Agent场景独有的评测维度还有一个传统检索评估不太关注、但Agent场景非常关键的维度——上下文使用效率。Agent调用检索服务时返回的Top-K片段会全部塞进LLM的上下文窗口。片段越多、越长LLM的推理负担越大、延迟越高、成本也越高。更重要的是高噪声的长上下文还会稀释有效信息降低LLM的推理准确率。所以我们引入了两个指标一是必要信息浓缩率。衡量的是检索结果中真正被Agent最终回答利用的信息占检索结果总长度的比例。这个指标越高说明检索系统给的东西越精炼。在实践中我们发现同样的Recall水平下不同切片策略带来的信息密度可能差3倍以上。二是噪声敏感度。把正确片段随机噪声和正确片段高相似度但错误的干扰片段两种检索结果分别喂给同一Agent比较回答正确率的变化。变化越小的系统对噪声的鲁棒性越强。这个指标在benchmark设计中非常有价值因为它衡量的是检索系统在无法做到100%干净时的兜底能力。这三个层次的指标放在一起才能构成一个完整的Agent检索能力画像检索系统不仅要在标准情况下找得到还要在信息混乱的情况下找得稳并且能让Agent真正用得上。5. 跑benchmark时真正踩过的坑最后这部分我想分享一些实际的踩坑经验。这些坑很难从论文或文档里学到基本都是被真实项目教育之后才明白的。记录下来希望后人少走弯路。5.1 文本切分策略看似无关紧要实则决定性影响第一个影响巨大的坑就是切分策略。我们最开始用简单的固定长度切分比如按512个token切一段然后在评测中连续翻车。典型场景是这样的一次关于2023年华东区销售考核方案的查询正确答案明明在某个文档里但无论怎么调检索参数结果里就是找不到。后来人工检查发现这份文档是一个大表格里面混合了文字和结构化的数据。固定长度切分时把表格的行切得支离破碎——每一行前半部分在片段A后半部分在片段B两个片段单独看都无法构成完整的语义单元检索系统自然无法命中。后来我们试验了多种切分策略包括按标题结构切分、按段落切分、按语义边界切分以及针对表格进行结构化提取后再切分。最终效果差异很大。所以现在我们在benchmark设计中会单独把文档切分的合理性作为一个评估维度。具体做法是对同一份文档分别用不同切分策略索引然后比较同一组评估问题的得分差异。如果切分策略的改变能引起得分5个点以上的波动说明这个切分策略本身就是评估结果中的一个关键变量——不能简单当作预处理细节忽略掉。5.2 public key retrieval is not allowed权限带来的隐蔽坑第二个想说的坑是关于权限与加密文档的。标题里提到的某个热词某种程度上也反映了一个真实问题——在实际部署的检索系统中权限过滤、加密机制和检索服务常常会互相纠缠产生一些表面上很难定位的错误。举个例子在一次评估中某个团队的知识被加密保护检索服务的正常查询路径里拉取文档内容时会因为密钥管理策略返回public key retrieval is not allowed。我们最初的评测代码没有专门处理这类错误导致这些文档在检索结果中神秘消失看起来像检索效果差实际上是权限机制拦截了内容获取。这个错误既不在检索日志里暴露也不在评测报告的报错里体现排查了很长时间才发现根因。这类问题在benchmark设计中意味着两件事第一评估集一定要带上权限维度的样本并且要在评测方案里明确这些样本的检索过程是否被允许第二评测系统要有错误注入的检测机制——当检索服务因权限、加密、网络等原因无法访问某些文档时评测应该能明确记录是检索未命中还是检索被拦截否则会把系统问题误判为算法问题。从此以后我们把权限相关错误单独成一类日志在评测报告里分开统计不再混在未命中里了。5.3 评估集的脏与偏两个隐蔽失真的来源第三个坑是评估集自身的偏差。脏的问题在于标注不统一。我们的标注人员来自不同业务线对相关的定义不一致。两个人都标同一批问题最后仲裁率需要第三方定夺的比例逼近30%。后来我们录入了领域术语表和标注指南重新培训仲裁率才降到10%以下。这个数字提醒我们评估集本身是一个需要建设的数据产品没有严格的质量控制评测结果只能是一堆噪声。偏的问题在于覆盖不全。第一版评估集里我们漏掉了邮件转发链这类特殊格式文档结果整个系统在这类资料上的检索能力长期处于盲区直到有业务反馈查不到历史邮件才开始补救。这个教训告诉我们评估集的构建必须从真实使用日志驱动而不是从方便标注出发。凡是真实场景中出现过的文档类型、查询类型都要尽量在评估集中有对应样本。5.4 LLM采样随机性一个让A/B测试翻车的细节最后一个坑可能对正在做评估对比的人特别有价值——LLM的采样随机性会直接影响评测结果而且影响幅度远超多数人的预期。在同一组检索结果下同一个LLM的温度设为0.2时跑两次评测任务完成率可能波动3到5个百分点。这个波动幅度足以让两个系统的差异变得不显著——你辛苦做的优化可能被随机噪声掩盖了。为了对抗这个问题我们做了三件事第一在评测时对同一设置跑多次至少三次以上取均值或中位数而不是跑一次就下结论。第二对于确定性要求高的任务单跳事实问答、时效性判断我们直接在评测时给LLM设置更低的温度甚至用多次采样投票的方式获取答案。这类任务的得分差异应该主要来自系统能力而非采样运气。第三引入随机性下界的对照实验——先在完全固定的输入不调用检索器直接把正确答案硬编码进上下文下测一个LLM表现的下限和上限再测真实检索条件下的表现。如果真实表现已经很接近理想上下文表现说明检索系统已经不是瓶颈再优化检索效果有限。这个对照策略帮助我们更理性地判断优化的优先级。5.5 排名与选择最终评测结果怎么汇报才不算误导上面讲的都是工程细节最后想提一个结果汇报层面的建议——不要只汇报一个综合分数。我们的做法是将结论拆成三块汇报第一块是任务完成率总览按任务类型单跳、多跳、时效、决策参考分别汇报准确率这样能看到系统在哪类任务上偏弱。第二块是失败归因分析对每个失败样本判定失败原因是检索未命中、检索命中但被噪声淹没、还是LLM推理错误。第三块是维度诊断报告按文档类型、权限场景、时效性场景分别统计。这三块放在一起你才能对系统的真实能力有一个立体的、可信的了解而不是被一个漂亮的平均分欺骗。6. 再说点个人体会回头来看这个benchmark设计项目给我留下的最大体会其实是做Agent检索的评估最难的部分不在于设计精巧的指标而在于真实地还原使用场景。很多人一开始做评测会习惯性地先找一套现成的benchmark、跑一个熟悉的指标然后基于分数调优。但真实世界的知识检索尤其是公司内部的messy knowledge远不是一个问题-段落匹配的任务。它要求系统在混乱、冲突、过时、碎片化的信息中找出对当前决策真正有用的部分——这份能力只有通过还原真实场景的评估才能测出来。另外一个体会是评估工作应该是持续建设的而不是一锤子买卖。知识库在变、用户在变、Agent在变benchmark也需要跟着迭代——每过一段时间从真实使用日志里捞一批新问题补进评估集拿去重后替换掉已经饱和的旧问题。这样评测分数才有持续的指导意义。如果这篇文章能给你一个可落地的建议我想说如果你正在为自己的Agent系统搭建检索评估别急着选指标、跑分数。先花两周时间把你知识库里最乱的那部分挑出来构造一个让系统不那么好看的评测集。让评估集先难起来再谈怎么变好这条路径比反过来走要高效得多。以上是我在这个方向上踩过的一些弯路和攒下的一点经验。希望对大家有帮助。
