大模型落地卡在数据治理？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 向量库选型别一上来就上最贵的向量库这个事我的观点很明确先看数据量级和团队运维能力别被厂商宣传带偏。场景推荐方案理由数据量10万条快速验证本地文件内存索引如FAISS零运维跑通流程最重要10万-100万条单机部署轻量级向量库如Chroma、Milvus单机够用成本低100万-千万级生产环境分布式向量库如Milvus集群、Qdrant需要水平扩展和元数据过滤已有ES技术栈ES的向量检索能力复用现有运维体系减少学习成本我踩过的一个坑是早期为了技术先进直接上了分布式向量库结果数据量才几万条运维复杂度却上去了出问题排查半天。后来换成单机方案反而稳定。技术选型要匹配当前阶段不是越先进越好。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, metadatabuild_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结合做复杂任务编排、把多模态数据图片、表格也纳入检索范围。但那是另一个话题了先把当前这条链路跑稳比什么都重要。