ARTICLE · 1225289
企业文档问答答不准?先定位断点,再选技术
从检索优化到知识维护：企业非结构化资料的 RAG 架构取舍｜企业知识技术系列
几乎每家企业都积累了大量文档——内部制度、操作手册、会议纪要、项目材料，其中大部分分散在各个部门乃至个人手中。企业初期想做知识管理，往往先靠网盘或集中存储把它们管起来；但真要用的时候，拿到资料的人仍要自己验证有效性：这份是不是现行版本？不同版本之间说法有没有冲突？面对纷乱的非结构化资料，访问者要自己弄清在哪里、是什么、为什么。
大模型应用的出现，抬高了人们对文档知识访问的期望。提问的人不再满足于找到原文，而是直接向系统要答案，还要附上出处。
追根究底，这些问题本质上在大模型出现之前就存在。大模型改变的是，使用者把这份期望整个交给了应用——原本由人完成的核对与判断，成了应用架构必须解决的难题。
本文讨论非结构化资料的加工、检索与维护：在大模型应用场景下，这些架构选择该如何判断、如何有效利用。
一、基础 RAG 让文档可问，却还不能保证答案有效
大模型应用刚出现时，需求很具体：让模型回答时用上企业自己的真实文件，而不是凭训练印象"编"答案。RAG（检索增强生成）就是为此而来：把大模型与可检索的外部资料连接起来，按问题取回相关内容，再组织成有依据的回答[1]。
常见做法分两条链：
离线建索引：解析文档、切分、计算向量并建立索引； 实时问答：查索引、取回原文片段，交给模型组织答案。
系统不会每次都把整份文件塞进模型。预先给文档建索引，是信息检索的基本功[2]；RAG 新加的环节，是让模型依据检索片段直接组织回答，而不是只返回一份文件列表。
图1｜基础 RAG 的两条链路。答案若要显示出处，还须把来源位置随片段保留下来，并在生成与展示环节正确引用；接上向量库不等于自动可信。
如果资料范围本身收得住，回答只需要依托少量原文片段，这套方案就很好用。企业起步阶段完全可以先做基础能力：让模型能检索到原文，不用一上来就搭知识图谱、知识页，搞很重的内容编排。
但它的局限也很清晰：基础 RAG 只管"能不能读到资料"，不判断"这份资料算不算有效"。向量检索能匹配到看上去相关的条款，却经常忽略文号、版本、特殊例外。搜到一段相关文字，不等于证据链完整、足以作答。到底要补什么能力，要看问题卡在哪个环节。
二、从基础 RAG 往外长：为不同问题组合不同能力
那我们就把落地时真实碰到的问题摊开来看。基础 RAG 落地之后，检索侧反复出现三类问题：
找不准：文号、专有名词、条款号这类精确信息，只靠语义相似度容易漏； 跨文档关系连不起来：片段各自孤立，增加召回数量也组不成逻辑链； 结果不可靠：材料找到了，但没有机制检查证据能不能支撑回答。
对应的解法差别很大：有的改索引，有的提前梳理加工文档，有的增加证据校验环节。很多 RAG 综述习惯把方案分成基础、高级、模块化[3]。站在建设者视角，更实用的思路不是跟着分类走，而是对照故障找对策。下面我们逐个拆解。这些能力可以自由组合，没有固定上线顺序，不是必须一步步安装的升级包。
还有一类高频情况：用户的问题本身过于复杂，单次检索根本答不全。这不属于检索本身的缺陷，放在本节最后单独说明。
1）找不准，先改检索。文号、专有名词和条款号，单靠语义相似度容易漏。入库时，可为片段同时建立向量和关键词索引，并保留来源、版本等元数据。提问时，视情况改写问句或生成多个问句（Query Rewrite、Multi-Query），再按元数据限定范围。
两类索引可并行召回、融合结果，必要时再重排（Reranking）。微软的混合检索文档展示了这一路径[4]，具体场景不一定要把所有步骤都接上。
图2｜同一批资料可建立向量与关键词索引；查询时并行召回、融合结果，必要时再重排。图中只展开混合检索，不代表所有增强能力都必须串在这条路径上。
同一批资料准备不同索引，再按问题选择召回路径，是老的工程判断。关系数据库的查询优化[5]和传统全文检索[6]都做过类似取舍；向量检索加入后，单一路径仍难兼顾文号匹配与语义理解。
2）需要跨文档追关系，就要提前加工。一项制度引用哪份操作规范，规范又把责任分给谁？扩大召回数量，未必能把这些片段连起来。以微软的 GraphRAG 实现为例：入库时从文本中抽取实体和关系，形成可查询的关系资产[7]；提问时再利用这些资产，结合原文或摘要组织证据[8]。
图3｜关系资产须先形成，查询时再利用关系与原文共同取证。图中只画出这一类查询机制，不代表所有 GraphRAG 方法都采用相同算法；有关系索引也不等于完成企业本体建模。
3）结果找到了，还要检查能不能用。这一类的问题不是"找不到"，而是"没有验收环节"。CRAG（Corrective Retrieval Augmentation）的思路是在检索之后加一道质检：先用轻量评估器判断取回的材料够不够格，不够就触发补救，比如改写查询或换来源再查[9]；Self-RAG 更进一步，让模型在生成过程中自我反思——这个问题该不该检索、取回的材料可不可信、答案有没有依据[10]。目前它们都还是研究贡献，不是开箱即用的组件，但方向已经清楚：证据不足要能被发现。只是这些机制再多，也不能替企业确认资料本身是否仍然有效。
资料包含复杂表格或图片时，解析与检索也要跟着调整。若主要事实在业务数据库中，就要另做数据访问与口径控制；本文聚焦非结构化资料。
另外还有一类场景，不属于单次检索不准。比如提问"新版制度对比旧版，在准入条件、审批例外、生效日期上分别做了哪些调整？"这类问题一轮检索很难直接给出答案，需要拆成多个子问题（Query Decomposition），并行或者迭代检索（Iterative Retrieval）之后再合并证据。
它要解决的是"一次检索不够"，而不是"单次检索召回不准"。Adaptive-RAG 根据问题复杂度选择执行路径[11]、Agentic RAG 将检索作为工具做策略编排[12]，本质上都是查询规划能力：在问题层面做调度，而不是优化底层检索组件本身。
回头看这一节：混合检索要先建不同索引，GraphRAG 要先加工关系——检索越增强，入库端预先要做的工作越多；CRAG、Self-RAG 再在查询端补上检查。两端都越来越强，资料的冲突、失效和更新，却仍可能无人处理。
三、找齐材料仍可能答错：把知识整理前移
我们再往前推一层：同一项政策，分散在旧手册、会议纪要、新版通知里，出现三种不一样的表述。哪怕所有相关材料都完整召回，只靠文本相似度，依然判断不出哪一份才是现行有效版本。
举个典型场景：准入审批规则散落在 3 份制度、2 次专题纪要里。新版本制度更新了门槛，但没人把汇总口径同步维护。RAG 每次被提问都现场拼材料，这次人工修正了答案，换一个提问角度、隔几天再问，错误仍会再次出现。反复优化召回和排序，解决不了版本效力认定、冲突裁决和持续更新的问题。
本质上，我们缺少一套固化的判定标准，大量本该提前完成的知识梳理，都推迟到用户提问时才临时处理。
将整理工作前置，可以实现三个价值：不用每次提问都重新判定内容有效性；已修正的结论能够沉淀，避免同类错误反复出现；所有判定规则权责到人，支持追溯审计。
前置加工并不是新思路。数据分析领域一直沿用这套做法：提前清洗数据源、固化业务口径，不让查询引擎自行推断含义[13][14]。数据仓库的物化视图也带来启示：预计算的内容必须跟随源数据同步刷新，查询再快，过期结果依旧不可信[15]。RAG 体系本身也是一样：基础 RAG 提前建索引，GraphRAG 预先抽取实体关系、生成摘要[7]。先加工、再查询，本就是数据领域成熟的思路，只是企业文档知识场景，过去普遍缺失这一环。
Karpathy 提出的 LLM Wiki 构想[16]，将只读原始资料、模型维护的 Wiki 知识页、约束页面结构与流程的 Schema 三者解耦。新资料入库后，模型可更新摘要、实体条目与交叉引用，主动识别冲突、过期表述。该构想最初面向个人知识库，尚不能直接当作成熟的企业通用架构。
本文用"知识编译"概括这套思路：如同源码编译为可执行程序，一次性加工，后续反复复用。落地方式是：针对高频咨询、需要跨文档整合的主题，提前生成附带原文锚点的主题页、概念页或实体页；有新资料流入时，触发复核与修订。"知识编译"是本文自创概括，并非 LLM Wiki 的原生术语。
企业可以双轨并行：原文检索索引 + 可维护知识页。简单问题直接检索原始文档；高频、需要多份材料交叉印证的主题，提前维护知识页，并保留指向原始资料的溯源链接。知识页不能替代原文；模型归纳产出的页面，也需要按风险等级完成人工复核，再开放使用。
图4｜知识页先作为候选内容，经校验或按风险审核后发布；使用反馈进入待核查队列，不从答案自动回写。这是知识加工前移的架构示意，并非某个 LLM Wiki 项目的实现图。
LLM Wiki 原生面向个人知识库，并非偶然：那里环境宽松，边生成、边修订，错了自己承担。
企业的制度解释和合同知识没有这种宽容度——模型产出的每一页，都要能回答：来源是哪一版？谁能确认、谁能看？何时失效？冲突由谁裁决？Markdown、向量库、图数据库可以记录和实施部分控制，却不能替企业作出这些决定。
知识加工与运营由此进入架构视野；至于这些环节在整体架构中如何落位、由谁负责——正是下一节要展开的。
四、落回非结构化知识架构：把复杂性放在哪一段
梳理至此，可选能力构件包括：原文索引、混合检索、关系资产、知识页。它们并不互斥，一套系统可以按需组合：原文索引支撑常规问答，混合检索处理精准匹配，少量知识页承接高频综合主题，关系资产只在核心场景落地。所有选择的核心取舍只有一个：治理动作放在文档入库阶段、提问阶段，还是人工复核阶段。
落到选型上，先看反复出现的故障形态。如果答案依托少量原文片段就能支撑，那么可靠的解析、准确的溯源记录加上基础检索，往往就足够。
如果召回片段跑偏，优先排查切分策略、元数据、权限范围，再考虑关键词检索、问句改写或者结果重排。材料已经找齐，但回答依旧残缺，就要评估是否需要拆解问题、多轮补查并组织证据；证据不够时，应当支持拒答，不强行输出结论。
如果跨文档关联问题反复出错，再权衡预构建关系资产的收益与长期维护成本。过时条款总是被误引，先梳理版本效力、明确裁决责任人；只有同一个主题持续需要反复整合多源信息，才考虑落地专人维护的知识页。
当系统直接输出结论时，信息检索与文档管理、数据库与数据仓库这两类经验，需要协同发挥作用。原本由查阅者自行完成的核验工作，转移为系统取证与知识持续维护的责任。
架构上至少可以拆成四个环节：
资料加工：解析文档、切分、标注来源与版本，按需抽取关系或者生成待审核知识页； 知识资产存储：保存原文与检索索引，也可存放领域关系、已经审核生效的知识页； 查询取证：根据问题调用资产，串联证据，组装回答； 反馈维护：核查错误、冲突与过期信息，确认后更新知识资产。
权限与责任机制贯穿全部四个环节。
图5｜原始资料、文本索引、按需建设的关系资产与知识页共同构成供查询使用的材料；权限、来源、版本和 Owner 贯穿其中。反馈先核查，再更新资产。这是逻辑总览，不是 UML，也不是完整企业知识平台。 图中的“外部 LLM 服务”为示意名称，模型也可在企业内部部署。
本文讨论范围仅限非结构化知识的取证与问答。如果需要查询订单状态、发起审批、变更业务数据，仍然要对接业务系统里的权威数据、规则、流程与权限；RAG 和知识页本身无法承载这类业务操作。
五、结尾：先定位反复出错的环节，再选技术
全文走完一条完整路径：基础 RAG 让模型用上企业文档；混合检索、多步检索和结果检查，补齐取证的不同短板；GraphRAG 在关系问题上增加结构化取证；LLM Wiki 提示，一些知识值得在提问之前组织。这些能力构件可以组合，没有一套全装上的标准答案。但贯穿始终的主线只有一条：当系统开始代人回答，原本由人完成的核对与判断，就成了架构的责任——检索、取证、维护，都是这份责任的不同落点。
企业要决定的，是哪些资料保留为可检索原文，哪些关系值得提前加工，哪些知识需要长期维护，以及谁对它们的有效性负责。
不妨记录最近几次错误答案：错在召回、证据组织、查询规划，还是资料本身未被确认和更新？先定位断点，再决定是否增加技术组件。否则，再复杂的查询链路，也可能只是在一次次替混乱的知识源头补课。
你的文档问答系统，现在卡在哪一段——召回、证据组织，还是版本治理？欢迎留言说说场景，下一篇挑典型场景展开。
参考文献
[1] Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（RAG 原始论文，Lewis 等） [2] 斯坦福《Introduction to Information Retrieval》在线版，倒排索引构建章节 [3] Retrieval-Augmented Generation for Large Language Models: A Survey（RAG 综述） [4] Azure AI Search 混合检索说明（微软） [5] Access Path Selection in a Relational Database Management System（System R 查询路径选择，Selinger 等） [6] Apache Lucene [7] GraphRAG 索引说明（微软） [8] GraphRAG 查询说明（微软） [9] Corrective Retrieval Augmentation（CRAG） [10] Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection [11] Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity [12] Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG [13] ETL/ELT 架构说明（微软 Azure 架构中心） [14] Fabric 语义模型说明（微软） [15] Oracle 物化视图说明 [16] Karpathy：LLM Wiki 构想（gist）
