小语料为什么不用向量检索？delivery-harness词法搜索背后的「傻瓜指数」与Milvus取舍（ADR-0003）

小语料为什么不用向量检索delivery-harness词法搜索背后的「傻瓜指数」与Milvus取舍ADR-0003【免费下载链接】delivery-harnessAI harness reference implementation for on-demand delivery workflows项目地址: https://gitcode.com/gh_mirrors/de/delivery-harness在 AI 应用里做知识检索很多人第一反应就是上 RAG嵌入embedding 向量数据库比如 Milvus。但delivery-harness——一个面向即时配送的 AI 参考实现——在 ADR-0003 里做了一个反直觉的决定语料库只有十几条规则时不引入向量检索而是用简单的词法搜索lexical search。这不是偷懒而是用「傻瓜指数」Idiot Index算出来的理性取舍。本文带你读懂这个决策背后的完整推理。一个没人调用的假向量检索是怎么进来的 事情的起点很有代表性。仓库最初提交里带了一个VectorSearchService对内存里的 map 跑一个余弦相似度循环代码注释写着「生产环境替换为 Milvus 客户端」路线图上还列着「embedding 生成 向量检索」。但没有任何代码调用它。真正在跑的检索逻辑是String.contains配着三个写死的固定分数规则 0.8、文档 0.6、案例 0.5。这个宣称的设计与实际运行的代码之间的落差自然会诱导出下一步把活干完嘛——生成嵌入、搭起向量库。ADR-0003 开宗明义地指出在这个体量下这一步是错的而且值得写下来免得将来有人默认就这么做了。配套的清理动作见 docs/adr/0001-delete-unreachable-code-before-adding-features.md那个从未被执行的VectorSearchService被直接删除而不是留作占位——因为它本来就不是真正向量库的写法留着也省不下未来的工作量。「傻瓜指数」一个成本收益公式专治过度设计 ADR 的结尾用了一个很形象的词idiot index傻瓜指数。它的思想很简单傻瓜指数 成本 / 收益分母你买到的东西是零分子付出的代价是实打实的——这就是无界的傻瓜指数。翻译成人话花真金白银第二模型依赖、冷启动流程、索引同步成本却换不来任何可度量的收益这笔账越算越亏。ADR 原文的判词是在当前语料规模下引入嵌入管线的傻瓜指数是无界的——成本是真实的而它能买到的分子是零。为什么小语料不用向量检索四个硬核理由 ✅先看前提这个语料库是一份政策集。项目启动时播种了 11 条规则和 8 个已解决案例数据文件 harness-core/src/main/resources/seed/rules.json 和 harness-core/src/main/resources/seed/cases.json。真实的运营方其赔付与归因政策也不会大出几个数量级——它必须是一份人能读完、能争论、能签字确认的文档规模上限就在几百条左右。在这个体量下四条理由逐条成立#理由说明1整个规则集塞得进 prompt检索在这里是优化项不是使能项2暴力扫描就是正确答案对几百条短字符串做全量打分只要微秒级向量索引存在的意义正是避免线性扫描——而这里线性扫描恰恰是最合适的数据结构3嵌入引入一整串新依赖第二个模型、冷启动步骤、需要与事实源保持同步的索引以及一类新故障政策文本改了、向量却没跟上4政策查找更像精确匹配COMP-001、超时30分钟以上是运营真实会用到的词词法匹配直接命中而最近邻搜索反而可能自信地返回一个错误的邻居词法搜索长什么样分词 词元重叠打分 删掉向量方案后RetrievalService 的实现朴素到近乎透明分词把查询按空格和标点逗号、顿号、分号等切成小写词元丢掉单字符tokenize打分一条记录的分数 它包含的查询词元占比overlap破平按来源类型加一点小权重rule 1.00 case 0.95 document 0.90只用于打破平局绝不让未命中的条目超过命中的条目。对比旧实现这一步是实质性修复详见 RetrievalScoringTest旧逻辑把整串查询当子串去匹配——任何包含多个词的查询包括工作流生成的所有查询都会失败旧逻辑里所有规则都是 0.8 分按分排序只复现出先规则、后文档、再案例的来源顺序分数不携带任何信息新逻辑下多词查询能命中分数真实反映匹配程度且不依赖任何模型即可测试——而它确实被测了。对外只有一个入口POST /api/v1/knowledge/searchKnowledgeController工作流分析订单时自动调用把命中的规则和案例写进 prompt。诚实的代价放弃的是什么 ADR 没有报喜不报忧明确列了两条负面后果没有同义/改写匹配。查出餐慢不会命中只写了备餐时间过长的规则。缓解手段是每条规则上的tags字段——由运营方亲手枚举重要说法。在百条级规模下这比 embedding 更便宜、更可审计中文不做分词只按空格和标点切分召回依赖查询与规则共享短语。在查询来自固定词表的机器生成场景下可接受若将来运营方开始自由文本搜索需要重新评估。这两条被明确写进了 README 的已知限制——诚实的取舍声明比含糊的高级检索更有价值。什么时候该重新考虑 MilvusADR 最有价值的部分之一是给出了可执行的再评估触发条件——而且要求带上数字再来语料库超过约1,000 条运营方自由文本搜索成为真实用例且有实测的词法匹配漏召回查询有度量证据表明检索召回不足导致了归因错误——而不是假设。三者都不成立之前嵌入管线在这里就只是一个成本真实、收益为零的方案。Roadmap 里甚至专门写了一条embedding 与向量检索在当前语料规模下刻意不列入。小结架构决策的示范样本 ADR-0003docs/adr/0003-no-vector-retrieval-at-this-corpus-size.md是一份很好的决策不做什么的范本用数字说话十几条规则 vs 上千条的再评估线用公式防杠傻瓜指数把成本 vs 收益变成可计算的东西闭环设计负面后果有缓解措施tags未来有条件有数字1,000 条、实测召回缺口。对新手来说它传递的工程直觉是技术选型没有先进即正确。几百条政策文档分词 包含打分就是最优解把 Milvus 留给你真正需要它的那一天。想亲手验证这套检索行为最快的方式是跑./mvnw clean verify看 RetrievalScoringTest 里的断言或者调用知识搜索接口观察分数如何随词元重叠变化。【免费下载链接】delivery-harnessAI harness reference implementation for on-demand delivery workflows项目地址: https://gitcode.com/gh_mirrors/de/delivery-harness创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考