大模型落地卡在数据治理？RAG与Excel模板导入的工程实践

1. 从"数据喂不动模型"说起：大模型落地最真实的卡点

过去一年多，我参与过好几个企业级大模型的落地项目，从最早的"先跑个Demo看看效果"，到后来真正要上生产、要对接业务系统，中间踩的坑几乎都指向同一个地方——数据。模型本身的能力其实已经足够强了，不管是开源可私有化部署的，还是走API调用的，参数规模摆在那里，通用能力都不差。但一旦落到具体业务场景，比如让模型回答"我们公司去年Q3华东区的退货率是多少"这种问题，它就开始胡编乱造，或者干脆说"我无法获取实时数据"。

这时候大家才反应过来：大模型不是缺脑子，是缺"喂进去的料"。而这个"料"的质量、结构、更新频率、权限边界，恰恰就是数据治理要解决的问题。所以标题里说的"双向奔赴"，我理解不是一句漂亮话，而是两个系统在真实项目里互相倒逼、互相成就的过程——数据治理因为大模型的接入，第一次有了"必须做好"的紧迫理由；大模型因为数据治理的介入，才真正从"玩具"变成"生产力工具"。

这篇文章我想聊的不是概念科普，而是把我在实际项目里摸出来的东西摊开讲：数据治理到底要给大模型准备什么、RAG和向量库在其中扮演什么角色、Excel模板导入这种"土办法"为什么反而最实用、以及那些看起来很美但一上生产就翻车的坑。适合正在做企业大模型落地、或者被"数据治理"这四个字搞得头大的朋友参考。

2. 数据治理给大模型"供料"的四个硬性条件

2.1 为什么通用大模型直接问业务问题必然翻车

先把这个事情说透。大模型的训练数据是截止到某个时间点的公开语料，它不知道你公司内部的制度、流程、产品参数、客户名单。你问它"我们的报销标准是多少"，它只能根据训练时见过的"一般公司报销标准"来编一个听起来合理的答案。这不是模型笨，是它压根没见过你的数据。

有人会说，那我微调不就行了？微调确实能让模型"记住"一些领域知识，但微调有几个现实问题：成本高、周期长、数据一变就得重新训、而且微调后的模型容易"灾难性遗忘"——学了新东西把旧能力丢了。更关键的是，微调解决不了权限问题。你不可能给每个员工训一个专属模型，但每个员工能看的数据范围是不一样的。

所以主流方案就落到了**RAG（检索增强生成）**上：模型本身不动，在回答问题之前，先去你的知识库里检索相关内容，把检索结果作为上下文喂给模型，让它基于这些"证据"来回答。这样数据更新只需要更新知识库，权限控制也只需要在检索层做过滤。RAG这个词在热搜里出现频率极高，不是没道理的，它确实是目前企业落地最务实的路径。

2.2 数据治理要交付的四种"模型可消费"资产

那数据治理具体要交出什么东西？我在项目里总结下来是四类：

第一类是结构化的事实数据。比如销售报表、库存表、财务科目余额。这类数据的特点是精确、可计算，模型需要的是"能查"而不是"能读"。所以治理的重点是建好指标口径、做好维度对齐，让模型能通过工具调用（比如生成SQL）去查。

第二类是非结构化的文档知识。制度文件、操作手册、产品说明、合同模板。这类是RAG的主战场，治理重点是切分、清洗、打标签、建索引。

第三类是半结构化的模板数据。这就是热搜里提到的"以Excel模板数据导入的数据治理项目"——很多企业的核心数据其实就是一堆Excel，格式五花八门，但业务逻辑都在里面。这类数据的治理最考验工程能力。

第四类是元数据和血缘。模型回答问题时，最好能告诉用户"这个答案来自哪份文件、哪个版本、谁维护的"。这既是可信度问题，也是合规问题。

这四类资产不是并列关系，而是有层次的。结构化数据解决"准不准"，非结构化文档解决"全不全"，模板数据解决"接不接得上业务"，元数据解决"信不信得过"。

2.3 数据质量不达标时，RAG会以什么方式"报复"你

我见过最典型的翻车场景是这样的：知识库里有一份2022版的报销制度，还有一份2024版的，两份都进了向量库。用户问"出差住宿标准"，检索出来两段内容，一段说500，一段说800，模型一看上下文矛盾，要么随机选一个，要么把两个都列出来让用户自己判断。用户直接炸了："你们这个AI到底靠不靠谱？"

这就是数据治理没做好的直接后果。RAG不会帮你解决数据矛盾，它只会把矛盾放大。因为它的工作逻辑是"检索到相关内容就拿来用"，它没有能力判断哪份文件更新、哪份作废。所以治理阶段必须做的几件事：文档版本管理、失效文档下架、同一主题的内容合并去重、关键字段的结构化抽取。

还有一个隐蔽的坑：文档切分粒度。切太碎，检索出来的片段缺少上下文，模型看不懂；切太大，检索精度下降，还容易超出上下文窗口。我一般建议按语义段落切，单块控制在300到500字，同时保留标题层级信息作为元数据。这个参数没有标准答案，得根据你的文档类型实测调。

2.4 权限体系：RAG落地时最容易被低估的工程

权限这件事，Demo阶段没人管，生产阶段要人命。你想想，如果HR的知识库和研发的知识库都进了同一个向量库，一个普通员工问"公司薪酬带宽是多少"，检索层不做过滤，直接把HR文档捞出来喂给模型，模型老老实实回答了，这事故可就大了。

所以RAG的检索层必须和企业的权限系统打通。常见做法是在向量库里给每个chunk打上权限标签（比如部门、密级、角色），检索时先按用户身份过滤，再算相似度。这里有个工程细节：过滤和相似度计算的顺序会影响性能。先过滤再算相似度，召回率可能下降；先算相似度再过滤，可能算了一堆最后被过滤掉，浪费算力。我的经验是数据量在百万级以下时，先过滤再检索完全够用；上了千万级，就得考虑分库分索引或者用支持元数据过滤的向量数据库。

3. RAG、向量库、知识图谱：谁在什么场景下干活

3.1 RAG不是万能药：它的三个真实瓶颈

热搜里"rag瓶颈"这个词很实在。RAG用久了就会发现它有几个绕不过去的问题：

瓶颈一：多跳推理能力弱。用户问"我们哪个供应商的账期最长"，这个问题需要先查供应商列表，再查各自账期，再比较。RAG一次检索只能捞回相关片段，做不了这种链式推理。这时候就需要Agent或者工具调用，让模型分步去查。

瓶颈二：全局性问题答不好。用户问"这份合同的主要风险点有哪些"，RAG检索回来的可能是零散的几个条款，模型拼不出全局判断。这类问题需要预先做摘要或者用知识图谱来组织关系。

瓶颈三：检索精度依赖embedding质量。中文的embedding模型选择很关键，通用模型在专业领域（比如法律、医疗）表现会明显下降。我一般建议在目标领域语料上做一轮embedding微调，或者至少用领域数据测一下召回率再上线。

3.2 向量库选型：别一上来就上最贵的

向量库这个事，我的观点很明确：先看数据量级和团队运维能力，别被厂商宣传带偏。

我踩过的一个坑是：早期为了"技术先进"，直接上了分布式向量库，结果数据量才几万条，运维复杂度却上去了，出问题排查半天。后来换成单机方案，反而稳定。技术选型要匹配当前阶段，不是越先进越好。

3.3 知识图谱和RAG的分工：什么时候需要"上图谱"

热搜里"kg知识库、rag知识库和结构知识库区分以及应用场景"这个问题问得很好。我的理解是：

• RAG知识库擅长"找相关内容"，适合文档问答、客服助手。
• 知识图谱擅长"理清关系"，适合需要多跳推理、关系查询的场景，比如风控、供应链分析。
• 结构化知识库（其实就是数据库）擅长"精确计算"，适合报表查询、指标统计。

实际项目里这三者往往是配合的。比如一个企业智能助手，用户问"帮我分析一下A产品最近的销售情况"，系统可能需要：先用结构化查询拿到销售数字，再用知识图谱找到A产品的相关供应商和竞品，最后用RAG检索最近的客户反馈文档，综合起来给一个回答。这就是热搜里"多AI协作"和"ai agent"的实际含义——不是一个大模型包打天下，而是多个组件各司其职。

3.4 从"能答"到"答得对"：检索结果的重排与校验

检索出来一堆片段，直接塞给模型，效果往往一般。我一般会加一层重排（Rerank）：先用向量检索召回Top 20，再用一个交叉编码器模型对这20个片段重新打分，取Top 5喂给大模型。这一步能把准确率提升不少，代价是增加一点延迟。

再进一步是答案校验：模型生成回答后，用一个轻量模型或者规则去检查"回答里的每个事实是否能在检索结果里找到依据"。找不到依据的部分就标注"此信息未在知识库中找到来源"。这个机制在合规要求高的场景（比如金融、医疗）几乎是必须的。

4. Excel模板导入：被低估的数据治理"最后一公里"

4.1 为什么企业数据治理绕不开Excel

说个真实情况：我接触过的企业里，超过一半的核心业务数据最初都是以Excel形式存在的。销售台账、客户名单、项目进度、库存盘点，全是Excel。你可以说这不规范，但这就是现实。数据治理项目如果一上来就说"你们先把Excel都改成系统录入"，基本推不动。

所以务实的做法是：承认Excel是数据源，把治理能力做在导入环节。热搜里"以excle模板数据导入的数据治理项目或系统，应该拥有那些功能"这个问题，我按实际项目经验列一下必备功能：

• 模板版本管理：不同时期模板字段可能不一样，系统要能识别版本并做字段映射。
• 字段校验与清洗：必填校验、格式校验（日期、金额、枚举值）、去空格、统一单位。
• 重复检测与合并：同一客户多条记录怎么处理，是覆盖还是合并，要有策略。
• 导入预览与回滚：导入前让用户看到"将新增X条、更新Y条、冲突Z条"，导入后能一键回滚。
• 操作审计：谁在什么时候导入了什么文件，改动了哪些数据，全程留痕。

这些功能听起来不酷，但每一个都是实际项目里被用户追着要的。

4.2 导入管道的设计：从原始表格到向量库的完整链路

一条完整的链路大概是这样：

# 伪代码示意，实际项目按需调整 def excel_to_vector_pipeline(file_path, template_version): # 1. 解析Excel，按模板版本做字段映射 raw_df = parse_excel(file_path, template_version) # 2. 数据清洗：去空、格式化、枚举校验 cleaned_df = clean_data(raw_df) # 3. 重复检测：按业务主键去重 deduped_df = deduplicate(cleaned_df, key_fields=["客户编号"]) # 4. 结构化存储：写入业务数据库 save_to_db(deduped_df) # 5. 生成文本描述：把每行数据转成自然语言片段 text_chunks = row_to_text(deduped_df) # 6. 向量化并入库 embeddings = embed(text_chunks) vector_store.upsert(embeddings, metadata=build_metadata(deduped_df)) # 7. 记录血缘：这份数据来自哪个文件、哪个版本 log_lineage(file_path, template_version, len(deduped_df))

这里有个关键设计决策：要不要把结构化数据也转成文本进向量库？我的经验是，如果这些数据需要被"问答式检索"，那就转；如果只是用来做精确查询，那走SQL就行，不必进向量库。两者都做也可以，但要保证数据一致性——数据库更新了，向量库也得同步更新，否则就会出现"模型说的和报表对不上"的尴尬。

4.3 模板治理的坑：字段漂移、编码混乱、合并单元格

Excel导入的坑，我随便说几个都是血泪：

合并单元格是解析噩梦。一个"华东区"合并了五行，解析出来只有第一行有值，后面四行是空的。处理办法是解析时做"向下填充"，但这又可能把本来该空的字段填错。我的建议是：在模板规范里明确禁止合并单元格，从源头解决。

字段漂移是指同一个业务含义，不同部门用不同字段名。销售叫"客户名称"，财务叫"客户全称"，运营叫"客户"。导入时必须做字段映射表，而且这个映射表要可配置、可维护，不能硬编码。

编码问题主要是中文乱码，尤其是从老系统导出的CSV。统一用UTF-8处理，遇到GBK的先转码再解析，这个在代码里加一层检测就行。

4.4 导入之后：怎么让模型"知道"这批新数据

数据导进去了，向量库也更新了，但模型怎么知道有新数据？这里涉及索引刷新策略。全量重建索引成本高，一般用增量更新：新数据插入时同步写入向量库，删除时标记失效而不是物理删除（保留审计能力）。同时要在元数据里记录"数据生效时间"，检索时可以按时间过滤，避免旧数据干扰。

还有一个细节：导入后的数据要能被检索到，embedding必须和检索时用的模型一致。我见过一个项目，导入时用A模型做embedding，检索时配置成了B模型，结果检索出来的东西驴唇不对马嘴，排查了两天才发现是模型不一致。这种低级错误，恰恰是最容易犯的。

5. 私有化部署与微调：什么情况下值得做

5.1 私有化部署的决策线：数据敏感度和调用成本

热搜里"企业大模型私有化部署"和"ollma部署大模型"（应该是Ollama）出现频率很高。我的判断标准很简单：

• 数据绝对不能出内网：那就必须私有化，没得商量。
• 调用量极大，API成本扛不住：算一下账，如果每月API费用超过自建GPU集群的折旧+运维成本，就值得私有化。
• 需要深度定制：比如要在模型层面做特殊处理，私有化更灵活。

但私有化不是没有代价。GPU采购、模型选型、推理优化、版本升级，每一项都是持续投入。我见过一些团队，私有化部署完之后发现效果不如预期，因为选的开源模型能力不够，又不会调优，最后还不如直接用API。所以私有化之前一定要做POC，用真实业务数据测效果，别光看榜单分数。

5.2 微调 vs RAG：不是二选一，而是分层配合

经常有人问"我到底该微调还是该做RAG"。我的答案是：大部分场景先做RAG，微调作为补充。

RAG解决的是"知识注入"问题，微调解决的是"行为对齐"问题。比如你希望模型回答时总是用某种格式、总是先给结论再给依据、总是用特定的行业术语，这些是微调擅长的。而"我们公司的产品参数是什么"这种知识性问题，RAG更合适，因为数据会变，微调跟不上。

如果两者都做，一般是先RAG跑通，收集bad case，看看哪些是知识缺失（补RAG），哪些是风格不对（做微调）。微调数据就从真实bad case里构造，这样最有的放矢。

5.3 微调实战里最容易被忽略的三件事

第一，数据质量比数量重要。几百条高质量的对齐数据，效果可能好过几万条噪声数据。构造微调数据时，宁可少而精。

第二，评估集必须独立。训练集、验证集、测试集要严格分开，而且测试集要覆盖真实场景的各种问法。我见过训练时loss降得很好，一上真实场景就露馅的，就是因为测试集太"干净"了。

第三，微调后的模型要重新测RAG效果。微调可能改变模型对检索上下文的利用方式，原来RAG效果好的，微调后可能变差。所以每次微调后都要跑一遍端到端评估。

6. 那些让我熬夜排查的坑：RAG生产环境实录

6.1 检索"看起来对"但答案错：一次完整的排查链路

有个项目上线后用户反馈："问A产品的保修期，AI回答3年，但实际是2年。"我按这个链路排查：

第一步，看检索结果。把用户问题拿去检索，Top 5片段里确实有一段写着"保修期3年"，但那是B产品的文档，因为A和B的产品名很像，embedding没区分开。

第二步，看元数据过滤。发现检索时没有按产品ID过滤，只做了语义相似度。这是设计缺陷——产品问答场景必须带产品ID过滤。

第三步，看文档切分。B产品的文档里，"保修期3年"和产品名不在同一个chunk里，导致检索时只匹配到了保修期那段，没匹配到产品名。

第四步，修复方案：一是检索时强制带产品ID过滤；二是调整切分策略，保证产品名和关键属性在同一个chunk；三是加一层重排，用交叉编码器提升区分度。

这个案例说明，RAG的问题往往不是单点问题，而是检索、切分、过滤、重排多个环节叠加的结果。排查时要一层层看，别急着改模型。

6.2 向量库更新延迟导致的"答非所问"

另一个坑是数据更新了，但用户还是得到旧答案。排查发现是向量库的索引刷新有延迟，写入后要等几分钟才能被检索到。对于时效性要求高的场景（比如库存查询），这个延迟不可接受。

解决方案是读写分离+缓存失效策略：写入时同步更新一个"最新数据缓存"，检索时先查缓存，缓存没有再走向量库。同时给用户一个"数据更新时间"的提示，让用户知道当前答案基于什么时间点的数据。

6.3 多轮对话里上下文把检索带偏

多轮对话时，用户第二句可能说"那它的价格呢"，这个"它"指代上一轮的产品。如果直接把这句话拿去检索，肯定检不到东西。所以需要查询改写：用大模型把"那它的价格呢"改写成"A产品的价格是多少"，再去检索。

这个改写步骤很关键，但也很容易出错。改写过度会丢失原意，改写不足则检索不到。我的经验是给改写模型明确的指令和几个示例，并且保留原始查询作为兜底——如果改写后的检索结果为空，就用原始查询再检一次。

7. 我个人的几条实操建议

先说一个反直觉的结论：数据治理项目里，最难的从来不是技术，而是让业务部门愿意配合。你技术方案再漂亮，业务不给你数据、不确认口径，照样推不动。所以我的第一条建议是：先找一个业务痛点明确、配合意愿高的场景做试点，做出效果再推广。别一上来就搞全公司数据治理，那是给自己挖坑。

第二条，RAG的效果评估要建立常态化机制。上线不是终点，要持续收集bad case，定期跑评估集，监控检索召回率和答案准确率。我一般会建一个"问题日志"，把用户问过的、答错的都记下来，每周复盘一次，这比任何自动化指标都管用。

第三条，别迷信"一键式"方案。市面上很多产品宣传"上传文档就能用"，实际用起来你会发现切分不对、检索不准、权限没有。数据治理和RAG落地一定是需要工程投入的，没有银弹。

最后分享一个小技巧：在知识库文档的元数据里加一个"可信度"字段，比如官方制度标"高"，员工手册标"中"，论坛讨论标"低"。检索时优先召回高可信度的内容，低可信度的作为补充。这个简单的策略能显著提升答案的可靠性，而且实现成本极低。

这个方向后续还可以扩展的地方很多，比如把用户反馈闭环接进来做持续优化、把RAG和Agent结合做复杂任务编排、把多模态数据（图片、表格）也纳入检索范围。但那是另一个话题了，先把当前这条链路跑稳，比什么都重要。