"我换了个问法再问一遍，怎么这次就有答案了？"
如果你在使用企业知识库问答系统时遇到过类似的困惑，你不是一个人。RAG 系统的检索准确性问题，可能比想象中更普遍。
我们最近针对这个问题做了一些探索，发现了一些有意思的改进方向。
真实场景中的三个尴尬时刻
场景一：明明有，就是找不到
技术团队维护着一个完善的产品文档库，但客户经常反馈"系统回答不出来"。人工检查后发现，相关内容其实都在文档里，只是客户的提问方式和文档的表述不太一样。
比如客户问"如何配置数据同步"，文档里写的是"数据复制设置"。对人来说这是同一个意思，但对传统 RAG 系统来说，向量相似度不够高，就检索不到。
场景二：答案看起来对，但总觉得哪里不对
系统给出了一个看似详细的答案，但仔细核对文档后发现，有些细节是"编造"的（业内叫 hallucination）。问题是，普通用户根本分辨不出来。
这在 B 端场景尤其危险——客户可能会基于错误信息做决策，最后发现不对时，对产品的信任度就彻底崩了。
场景三：不知道该不该信
系统给了答案，但用户心里没底："这个答案靠谱吗？是从哪个文档来的？置信度有多高？"
传统 RAG 系统像个黑盒，用户只能选择"信"或"不信"。缺乏透明度的系统，很难获得用户信任。
这些场景的背后，是三个技术层面的问题：
- 检索召回不足 → 用户换个问法，检索结果就完全不同
- 答案质量难评估 → 不知道答案是真的准确还是"一本正经地胡说八道"
- 系统不透明 → 用户无法判断该不该信这个答案
我们的尝试：多检索 + 实时评估
针对这些问题，我们搭建了一个原型系统（MOI Assistant），核心思路是：既要扩大检索范围，又要量化答案质量。
方向一：用多种方式"理解"同一个问题
与其依赖单一的向量检索，不如用多种策略并行：
HyDE（假设文档增强）
系统先生成一个"假想的完美答案文档"，再用这个文档去检索。这样能找到那些"意思对但表述不同"的文档。
Multi-Query（多角度提问）
把用户的一个问题，自动改写成 3-4 个不同角度的提问，分别检索。比如"如何配置"可以改写成"配置方法""设置步骤""参数说明"等。
MOI（组合检索）
并行执行上述策略，然后把结果聚合去重。在我们的测试中，这种方法能检索到 200 个候选文档（传统方法只有 50 个），检索耗时约 2 秒（相比传统方法的 0.5 秒，增加了 1.5 秒）。
| 检索方法 | 召回文档数 | 检索耗时 | 相关性分数 (nDCG) |
|---|---|---|---|
| Dify (基础) | 50 个 | ~0.5s | 0.72 |
| HyDE | 50 个 | ~2.0s | 0.78 |
| Multi-Query | 150 个 | ~1.0s | 0.81 |
| MOI (组合) | 200 个 ⬆️300% | ~2.0s (+1.5s) | 0.85 ⬆️18% |
说明：MOI 方法通过并行化，在增加 1.5 秒的情况下，召回率提升 300%，准确率提升 18%。
方向二：给每个答案打个"信任分"
检索到文档后，我们加入了两个维度的实时评估：
幻觉检测（0-1 分）
用专门的 HHEM 模型检查"生成的答案是否和检索到的文档内容一致"。如果答案里出现了文档中没有的信息，分数就会降低。单次检测耗时不到 0.1 秒。
检索相关性（nDCG 评分）
使用 UMBRELA 标准，评估每个检索到的文档与问题的相关程度（0-3 分制），然后聚合成一个整体的相关性分数。对 10 个文档的评估耗时约 5 秒。
这些评估异步进行，30 秒内完成，不影响用户看答案的体验。用户可以实时看到：
- "这个答案的可信度是 0.92"（幻觉检测分数）
- "检索到的 10 个文档，平均相关性 0.85"（nDCG 分数）
- 每个文档的相关性评分和排序
效果如何？
我们在一个包含技术文档的测试环境中做了验证：
检索准确率明显提升
| 指标 | 传统方法 (Dify) | MOI Assistant |
|---|---|---|
| 召回文档数 | 50 个 | 200 个 (⬆️300%) |
| 检索耗时 | 0.5 秒 | 2.0 秒 (+1.5秒) |
| 准确率 (nDCG) | 0.72 | 0.85 (⬆️18%) |
核心收益：召回率提升 300%，准确率提升 18%，检索耗时仅增加 1.5 秒。
答案质量可量化
在 100 个测试问题中：
- 幻觉检测分数与人工标注相关系数 > 0.85
- 相关性评分能有效区分高质量和低质量的检索结果
- 评估在 30 秒内异步完成，不影响答案生成
最关键的是，用户终于能看到答案的可信度，而不是盲目相信或怀疑。
系统性能优化
| 性能指标 | 数值 | 说明 |
|---|---|---|
| 首字延迟 | < 1 秒 | 问题提交后，首字出现的时间 |
| 答案生成速度 | ~10 字/秒 | 流式输出，逐字显示 |
| 向量检索 | < 500ms | MatrixOne 数据库响应 |
| Rerank 处理 | < 200ms | GTE-Rerank 模型耗时 |
| 总响应时间 | 2-3 秒 | 完整答案生成的总时间 |
通过并行化优化，系统总响应时间从传统方法的 3-5 秒降低到 2-3 秒，效率提升约 40%。
多数据源检索效果对比
| 对比项 | 传统方法 | MOI Assistant |
|---|---|---|
| 查询次数 | 需要手动查询两次 | 一次查询完成 |
| 耗时 | 约 6 秒 | 约 3 秒 |
| 效率提升 | 基准 | ⬆️50% |
DEMO 演示截图
（支持知识库分类，并支持仅检索单一知识库）
（支持知识库分类，同时可对所有知识库进行统一搜索）
（MOI 针对解析&检索功能，进行了优化，从结果可看出，MOI 检索回答整体表现较好）
一些观察和思考
"多问几次"不应该是用户的必选项
理想情况下，用户不应该因为"第一次没检索到"就换个问法再试一次。多检索策略的目标，就是让系统主动帮用户"多问几次"。
透明度本身就是产品价值
B 端用户对"黑盒系统"天然不信任。让用户看到答案来源、相关性评分、可信度，这种透明度本身就能提升产品体验。
有测试用户反馈："即使答案不完美，但我能看到评分，就知道该不该深入核查，这个很有用。"
技术优化的目标是减少"不确定性"
RAG 系统很难做到 100% 准确，但可以通过技术手段，让"不准确的时候，系统知道自己不准确"。这种诚实，比虚假的自信更重要。
写在最后
RAG 系统的检索准确性，表面上是个技术问题，本质上是个用户信任问题。
当用户提问时，他们期待的不仅是一个答案，更是：
- 这个答案是对的
- 即使不对，我能知道它可能不对
- 我能理解答案从哪里来的
而 RAG 系统的优化不只是"调参数"或"换模型"，更需要底层基础设施的支撑。
MOI 的向量检索能力让我们可以在毫秒级完成大规模相似度计算；SQL 与向量的融合查询，让复杂的多条件筛选成为可能；而云原生架构带来的弹性扩展，让实时评估这种"额外计算"不再是性能瓶颈。
当基础设施足够强大时，上层应用才有空间去做更精细的优化。这只是开始。RAG 的想象空间还有很多，而 MOI 正在成为我们探索这些可能性的基座。
点击链接，查看【 MOI Assistant 】实景演示 DEMO https://www.bilibili.com/video/BV1sJSWBhEpd/?vd_source=0125861879b1b6dceb4e6b846abd4be7