检索增强生成常被当作一项即插即用的能力：接入文档、建立索引、挂上问答接口，演示里对答如流。可一旦面向真实业务，召回质量却时好时坏。症结往往不在检索算法，而在被喂进去的数据本身。RAG 的本质是"从已有知识里找答案"，它的上限由知识的组织状态决定，而不是由平台能解析多少种文档格式决定。平台能把产品手册、技术文档、合同解析索引，不等于这些内容天然适合被检索。
数据治理之所以是前置条件，可以从三个层面理解。第一是沉淀问题：相关知识究竟已经整理成可检索的文档或结构化数据，还是仍散落在个别员工的经验里。没有沉淀，再强的引擎也无从检索。第二是时效与维护：数据靠什么机制更新、谁负责维护、过期版本如何剔除。当索引里混入大量旧版本，检索会把陈旧内容当作权威依据返回，形成看似合理实则失效的答案。第三是口径一致性：同一概念在不同系统中若存在冲突定义，检索命中的片段彼此矛盾，模型只能在噪声中拼凑结论。
这三点共同决定了召回质量，而召回质量又直接传导到业务后果。判断一个环节是否适合交给 RAG，关键不是技术跑不跑得通，而是检索出错时错误答案会带来多大代价。在责任判断、合规后果较重的环节，即便检索可用，也应保留人在环中：让系统承担信息整理和初步归纳，把判断依据连同原始数据一并呈现，由人做最终决定并留痕。这样既守住风险底线，人工反馈也能反过来修正数据与规则。
因此，对于数据零散、流程尚未稳定的领域，更稳妥的顺序是先治理数据、固化流程，再谈检索增强。文档是否结构清晰、版本是否可控、口径是否统一，这些看似琐碎的治理工作，恰恰是决定 RAG 能否真正产生价值的地基。先把数据理清楚，再上检索，远比先上系统、再回头补数据来得稳当。