在 QCon London 2026 上，Rabobank 的 AI Tech Lead Lan Chu 分享了一套已经在内部落地的 AI 搜索系统经验。这个系统服务超过 300 名用户，覆盖约 10,000 份文档，包括 PDF 和 PowerPoint 等常见办公资料，目标是帮助员工更快提取洞见、准备客户会议和完成知识查询。她给出的一个核心判断很直接：很多 RAG 系统在真实生产环境里出问题，并不是因为大模型不够强，而是因为索引和检索环节做得不够可靠。
典型架构看似简单，真实落地却很快变复杂
Lan Chu 将系统拆分为三个典型层次：首先是文档摄取，包括解析、切块、向量化并写入向量数据库；其次是检索与生成，从索引中找出相关片段，再交给大模型生成回答；第三是可观测性，对调用链路、检索效果和评估指标做持续监控。从概念图上看，这是一条很多团队都熟悉的标准 RAG 管线，但一旦进入生产环境，文档质量参差不齐、检索相关性不稳定、评估口径难统一等问题就会迅速显现。
检索质量决定了后续生成的上限
她特别强调，如果摄取阶段的解析和切块策略有问题，后面即便换更强的模型，也很难把结果完全补回来。企业文档往往格式复杂、结构不统一，内部知识还可能频繁变化，这意味着索引构建、元数据质量和召回策略都会直接影响答案质量。对外界常见的“模型升级就能解决问题”的乐观判断，她的经验更偏谨慎：检索层不稳定时，生成层得到的上下文本身就已经偏了。
可观测性和评估不能放到上线之后再补
另一个重要经验是，可观测性必须从系统设计阶段就一起考虑，而不是等出现问题后再补。团队需要持续监控检索命中、生成结果、调用链路以及评估指标，才能知道错误究竟出在文档摄取、检索排序还是模型回答。对于生产系统来说，这种拆解能力非常关键，因为只有明确知道哪一层出错，团队才可能系统性优化，而不是盲目堆模型或增加提示词。
生产级 RAG 的难点更接近信息工程，而不仅是提示词工程
这场分享传递出的信号很明确：当 AI 搜索系统真的进入企业日常工作流后，最难的部分通常不是让模型“看起来会答”，而是让整个知识检索链路长期稳定、可解释、可评估。对想把 RAG 从原型推进到生产的团队来说，Lan Chu 的案例提醒大家，真正拉开结果差距的，往往是文档治理、索引质量、检索策略和监控体系这些基础能力，而不只是模型参数规模。
