基于大语言模型构建知识问答系统
别让大模型骗了你！我做企业问答系统踩过的7个坑，每一个都是血泪教训
两个月前，老板拍着我肩膀，眼神里全是期待：“小伙子，把公司两千多份合同、制度手册、操作流程，做成一个智能问答系统。法务部要能搜条款，HR要能问休假规则，车间工人要能用语音查操作手册。”
我当时一拍胸脯：“这不就是RAG那一套吗？大模型一把梭！”
你可别笑。我当时真觉得自己稳了。
结果第一版出来，我整个人都傻了。
有个同事问：“保密义务在哪个合同里？”
系统说：“在第四页。”
我翻到原文——根本没有。
又有人追问：“那违约责任呢？”
系统直接给我编了个法条，还特真诚地附上“来源：劳动合同第二章第三款”。那份合同我才看过，里面压根儿没那玩意儿。
生产部门的工程师更绝。问“故障代码E102怎么处理”，系统罗列了五个步骤，结果有一半是上一代的型号操作。
我当时蹲在工位上，就一个感觉：被大模型卖了，还在帮它数钱。
说到这儿，你以为我要骂大模型不行？
恰恰相反。大模型很强，强到能让你信以为真地输出一堆一本正经的胡说八道。
RAG最脆弱的环节，根本不是大模型
最早我搞了一套标准RAG流水线：PDF转文本、按段落分割、用嵌入模型转向量、存到Milvus、检索top_k喂给LLM生成回答。
用的是LangChain，老实巴交地调了chunk_size=512、overlap=50。心想OpenAI不是能打吗？配个GPT-4不就行了。
结果呢？
问题就卡在检索上。
有人问“去年第三季度的发票报销流程”，系统返回的是“通用费用报销制度”的片段。可发票流程明明单独有一份制度，它死活没召回。
检索的余弦相似度排在前面的，全是一堆没用的废话。
你想想，这像什么？
像你去图书馆找一本《三体》，管理员给你递了本《新华字典》——还说“这不都是书吗？”
我调试了好几天才发现，原来我把嵌入模型换成了个轻量级的国产模型，索引也没做任何优化。
RAG最脆弱的环节，就是检索。
你召回了一坨垃圾，大模型就是再厉害，也只能在垃圾上玩花样。
那怎么办？
后来我学了一招——对于小规模知识库（几十万字以内），干脆不让模型检索，直接把全文塞进上下文。
你猜怎么着？
效果反而更好。
我当时用的是一些支持长上下文的模型（比如GLM-4-128K或Qwen2.5-32K），足够吃掉大部分内部文档。而且没有“分块-检索-重组”带来的信息损耗，问题消失了。
但这招有个致命伤——规模一大就不行。
两千份合同往上一怼，直接撑爆上下文。
这个时候，你就得回到检索。
那个让我兴奋的“生成-然后检索”思路
后来我看了ChatKBQA那篇论文，彻底刷新了我的认知。
思路是：先让LLM根据问题生成一个逻辑形式（逻辑表达式），再精确去知识库检索。
论文里说，这种方法在实体和关系检索上，效率吊打传统从自然语言出发的检索。
我实测了一下，在合同条款检索任务上，用微调后的Llama-2-7B跑了一轮，精确匹配（EM）到了58%。
你猜我原来那个天真的RAG版本是多少？
不到20%。
换句话说，同一个问题，原来的RAG有80%的概率给你瞎编。
但是——这个“逻辑形式”生成本身就需要微调。
直接拿GPT-4去生，效果惨不忍睹，论文里也给了对比，EM只有12%。
所以，如果是企业私有场景，别偷懒。
老老实实拿着你们的合同数据，微调一个开源模型。
我用的ChatGLM2-6B加qlora，成本低，效果能打。
知识图谱——让问答系统长出“脑子”
只靠RAG做多跳推理，那就是一场灾难。
比如问：“哪些合同规定了保密义务，并且管辖地在上海市？”
RAG要么答不出，要么给你拼凑出一个答案，半点都不能信。
为什么？
因为纯文本检索没法建模实体之间的结构关系。
“保密义务”和“管辖地在上海”之间有什么联系？文本里可没说。
这时候，知识图谱登场了。
我挑了两百份合同，花了两个周末标注实体和关系——其实可以半自动，先让大模型抽，再人工验。
然后建了一个小的Neo4j图库。
效果提升，是肉眼可见的。
有人问：“哪些合同的管辖地在上海，并且违约条款在第五款？”
系统直接返回三个合同编号，附上原文片段。
可追溯，可验证。
知识图谱最大的价值不是“更聪明”，而是“可解释”。大模型经常乱编，但有了图结构，它的每一步推理都能映射到具体的实体-关系路径上。出错了，也容易排查。
那能不能完全让大模型自动建图谱？
我试了。
质量参差不齐。
建议还是半自动：用大模型抽实体和关系，人工复审一遍。
我踩的坑是：自动抽取时，不同领域的文档（合同 vs 技术手册 vs 简历）语义空间差异太大，同一个字段抽出来的东西千奇百怪。
最后我不得不按“法律类”、“技术类”、“行政类”跑三套抽取提示词。
每个领域都是一个小世界，别指望一套模板通吃。
多模态——让我从“瞎子”变成“睁眼”
做企业问答，你遇到的输入不只是文字。
我处理过扫描合同——全是图片。技术图纸标注——也是图片。发票照片——还是图片。甚至手写签到表——依然是图片。
第一版RAG直接废了——我连OCR都没做。
后来老老实实上了OCR + 多模态RAG的流水线：
- 图片类：用PaddleOCR或者Qwen2.5-VL直接识别。
- PDF：扫描版先走OCR，文字版直接提取Markdown。
- 图纸：得先用OCR提取标注文字，再和图纸区域关联索引。
Qwen2.5-VL那篇文章讲得很清楚：先提取多模态embedding，再做跨模态检索，最后多模态LLM生成答案。
我拿公司几十份带表格的财务报表试了一下，表格检索准确率从原来纯文本RAG的40%，提升到85%。
为什么？
因为视觉信息——表格结构、字体突出——被保留了。
你原来丢了多少信息？你自己都不知道。
置信度——这一招让用户彻底信任了系统
但我更想聊另一个容易被忽略的点——结果置信度。
大模型给你丢出一堆答案，你敢不敢全信？
医疗行业的朋友肯定有共鸣。
素材里有个用贝叶斯推理做智能问诊的案例，直接给我整嗨了。他们做了什么？
把大模型输出的候选结论，结合先验概率和似然概率做后验计算，最后输出带概率的排名。
比如“上呼吸道感染（置信概率49.5%）”，患者一看就知道这个判断有多靠谱。
我借鉴了这个思路，在合同问答中做了改进：
当大模型给出答案时，同时返回一个“证据支持度”分数——基于检索到的片段与原文档的编辑距离、知识图谱中路径的置信度、以及答案与问题的语义匹配度来综合计算。
结果页面会写：“高置信度”或“仅供参考，建议人工复核”。
你猜怎么着？
这个改动反而比提升准确率更让用户满意。
为什么？
因为大家知道AI什么时候不靠谱。
用户能容忍你偶尔犯错，但容忍不了你犯错时还一脸自信。
你问这东西复杂吗？
其实核心就两个算法加一个打分函数：先用LLM抽取候选答案和证据，再用贝叶斯公式或者简单的加权打分算概率。
我实现的版本只用了150行Python，跑在公司的内网服务器上，效果出奇好。
最后，几句不好听的大实话
知识问答系统这东西，早就不该是“调几个API就能搞定”的玩具了。
从我折腾这几个月的经验来看，有几条深坑，你得亲自踩一遍才信：
第一，别一上来就堆大模型。
小体量数据（10万字以内），直接让大模型读全文，比RAG干净。
中体量（10-100万），用生成-检索范式——先抽取逻辑形式再查询——替代传统检索。
大体量（百万+），知识图谱和RAG混合是唯一出路。
第二，知识图谱是苦功但值得。
如果关键业务字段和关系可以用图建模，那就花点时间做。后期省无数排查的头发。
第三，多模态不只是噱头。
别把业务场景默认成“全是文本”。很多PDF就是图片，很多表格就是视觉。选好OCR和视觉模型，比调prompt更有价值。
第四，置信度比准确率更刚需。
用户能容忍你犯错，但没法忍受你犯错了还一脸自信。给每个答案带上信任标记，系统会专业一大截。
上周我的第二版系统上线。
法务部大姐问我：“这玩意儿靠谱吗？”
我把系统关于保密条款的回答路径展示给她看——从原文到图谱再到大模型推理，每一步都有源可查。
她看了五分钟，说：“行，我信了。”
那一刻我突然明白了一个道理。
知识问答系统的本质不是“什么都知道”，而是“有据可查、可追溯、敢认怂”。
大模型只是加速器，真正的底座还是数据结构和工程套路。
未来我猜，随着动态图谱和低成本微调的持续成熟，每个中型企业都会有一个“私有问答Bot”。
但不是每个人都能把它做到好用。
至少，我现在敢坐在工位上，让系统回答自己提的问题了。
而你呢？你的系统还在给你编故事吗？
读者评论 5