一个央企知识库项目让我看到了AI落地的复杂先交代背景我去年底参与了一个央企集团级知识库项目目标是把它沉淀多年的制度文件、技术标准、项目文档、历史档案做成一个能“问一句就给答案”的AI知识库。项目不算大预算不算少周期将近十个月。做下来最深的感受是AI落地这件事真正的复杂度从来不在模型本身而在模型前面那些看起来不AI的环节——数据、组织、权限、链路、评测、运维。这篇文章就是我个人在项目里的完整复盘包括踩坑、选型思路和一些可以直接复用的操作经验。如果你接下来要做企业级知识库尤其是面向央国企这类对安全、权限、可靠性要求极高的场景这篇内容应该能帮你省不少时间。1. 这个项目到底在解决什么问题1.1 需求方眼里的“简单”和交付方眼里的“复杂”项目立项时候业务方的预期很直观把集团内部的制度文件、技术规范、历史项目报告整理到一起员工通过一个对话入口就能查到“出差报销标准是多少”“某型号设备的维护周期是什么”这类问题。在他们看来这就像把文件放进一个网盘再加一个机器人聊天框没理由做不出。但实际上这背后的链路长到超出大多数人想象。我先列一下项目真正要处理的几层内容数据层文档格式五花八门PDF、Word、Excel、扫描件、老旧的图片型档案甚至有一部分是带有密级标识的制度文件。组织层集团总部、二级单位、三级单位不同组织对同一份文件的访问权限不同同样是制度文件有些面向全员有些只允许特定岗位查看。语义层不少问题是跨文档的比如“某个项目的结算流程合规吗”需要把合同模板、审批制度、历史案例、财务规定串起来才能回答。交付层必须私有化部署不能走公有云API模型能力受限国产化环境要求还需要有完整的审计记录。从这时开始我就意识到这不是一个“RAG框架套上去就行”的项目而是一个涉及知识治理、权限模型、检索优化、生成控制、部署运维的系统工程。知识库只是外壳内核其实是组织知识资产的数字化治理。1.2 为什么传统搜索没有解决偏偏要上AI央企内部其实早就有了OA系统、文档管理系统、甚至专业的档案系统搜索功能也都存在但使用率一直不高。原因很现实传统搜索是“关键词匹配”员工得知道文件里大概有什么词才能搜到而员工实际提问是“我要报销流程是什么”这两者之间的语义鸿沟非常大。AI知识库的核心价值就是把“关键词匹配”升级为“语义匹配”让用户用自然语言提问系统去理解意图并召回相关文档片段。听起来不难但当你面对的不是几百篇文档而是十几万份文件、几十个业务系统导出数据的时候语义匹配的稳定性就会成为最大的问题。后面我会详细讲我们是怎么通过混合检索和重排模型去解决这个问题的这些都是方案设计阶段就要想清楚的事。2. 数据治理知识库落地的第一道坎2.1 文档“丢进去就行”是一句非常危险的话很多项目组在启动时会忽略一个事实知识库的效果上限取决于喂给它的文档质量。集团给我们的初始数据里PDF占了大约六成但其中超过三分之一是扫描件没有文本层还有一部分是从老系统导出的Excel表一张表里塞了两三种结构表头还不在第一行。如果直接把这些数据切块后灌入向量库结果会很酸爽——检索时召回的片段全是乱码、残缺表格和OCR错字。我们第一批内测语料就是这么做的测试集命中率不到四成相当惨。所以开工之后我们花了将近一个半月专门做数据清洗和结构标准化工作内容包括扫描件OCR识别用PaddleOCR做文字识别针对部分清晰度低的档案做了图像增强处理提高识别率。格式统一把所有文档转成统一的文本格式并保留结构标签如标题、段落、表格、页眉页脚。表格重结构化将Excel和Word中的表格解析为Markdown表格文本方便后续Embedding模型理解结构语义。密级和权限字段抽取从文档目录和文件属性中提取密级、适用范围、所属部门等元数据。这一套做下来数据质量才勉强够用。一个很深的体会是知识库项目的前半段通常不是AI项目而是数据治理项目。不要觉得这部分工作没技术含量——恰恰相反它直接决定了后面算法环节的天花板。2.2 Chunking切片的尺寸决定了检索的天花板数据清洗完之后下一步是决定怎么把文档切成知识片段。这个环节看着简单藏着的坑却不少。切片策略主要考虑三个因素模型支持的输入长度、检索召回粒度、语义完整性。我们当时用的Embedding模型支持最长512个token所以最开始设的是每段256个token、重叠32个token。结果内测发现像“报销标准”这种带有明确数值和条件的段落被切碎后经常把数额和适用条件拆到两个片段里导致回答缺失关键约束。后来我们把策略改成“结构感知切片”优先按文档的标题层级切分每个二级标题下的内容作为一片若内容过长再按段落拆分尽量保证一段完整的语义单元落在一个chunk里。用这种方式检索命中率明显提升尤其是制度类文档效果比固定长度切片好很多。补充一个实操建议切片时一定要保留文档的元数据标签比如“来源部门”“文档编号”“密级”“发布时间”。这不仅是权限过滤的需要也是回答里做引用溯源的基础。我们一开始没把“发布时间”纳入检索过滤条件后来问“现在出差住宿标准是多少”系统经常把五年前已经废止的标准召回出来教训很大。2.3 表格数据单独走一条处理通道央企知识库里表格类内容非常多设备参数表、费用标准表、审批权限表、项目进度表。表格这种结构化数据直接转成文本丢进向量库效果非常差——因为文本化之后的表格行与列的对应关系很容易丢失。我举个例子一张“差旅费报销标准表”包含“职级、城市类别、住宿标准、交通标准、伙食补助”五列。转成纯文本后Embedding模型很难学到“副总经理在北京市的住宿标准是500元”这种多列组合关系。用户问“处长在北京出差能住多少钱一晚的酒店”系统可能召回整张表但答案片段里没有准确的对应关系大模型就容易胡编。我们的处理方案是把表格转成Markdown格式后单独建立一套结构化知识索引同时在检索链路中增加一个“表格识别”分支——当判定用户问题涉及数值、条件、规则类信息时优先走结构化检索通道返回精确行数据而不是通篇向量检索。这个改动上线后标准类问题的准确率提升了将近20个百分点。3. RAG链路与Agent化改造3.1 关键词混淆与混合检索的必要性知识库的问答不是简单的“向量检索大模型生成”两步走。向量检索擅长语义相近但对精确关键词不敏感而央企文档里大量信息是靠“编号”“标准号”“部门名称”来区分的。比如“根据Q/SY 0381-2020标准执行”和“根据Q/SY 0381-2017标准执行”语义几乎一样但完全是两个版本用纯向量检索很容易把旧版本也召回。我们最终采用的是混合检索方案向量检索和BM25关键词检索并行各自取回TopN结果然后进行结果融合。融合算法用的是RRFReciprocal Rank Fusion对两条召回结果做加权排序。BM25保证精确编号和术语的匹配向量检索兜底语义泛化两者互补之后召回质量才明显稳定下来。这里有个细节值得说混合检索不是简单地把两路结果拼在一起而是要调整权重。我们的配置是向量检索Top50、BM25检索Top30RRF后取Top10送入重排模型。为什么取这么多因为后面还有一次精排前面的召回要“宁滥勿缺”防止漏掉正确答案。3.2 重排模型被很多人低估的一环项目中期我们做过一次对比测试不加重排链路直接取混合检索Top5送入大模型准确率大约在62%加上重排模型对混合检索Top10进行精排后取Top5同一测试集准确率提升到79%。这个提升幅度接近17个百分点远超我们预期也让我彻底意识到重排不是“可选优化”而是RAG链路里极其关键的一环。重排模型做的事情很简单对召回的候选片段逐一计算与用户问题的语义相关度重新排序让最相关的片段排到最前面。它能有效纠正向量检索带来的“表面相关、实际不相关”问题。选择重排模型时我们比较过几款最终选了BGE-Reranker系列主要是考虑到私有化部署环境对模型体积有限制这个模型在效果和资源占用之间比较均衡。推理服务用FastAPI封装成一个独立的rerank服务和主服务通过HTTP调用。提示如果你计划在项目里加重排一定要在方案阶段就预留GPU资源而不是等项目上线前才补。重排模型虽然不大但推理频率高吃GPU显存不是小数目。3.3 多跳问答如何让Agent拆解复杂问题知识库上线第一周就暴露了一个之前没测透的问题用户问的很多问题不是单片段能回答的。比如“我们签订的某项目合同结算需要经过哪些流程涉及哪些部门”这个问题至少涉及合同审批制度、结算流程规范、部门职责分工三份文档。用传统的“召回一个片段、生成一个答案”模式只能回答其中一部分回答得又碎又浅。我们后来引入了一个轻量级Agent方案思路是三步意图识别先用大模型判断问题是一个单跳问题还是多跳问题。子问题拆分如果是多跳问题把原问题拆解成若干独立子问题比如上面的例子就拆成“合同结算流程是什么”“审批过程中涉及哪些部门”“流程中的关键节点有哪些”。分步检索与汇总每个子问题走一遍检索重排拿回答案片段最后统一汇总生成最终答案。这个Agent不能复杂越复杂越容易失控。我们用的是一个很简单的状态机逻辑最多拆分三个子问题每个子问题检索Top5汇总时只基于检索片段二次生成不允许模型无中生有。这样既解决了复杂问题又保证了可控性。3.4 幻觉控制宁可说“不知道”也不要编央企场景对AI知识库的要求和面向C端聊天机器人完全不同。制度问答里如果模型给出一个错误的标准数值轻则报销被打回重则可能引发合规问题。所以我们在“幻觉控制”上花了很大的精力核心策略是限制生成来源强制引用。具体做法有三条所有回答必须基于检索到的片段生成Prompt里有硬性约束“如果给定材料中找不到答案必须回答‘未在现有知识库中找到相关信息’”。大模型输出答案时必须标注来源文档编号和原文片段引用方便用户回溯验证。对制度标准类问题采用“抽取式摘要式”混合策略涉及具体数值、编号、条款的内容直接从原文片段抽取不经过大模型二次转述。这套规则下来测试集的“无中生有”类错误从7.2%降到了1.1%左右基本实现了“可控”。虽然牺牲了一定程度的流畅性但在企业场景里准确性远比文采重要。4. 权限、私有化和上线后运维的复杂4.1 央企的权限矩阵比技术方案复杂得多如果说数据和链路层面的复杂度是技术性的那权限体系就是组织性的。知识库里既有面向全员公开的制度文件也有只允许二级单位分管领导查看的内部材料甚至还有部分标注“内部资料不得外传”的历史档案。如果权限在检索阶段没有生效任何一个不该看到内容的员工问到敏感信息都是重大事故。我们在实施中把权限体系拆成两层文档级权限每一份文档入库时打上权限标签包括可见范围全员/某部门/某职级以上和密级标识。检索级过滤用户发起检索请求时系统根据用户身份部门和职级实时计算可见文档集合检索时只对这个子集进行向量匹配和关键词匹配而不是全量库。这个设计听起来简单实际落地时遇到了不少麻烦。最典型的问题是一份文档被引用到另一份文档中可见范围到底以哪份为准比如一份公开制度里引用了某份内部标准文件用户问起这个引用条款时系统会不会把内部标准也输出出去我们的方案是“引用隔离”检索片段中如果包含对其他文档的引用信息且用户对该文档无权限则回答中自动隐藏引用细节只保留当前可见内容。牺牲了一点完整性换来了安全合规的底线。4.2 模型私有化部署不是“装个模型”那么简单由于数据不能出域整个AI链路必须在央企的内网环境私有化部署。这涉及Embedding模型、重排模型、大语言模型三个推理服务的搭建每一步都有坑。先说大模型选型。我们评估过几款开源模型在央企知识问答场景下的表现最终选了Qwen系列中尺寸适中的版本原因是它在中文理解、指令跟随、抽取能力上比较均衡而且中文社区资料丰富遇到问题好排查。模型量化使用的是INT8把显存占用压下来一半多点速度提升了接近30%效果损失在可接受范围内。这里给一个显存计算的参考公式模型推理显存 ≈ 参数(GB) 激活显存(约参数量的20%左右) 推理缓存一个7B模型FP16权重约14GBINT8量化后约7GB再加上KV Cache和激活值单卡16GB勉强够单实例跑。我们当时为了并发稳定用了一张24GB的卡跑大模型重排用一张消费级卡就够Embedding模型对资源要求最低CPU推理也能跑。整个部署采用Docker Compose编排各服务独立容器统一走内网API网关。注意不要在一开始就追求最大模型。知识库问答中绝大部分问题都是抽取和改写不需要特别强的复杂推理能力。一个大而全的模型不仅部署成本高推理速度慢还容易在细节上过度发挥反而不利于精确控制。4.3 评估、回灌与效果迭代上线才是开始项目上线后我们持续做了三个月的运营监控发现线上用户问的问题和测试集差距非常大。测试集里我们问的是“《采购管理办法》中超过多少金额需要招标”而用户实际问的是“我们部门买个服务器是不是一定要走招标流程自己招标行不行”。前一个是单点查询后一个是实际业务推理问题难度高了一个量级。为此我们建立了一套评估回灌机制每周从线上对话日志中抽取出回答质量差的问题人工标注正确答案。将标注数据加入测试集重新跑检索和生成评估看效果变化。每周更新一次Embedding模型的重训练数据可选或调整切片和检索策略。对反复出错的问题人工补充知识文档把隐含的“多文档推理”变成更细粒度的知识片段。这套闭环跑起来之后线上问答好评率明显上升。一个直接感触是知识库不是建完就能完事的它更像一个有生命的系统需要持续喂数据和反馈才能维持效果。5. 常见问题速查与经验总结最后整理几个我们项目里最具代表性的问题和处理办法供参考问题典型表现排查思路我们的解法召回相关但答案不对能检索到文档但给出的片段不是精确答案检查切片是否破坏语义单元尝试结构感知切片按标题层级切片表格单独结构化答案编造事实模型输出看似合理但原文没有缺少引用约束生成温度过高强制引用抽取值类信息温度调低旧版本文档被召回标准或制度更新后仍答旧版缺少时间过滤加入发布时间元数据和检索过滤条件权限泄露风险无权限用户检索到受限内容检索阶段未过滤权限文档级权限标签检索子集过滤引用隔离长文档找不到答案问题涉及全文多处信息单段召回不完整Agent拆分问题分步检索汇总并发一高就超时大模型推理耗时过长显存不足、推理配置差INT8量化、加大显存、服务化拆分经验层面上我真心建议后面做类似项目的团队在立项时就把下面三件事谈清楚数据质量是最大的交付物。不要急着上模型先花时间把文档清洗、切片、元数据标注做扎实否则后面每一步都是返工。明确权限和合规边界的责任人。技术方案能做的事只是“按权限标签过滤”标签和权限规则需要业务方明确拍板项目经理和法务或保密办共同确认。评测集建设是保命手段。不要凭感觉说效果变好了建立一份覆盖常见场景的测试集每次改动都跑一遍所有优化过程全部数据化。我在实际操作中还有一个体会央企知识库这类项目和互联网产品的AI落地是两个物种。互联网产品追求“惊喜感”回答越聪明越好央企知识库追求“确定感”回答越稳越好、越能追根溯源越好。项目后期我们把Prompt和链路反复“做笨”效果反而越来越好。做AI落地方案最大的本事是在花哨和稳重之间找到那条适合业务场景的线而不是一味堆新技术。希望这次的复盘能帮你在踩坑之前就绕过这些泥潭。
央企知识库实践复盘：AI落地的复杂远不止模型本身
一个央企知识库项目让我看到了AI落地的复杂先交代背景我去年底参与了一个央企集团级知识库项目目标是把它沉淀多年的制度文件、技术标准、项目文档、历史档案做成一个能“问一句就给答案”的AI知识库。项目不算大预算不算少周期将近十个月。做下来最深的感受是AI落地这件事真正的复杂度从来不在模型本身而在模型前面那些看起来不AI的环节——数据、组织、权限、链路、评测、运维。这篇文章就是我个人在项目里的完整复盘包括踩坑、选型思路和一些可以直接复用的操作经验。如果你接下来要做企业级知识库尤其是面向央国企这类对安全、权限、可靠性要求极高的场景这篇内容应该能帮你省不少时间。1. 这个项目到底在解决什么问题1.1 需求方眼里的“简单”和交付方眼里的“复杂”项目立项时候业务方的预期很直观把集团内部的制度文件、技术规范、历史项目报告整理到一起员工通过一个对话入口就能查到“出差报销标准是多少”“某型号设备的维护周期是什么”这类问题。在他们看来这就像把文件放进一个网盘再加一个机器人聊天框没理由做不出。但实际上这背后的链路长到超出大多数人想象。我先列一下项目真正要处理的几层内容数据层文档格式五花八门PDF、Word、Excel、扫描件、老旧的图片型档案甚至有一部分是带有密级标识的制度文件。组织层集团总部、二级单位、三级单位不同组织对同一份文件的访问权限不同同样是制度文件有些面向全员有些只允许特定岗位查看。语义层不少问题是跨文档的比如“某个项目的结算流程合规吗”需要把合同模板、审批制度、历史案例、财务规定串起来才能回答。交付层必须私有化部署不能走公有云API模型能力受限国产化环境要求还需要有完整的审计记录。从这时开始我就意识到这不是一个“RAG框架套上去就行”的项目而是一个涉及知识治理、权限模型、检索优化、生成控制、部署运维的系统工程。知识库只是外壳内核其实是组织知识资产的数字化治理。1.2 为什么传统搜索没有解决偏偏要上AI央企内部其实早就有了OA系统、文档管理系统、甚至专业的档案系统搜索功能也都存在但使用率一直不高。原因很现实传统搜索是“关键词匹配”员工得知道文件里大概有什么词才能搜到而员工实际提问是“我要报销流程是什么”这两者之间的语义鸿沟非常大。AI知识库的核心价值就是把“关键词匹配”升级为“语义匹配”让用户用自然语言提问系统去理解意图并召回相关文档片段。听起来不难但当你面对的不是几百篇文档而是十几万份文件、几十个业务系统导出数据的时候语义匹配的稳定性就会成为最大的问题。后面我会详细讲我们是怎么通过混合检索和重排模型去解决这个问题的这些都是方案设计阶段就要想清楚的事。2. 数据治理知识库落地的第一道坎2.1 文档“丢进去就行”是一句非常危险的话很多项目组在启动时会忽略一个事实知识库的效果上限取决于喂给它的文档质量。集团给我们的初始数据里PDF占了大约六成但其中超过三分之一是扫描件没有文本层还有一部分是从老系统导出的Excel表一张表里塞了两三种结构表头还不在第一行。如果直接把这些数据切块后灌入向量库结果会很酸爽——检索时召回的片段全是乱码、残缺表格和OCR错字。我们第一批内测语料就是这么做的测试集命中率不到四成相当惨。所以开工之后我们花了将近一个半月专门做数据清洗和结构标准化工作内容包括扫描件OCR识别用PaddleOCR做文字识别针对部分清晰度低的档案做了图像增强处理提高识别率。格式统一把所有文档转成统一的文本格式并保留结构标签如标题、段落、表格、页眉页脚。表格重结构化将Excel和Word中的表格解析为Markdown表格文本方便后续Embedding模型理解结构语义。密级和权限字段抽取从文档目录和文件属性中提取密级、适用范围、所属部门等元数据。这一套做下来数据质量才勉强够用。一个很深的体会是知识库项目的前半段通常不是AI项目而是数据治理项目。不要觉得这部分工作没技术含量——恰恰相反它直接决定了后面算法环节的天花板。2.2 Chunking切片的尺寸决定了检索的天花板数据清洗完之后下一步是决定怎么把文档切成知识片段。这个环节看着简单藏着的坑却不少。切片策略主要考虑三个因素模型支持的输入长度、检索召回粒度、语义完整性。我们当时用的Embedding模型支持最长512个token所以最开始设的是每段256个token、重叠32个token。结果内测发现像“报销标准”这种带有明确数值和条件的段落被切碎后经常把数额和适用条件拆到两个片段里导致回答缺失关键约束。后来我们把策略改成“结构感知切片”优先按文档的标题层级切分每个二级标题下的内容作为一片若内容过长再按段落拆分尽量保证一段完整的语义单元落在一个chunk里。用这种方式检索命中率明显提升尤其是制度类文档效果比固定长度切片好很多。补充一个实操建议切片时一定要保留文档的元数据标签比如“来源部门”“文档编号”“密级”“发布时间”。这不仅是权限过滤的需要也是回答里做引用溯源的基础。我们一开始没把“发布时间”纳入检索过滤条件后来问“现在出差住宿标准是多少”系统经常把五年前已经废止的标准召回出来教训很大。2.3 表格数据单独走一条处理通道央企知识库里表格类内容非常多设备参数表、费用标准表、审批权限表、项目进度表。表格这种结构化数据直接转成文本丢进向量库效果非常差——因为文本化之后的表格行与列的对应关系很容易丢失。我举个例子一张“差旅费报销标准表”包含“职级、城市类别、住宿标准、交通标准、伙食补助”五列。转成纯文本后Embedding模型很难学到“副总经理在北京市的住宿标准是500元”这种多列组合关系。用户问“处长在北京出差能住多少钱一晚的酒店”系统可能召回整张表但答案片段里没有准确的对应关系大模型就容易胡编。我们的处理方案是把表格转成Markdown格式后单独建立一套结构化知识索引同时在检索链路中增加一个“表格识别”分支——当判定用户问题涉及数值、条件、规则类信息时优先走结构化检索通道返回精确行数据而不是通篇向量检索。这个改动上线后标准类问题的准确率提升了将近20个百分点。3. RAG链路与Agent化改造3.1 关键词混淆与混合检索的必要性知识库的问答不是简单的“向量检索大模型生成”两步走。向量检索擅长语义相近但对精确关键词不敏感而央企文档里大量信息是靠“编号”“标准号”“部门名称”来区分的。比如“根据Q/SY 0381-2020标准执行”和“根据Q/SY 0381-2017标准执行”语义几乎一样但完全是两个版本用纯向量检索很容易把旧版本也召回。我们最终采用的是混合检索方案向量检索和BM25关键词检索并行各自取回TopN结果然后进行结果融合。融合算法用的是RRFReciprocal Rank Fusion对两条召回结果做加权排序。BM25保证精确编号和术语的匹配向量检索兜底语义泛化两者互补之后召回质量才明显稳定下来。这里有个细节值得说混合检索不是简单地把两路结果拼在一起而是要调整权重。我们的配置是向量检索Top50、BM25检索Top30RRF后取Top10送入重排模型。为什么取这么多因为后面还有一次精排前面的召回要“宁滥勿缺”防止漏掉正确答案。3.2 重排模型被很多人低估的一环项目中期我们做过一次对比测试不加重排链路直接取混合检索Top5送入大模型准确率大约在62%加上重排模型对混合检索Top10进行精排后取Top5同一测试集准确率提升到79%。这个提升幅度接近17个百分点远超我们预期也让我彻底意识到重排不是“可选优化”而是RAG链路里极其关键的一环。重排模型做的事情很简单对召回的候选片段逐一计算与用户问题的语义相关度重新排序让最相关的片段排到最前面。它能有效纠正向量检索带来的“表面相关、实际不相关”问题。选择重排模型时我们比较过几款最终选了BGE-Reranker系列主要是考虑到私有化部署环境对模型体积有限制这个模型在效果和资源占用之间比较均衡。推理服务用FastAPI封装成一个独立的rerank服务和主服务通过HTTP调用。提示如果你计划在项目里加重排一定要在方案阶段就预留GPU资源而不是等项目上线前才补。重排模型虽然不大但推理频率高吃GPU显存不是小数目。3.3 多跳问答如何让Agent拆解复杂问题知识库上线第一周就暴露了一个之前没测透的问题用户问的很多问题不是单片段能回答的。比如“我们签订的某项目合同结算需要经过哪些流程涉及哪些部门”这个问题至少涉及合同审批制度、结算流程规范、部门职责分工三份文档。用传统的“召回一个片段、生成一个答案”模式只能回答其中一部分回答得又碎又浅。我们后来引入了一个轻量级Agent方案思路是三步意图识别先用大模型判断问题是一个单跳问题还是多跳问题。子问题拆分如果是多跳问题把原问题拆解成若干独立子问题比如上面的例子就拆成“合同结算流程是什么”“审批过程中涉及哪些部门”“流程中的关键节点有哪些”。分步检索与汇总每个子问题走一遍检索重排拿回答案片段最后统一汇总生成最终答案。这个Agent不能复杂越复杂越容易失控。我们用的是一个很简单的状态机逻辑最多拆分三个子问题每个子问题检索Top5汇总时只基于检索片段二次生成不允许模型无中生有。这样既解决了复杂问题又保证了可控性。3.4 幻觉控制宁可说“不知道”也不要编央企场景对AI知识库的要求和面向C端聊天机器人完全不同。制度问答里如果模型给出一个错误的标准数值轻则报销被打回重则可能引发合规问题。所以我们在“幻觉控制”上花了很大的精力核心策略是限制生成来源强制引用。具体做法有三条所有回答必须基于检索到的片段生成Prompt里有硬性约束“如果给定材料中找不到答案必须回答‘未在现有知识库中找到相关信息’”。大模型输出答案时必须标注来源文档编号和原文片段引用方便用户回溯验证。对制度标准类问题采用“抽取式摘要式”混合策略涉及具体数值、编号、条款的内容直接从原文片段抽取不经过大模型二次转述。这套规则下来测试集的“无中生有”类错误从7.2%降到了1.1%左右基本实现了“可控”。虽然牺牲了一定程度的流畅性但在企业场景里准确性远比文采重要。4. 权限、私有化和上线后运维的复杂4.1 央企的权限矩阵比技术方案复杂得多如果说数据和链路层面的复杂度是技术性的那权限体系就是组织性的。知识库里既有面向全员公开的制度文件也有只允许二级单位分管领导查看的内部材料甚至还有部分标注“内部资料不得外传”的历史档案。如果权限在检索阶段没有生效任何一个不该看到内容的员工问到敏感信息都是重大事故。我们在实施中把权限体系拆成两层文档级权限每一份文档入库时打上权限标签包括可见范围全员/某部门/某职级以上和密级标识。检索级过滤用户发起检索请求时系统根据用户身份部门和职级实时计算可见文档集合检索时只对这个子集进行向量匹配和关键词匹配而不是全量库。这个设计听起来简单实际落地时遇到了不少麻烦。最典型的问题是一份文档被引用到另一份文档中可见范围到底以哪份为准比如一份公开制度里引用了某份内部标准文件用户问起这个引用条款时系统会不会把内部标准也输出出去我们的方案是“引用隔离”检索片段中如果包含对其他文档的引用信息且用户对该文档无权限则回答中自动隐藏引用细节只保留当前可见内容。牺牲了一点完整性换来了安全合规的底线。4.2 模型私有化部署不是“装个模型”那么简单由于数据不能出域整个AI链路必须在央企的内网环境私有化部署。这涉及Embedding模型、重排模型、大语言模型三个推理服务的搭建每一步都有坑。先说大模型选型。我们评估过几款开源模型在央企知识问答场景下的表现最终选了Qwen系列中尺寸适中的版本原因是它在中文理解、指令跟随、抽取能力上比较均衡而且中文社区资料丰富遇到问题好排查。模型量化使用的是INT8把显存占用压下来一半多点速度提升了接近30%效果损失在可接受范围内。这里给一个显存计算的参考公式模型推理显存 ≈ 参数(GB) 激活显存(约参数量的20%左右) 推理缓存一个7B模型FP16权重约14GBINT8量化后约7GB再加上KV Cache和激活值单卡16GB勉强够单实例跑。我们当时为了并发稳定用了一张24GB的卡跑大模型重排用一张消费级卡就够Embedding模型对资源要求最低CPU推理也能跑。整个部署采用Docker Compose编排各服务独立容器统一走内网API网关。注意不要在一开始就追求最大模型。知识库问答中绝大部分问题都是抽取和改写不需要特别强的复杂推理能力。一个大而全的模型不仅部署成本高推理速度慢还容易在细节上过度发挥反而不利于精确控制。4.3 评估、回灌与效果迭代上线才是开始项目上线后我们持续做了三个月的运营监控发现线上用户问的问题和测试集差距非常大。测试集里我们问的是“《采购管理办法》中超过多少金额需要招标”而用户实际问的是“我们部门买个服务器是不是一定要走招标流程自己招标行不行”。前一个是单点查询后一个是实际业务推理问题难度高了一个量级。为此我们建立了一套评估回灌机制每周从线上对话日志中抽取出回答质量差的问题人工标注正确答案。将标注数据加入测试集重新跑检索和生成评估看效果变化。每周更新一次Embedding模型的重训练数据可选或调整切片和检索策略。对反复出错的问题人工补充知识文档把隐含的“多文档推理”变成更细粒度的知识片段。这套闭环跑起来之后线上问答好评率明显上升。一个直接感触是知识库不是建完就能完事的它更像一个有生命的系统需要持续喂数据和反馈才能维持效果。5. 常见问题速查与经验总结最后整理几个我们项目里最具代表性的问题和处理办法供参考问题典型表现排查思路我们的解法召回相关但答案不对能检索到文档但给出的片段不是精确答案检查切片是否破坏语义单元尝试结构感知切片按标题层级切片表格单独结构化答案编造事实模型输出看似合理但原文没有缺少引用约束生成温度过高强制引用抽取值类信息温度调低旧版本文档被召回标准或制度更新后仍答旧版缺少时间过滤加入发布时间元数据和检索过滤条件权限泄露风险无权限用户检索到受限内容检索阶段未过滤权限文档级权限标签检索子集过滤引用隔离长文档找不到答案问题涉及全文多处信息单段召回不完整Agent拆分问题分步检索汇总并发一高就超时大模型推理耗时过长显存不足、推理配置差INT8量化、加大显存、服务化拆分经验层面上我真心建议后面做类似项目的团队在立项时就把下面三件事谈清楚数据质量是最大的交付物。不要急着上模型先花时间把文档清洗、切片、元数据标注做扎实否则后面每一步都是返工。明确权限和合规边界的责任人。技术方案能做的事只是“按权限标签过滤”标签和权限规则需要业务方明确拍板项目经理和法务或保密办共同确认。评测集建设是保命手段。不要凭感觉说效果变好了建立一份覆盖常见场景的测试集每次改动都跑一遍所有优化过程全部数据化。我在实际操作中还有一个体会央企知识库这类项目和互联网产品的AI落地是两个物种。互联网产品追求“惊喜感”回答越聪明越好央企知识库追求“确定感”回答越稳越好、越能追根溯源越好。项目后期我们把Prompt和链路反复“做笨”效果反而越来越好。做AI落地方案最大的本事是在花哨和稳重之间找到那条适合业务场景的线而不是一味堆新技术。希望这次的复盘能帮你在踩坑之前就绕过这些泥潭。
