|
|
这两年聊到大模型落地，RAG已经从“好主意”变成“默认选项”。但我越来越感觉，大家只盯着向量召回率、embedding 维度、chunk 大小在打转，却忽略了“新模型”和“向量数据库”的协同这件事：两者不是简单拼接，而是要彼此适配、互相牵引。
先说新模型。多模态、长上下文、工具使用能力都在快速演化。表面看，这些增强能弱化对外部检索的依赖，实际上恰恰相反：模型越强，越暴露出知识边界和事实时效性的短板，越需要检索把“可验证、可更新、可溯源”的证据喂进去。比如长上下文不是让你把全库塞进prompt，而是给更复杂的“检索-重组-对齐”留了空间；能用工具的模型，也更需要一个会“说话”的向量数据库，提供结构化的片段、元数据与评估信号，而不只是相似度打分。
向量数据库这边，同样在进化。纯ANN检索只能算基础设施。现在更重要的是：可教化的索引（支持多向量/多视角表示，如语义向量+关键词稀疏向量共检）、查询规划（先粗后细、多跳、多路召回）、以及和业务语义绑定的元数据过滤。很多团队一股脑儿把数据切成固定大小的chunk，这在新模型面前是浪费：更合理的是让数据库支持“语义片段化”和跨文档片段拼接，让上游模型能拿到完整论证链，而不是几段彼此孤立的文本碎片。
协同的关键在于接口和反馈回路。我的经验是，别把RAG当成一次性流水线，而要让模型能“回头”影响检索：用模型在生成阶段产生的证据缺口，驱动二次查询；用模型对片段可信度、时效性、冲突性的判断，反向标注检索样本；用用户的纠错信号更新索引与负样本库。好的向量数据库应该内置这些反馈入口：可快速重建或增量更新索引、支持片段级别A/B检索策略、提供检索日志用于离线难例挖掘。否则你的RAG只能停留在“把相邻段落塞给模型”的初级阶段。
另一个容易被忽视的点是表示层的协商。新一代embedding模型已经支持指令化、领域自适应和多粒度表示。与其在检索端死磕“最佳向量”，不如让模型与数据库说好
“协商语义”：检索时使用“问题导向”的查询向量，召回后在重排阶段引入“论证导向”的片段向量；还可以为不同任务维护多套子空间（事实查证、代码示例、操作步骤），由模型在查询规划里显式选择或混合。这种协商比单一向
一向量更稳健，因为它把“意图-证据-表述”拆开来优化。很多人把重排等同于BM25/融合打分，其实重排也该多模态：引入结构化特征（出处可信度、发布时间、跨来源一致性），加上“可证伪性”打分，把那些听起来对但无法核验的段落降权。
评估也要跟着升级。常见的Precision/Recall对业务不敏感，离线nDCG也难覆盖真实交互。更实用的是两层评估：检索层做“可证据回答率”（给定问题，是否能在Top-K里找到足以构成
完整回答）的片段），生成层做“可溯源正确率”（回答是否引用了足够且正确的证据）。这两层指标能把“检索够不够用”和“模型用得好不好”拆开看，便于定位瓶颈。此外，要加入时效性和稳健性测试：给同义改写、噪声干扰、过期信息注入的对抗集，观察检索与生成是否共同退化，退化在哪里。
落地路径上，我更推崇“以小带大”的演进式协同。先在单一高价值场景做端到端的闭环：选一个明确的任务（如客服知识问答里“退改签政策”），把数据治理好（来源分层、片段化策略、元数据规范），让模型与向量库围绕这个任务建立协商语义与反馈回路。跑通后，再横向复制到相邻任务，每次只扩一两种文档类型或一套子空间，避免一开始就做“通用RAG平台”却无人可用的陷阱。
最后说
最后说“成本与治理”。RAG的真正成本，不在于多跑了几次检索，而在于数据生命周期与回路维护：数据入库的清洗、去重、溯源；索引的增量更新策略；重排与提示词的版本管理；以及线上线下评估的一致性。我的做法是把“证据”当一等公民来管理：每个片段都有稳定ID、来源签名、时间戳与可视化预览；生成回答必须携带片段ID，便于复盘与回放；评估集里不只存问题与答案，还要存“期望证据集合”。这让你在模型或检索策略升级时，能精准量化改动带来的收益与回归，而不是靠主观感觉。
顺带点破一个误区：很多团队一开始就上最强的闭源模型，希望“以生成覆盖检索缺陷”。短 |
|
发表于 
微信公众号
官方抖音号