Omar Baruzzo

建立基线的方法是：从真实问题中选取约五十个问题写出标准答案，用全文搜索加结构化过滤跑一遍并记录正确结果数量，该数字即为基线。

收集用户真实问题并分类统计后发现，相当大比例的问题属于指向性检索，例如合同编号、客户名称、日期区间、物料编码、人名。

向量索引本质上是文档的一份副本，需要与数据源保持同步，更换embedding模型时需要重建整个索引，且必须执行与原系统相同的访问权限控制。

没有基线时，增加向量搜索只能叫“变化”，不能叫“改善”；任何新增技术方案必须能超越基线才称得上改进。

Baruzzo的论述不是反对向量搜索本身，而是关于做事顺序：先建立可测量基线，让错误类型驱动技术决策。

构建RAG助手时，团队通常第一反应是部署向量数据库，但Omar Baruzzo建议先用已有的搜索能力打好基线，让评估数据决定何时真正需要embedding。

Baruzzo 明确表示这些论点不是反对向量检索，而是反对将向量检索当作起点的顺序，向量更适合作为基线失效时的补丁。

在构建 RAG 助手时，应先用已有的全文检索和结构化过滤建立评估基线，再根据评估数据决定是否引入向量检索，而非一开始就接入向量数据库。

建立基线的方法是为约五十个真实问题写下期望命中的答案，然后用全文检索加结构化过滤运行，记录准确返回的问题数量作为基线。

之后添加的任何检索方案都必须能超过基线数字，否则不能称为改进，只能叫变化。

向量检索的适用场景是词汇鸿沟，即用户查询词与文档用词不一致导致关键词检索漏召回，例如用户问“如何在到期前终止租约”而文档写“提前解除租赁合同”。

引入向量索引会增加维护负担：副本必须和源数据保持同步；嵌入模型更换时需要重建整个索引；副本必须执行和原系统完全一致的访问权限。