RECTIFY: An Interactive Workbench for Post-Evaluation RAG Diagnosis, Repair, and Verification
Keerthana Murugaraj, Salima Lamsiyah, Martin Theobald
cs.SE
2026-09-15
卢森堡大学的RECTIFY把评测后的RAG案例路由到4大家族、23个修复切片,在100题合成基准上把修复决策从逐条检查压到2-3张卡,约少97%。
RAG评测器能标出检索弱、落地不稳、答案残缺、乱生成,却很少告诉开发者下一步改哪一块。失败若被当成一百个孤立bug,修复又慢又难审计。RAGXplain能给单条自然语言建议,Doctor-RAG能在agent轨迹里定位故障,都还没有把「同类失败捆成一张可审批的修复卡,再在沙盒里对比改前改后」。
卢森堡大学的RECTIFY补的是评测之后那一截:把已打分的案例变成可审计的修复工作流,人始终按批准键。
先把每条案例收成统一schema:问题、答案、检索上下文、可选金标、评测分数和诊断字段。主评测器是同一组作者的RAGVue,覆盖检索质量、相关性与完整性、严格忠实、校准。
进路由前有两道预过滤。正确拒答的不可答题直接放行;答案已经贴近金标且有检索依据的可答题也放行。剩下的按优先级落入四个宏家族:拒答、检索、落地、生成。拒答优先,因为「没证据还敢答」比检索噪声更危险;检索先于落地,因为证据又脏又少时谈忠实没有意义。家族内再切到23个细切片,例如R2噪声检索、R5多部分检索不足、S3证据没用上。一张切片对应一张模板修复卡:目标组件、建议改动、预期收益、代价、作用范围。开发者可改参数、批准或驳回,决定写入出处日志。可选沙盒会把补丁打到受影响案例上重跑,报告变好、不变、变差。
路由是确定性的,不是再调一个生成模型去猜根因。
评测在100道合成题上,语料是30篇关于10家虚构公司的短文档,84题可答、16题不可答。三种检索共用Mistral-7B做生成,也用它当RAGVue的12项指标裁判:BM25、all-MiniLM-L6-v2稠密、以及二者混合。
| 设置 | 最终待修案例 | 主导切片 |
| BM25 | 16 | R2噪声检索7, R5=3, S3=6 |
| Dense | 5 | R2=0, R5=4, S3=1 |
| Hybrid | 6 | R2=0, R5=1, S3=5 |
严格忠实从BM25的0.627升到稠密0.745、混合0.741;答案完整性从0.391到0.474/0.465。81题在三种检索下都不用修。原始指标扫描要看74-89条,预过滤后剩5-16条,切片再收成2-3张卡,按决策次数估计少97%。沙盒里,给7条BM25的R2加上重排序,7条全好;把R5的top-k从3加到6,8条里5好、2不变、1变差。
对已经在跑RAGAS、RAGChecker、RAGVue的团队,缺的往往不是又一个分数,是把分数变成「改重排序还是加top-k还是改提示」的可审批假设。RECTIFY把调试单元从单条案例换成切片级补丁,并坚持人工批准。它是渐进的工程工作台,不是新的生成架构。合成语料让金标文档和不可答题可控,换到企业知识库还要另测。
作者自己把系统定位为本地交互原型,不是生产优化器。23个切片写死,新架构或新领域要扩表。没有金标时预过滤会关掉,只靠评测信号诊断。生成器和裁判都是同一只Mistral-7B,分数可能互相吹捧。沙盒只展示了两张切片,R5已经出现1条回退,说明修复卡是待检验假设。附录里若干RAGVue指标名在HTML转换中对不齐,解读以正文表格为准。