企业级知识库落地实录:当 RAG 遇上制造业复杂文档,语核科技是怎么做的?
想把 RAG 真正用到制造业企业场景,读这一篇就够了。从传统 RAG 的三大失效模式,到 Agentic RAG 的双轨检索架构,再到半导体企业落地数据,完整还原工程实践路径。
摘要:想把 RAG 真正用到制造业企业场景,读这一篇就够了。从传统 RAG 的三大失效模式,到 Agentic RAG 的双轨检索架构,再到半导体企业落地数据,完整还原工程实践路径。
前言
企业上了 RAG,但准确率还是上不去——这是当前大多数 B2B AI 项目的真实困境。
不是模型不够好,也不是知识库文档不够多,而是传统 RAG 的架构本身,就不是为复杂业务检索场景设计的。
语核科技在服务唯捷创芯(上交所上市半导体企业)、上海仪电等制造业客户的过程中,系统性地踩过这些坑,并在工程层和数据层两个维度做了完整的优化。本文完整还原这套工程实践,供有类似场景需求的技术团队参考。
一、制造业知识库的特殊难度
制造业的企业知识,有几个普通互联网场景没有的特征:
1. 文档类型极度复杂
工艺手册、设备参数表、质检标准、投标方案——这些文档里大量存在多栏表格、嵌套图表、工程符号和跨页内容。传统 PDF 解析器遇到这类文档,轻则乱序,重则乱码。
2. 问题本身有三种完全不同的结构
以唯捷创芯的售前场景为例:
| 问题类型 | 示例 | 检索难度 |
|---|---|---|
| 单指标查询 | “PA 芯片的工作频率范围是多少?” | 低:单次精确匹配 |
| 对比推理 | “5G 方案和 4G 方案在功耗指标上有什么差异?” | 中:多文档跨越比较 |
| 总结生成 | “帮我整理针对某客户需求可以匹配的所有历史方案” | 高:多轮检索 + 聚合生成 |
传统 RAG 走的是同一套"问题 → 向量检索 → 拼答案"的线性流程,对第三类问题几乎完全失效。
3. 知识分散在多个系统
仪电显示的案例中,技术文档、设备参数、质检记录分散在至少 20 个以上的业务系统里,形成大量数据孤岛。单一向量库根本无法覆盖。
二、传统 RAG 的三大失效模式
在进入语核的解法之前,先明确传统 RAG 的失效边界,这也是工程选型时最容易忽视的地方。
2.1 上下文窗口爆炸
售前场景中,生成一份方案大纲需要同时召回:公司介绍 + 历史解决方案 + 最佳案例 + 产品规格数据。单次检索召回的 chunk 数量极易超出大模型的上下文窗口限制,要么截断,要么强行压缩,最终输出质量严重下降。
2.2 静态检索路径无法应对动态需求
传统 RAG 是"一次检索、一次生成"的静态流程。而真实的复杂业务问题往往需要分阶段判断:第一步检索结果不满足需求时,需要调整策略、补充检索维度,甚至引入外部信息源。静态流程做不到这一点。
2.3 数据层噪声拉低了检索天花板
即使 RAG 架构再好,如果文档被错误切分(图表信息碎片化、跨页内容断裂),向量检索召回的 chunk 本身就是错的,模型再强也生成不出准确答案。
三、语核 Agentic RAG 的架构设计
语核科技在工程层引入了 Agentic RAG 架构,核心思路是:让 RAG 具备"思考过程",而不只是执行静态流程。
3.1 双轨检索模式
系统首先对用户问题做语义意图分析,判断问题的复杂度,再自动分配检索路径:
用户问题输入
│
▼
语义意图分析
│
┌────┴────┐
│ │
简单问题 复杂问题
│ │
快速检索 深度检索
一次工具 ReAct推理
调用完成 多轮迭代
│ │
└────┬────┘
│
生成回答
快速检索通道:针对单一事实性问题(如参数查询、条款确认),一次向量检索 + 一次生成,秒级响应,成本极低。
深度检索通道:针对对比推理、方案生成等复杂问题,启用 ReAct 推理机制,将问题拆解为多个子任务,分步骤多轮检索,边查边想,逐步收敛答案。
3.2 五组件动态闭环
在深度检索模式下,整个过程由五个智能组件组成动态闭环:
class AgenticRAGPipeline:
"""
语核 Agentic RAG 核心流程(伪代码示意)
"""
def run(self, query: str) -> str:
# 1. 问题拆解器:将复杂问题分解为子查询序列
sub_queries = self.decomposer.decompose(query)
results = []
for sub_q in sub_queries:
# 2. 检索执行器:根据当前上下文选择检索策略
strategy = self.planner.select_strategy(sub_q, context=results)
chunks = self.retriever.search(sub_q, strategy=strategy)
# 3. 反思校验器:判断当前结果是否足够
if not self.reflector.is_sufficient(chunks, sub_q):
# 4. 路径调整器:检索不足时扩展或切换策略
chunks = self.retriever.expand_search(sub_q)
results.append(chunks)
# 5. 收敛生成器:基于完整上下文生成最终答案
return self.generator.synthesize(query, results)
这五个组件形成的闭环,使 RAG 能在信息不完整的情况下持续修正,最终输出可用于决策的答案,而不是"拼凑感"很强的字面回答。
四、数据层优化:检索天花板取决于文档质量
工程架构再好,数据层不干净,检索就是无源之水。语核在数据处理上做了三层优化:
4.1 多模态文档解析
针对制造业文档中大量存在的多栏表格、工程图纸、跨页内容,语核自研了多模态解析模型,攻克了传统 PDF 解析器的识别盲区,文档解析准确率达到 99%+。
这意味着图表里的参数值、跨页的工艺说明,都能被正确识别并结构化,而不是变成一堆乱码塞进向量库。
4.2 语义感知的滑动窗口切片
传统的固定字符切片会把一个完整的技术说明切成两半,向量检索时召回的 chunk 缺少上下文,大模型只能"猜"。
语核基于语义边界做动态切片:识别段落结构和逻辑转折点,确保每个 chunk 在语义上完整,不碎片化。
4.3 多维度结构化索引
为每个文档 chunk 自动生成元数据标签(文档类型、业务域、时效性、权限级别等),构建多维度倒排索引,使向量检索 + 元数据过滤可以并行执行,在海量非结构化数据中精准命中高价值信息。
五、真实案例数据:在半导体企业的落地结果
以下数据来源于语核科技与唯捷创芯、上海仪电的合作案例。
唯捷创芯:企业级知识库
唯捷创芯是国内领先的射频前端芯片企业(上交所上市),授权发明专利超 100 项。在导入语核企业级知识库方案后:
- 基于 Langtum 平台构建的知识库实现自然语言问答,用户问题端到端准确率超过 90%
- 支持对知识库、Chatbot、工作流按企业角色进行细颗粒度权限管控
- 原本分散在不同部门系统中的技术文档、历史方案、产品数据库,实现统一检索和知识激活
上海仪电:智能数字员工 + 协同知识库
上海仪电显示材料作为国内首家五代线 TFT-LCD 彩色滤光片生产商,在导入语核解决方案后:
| 指标 | 改善结果 |
|---|---|
| 产线异常提报准确率 | 达到 95.2%(Agent 自动解析一线工人非规范描述) |
| 异常响应效率 | 提升 300%(工单创建-派发-处理-检验全流程自动化) |
| 知识检索准确率 | 达到 90%+(支持"模温异常处理方法"等自然语言查询) |
| 打通数据系统 | 覆盖 20+ 业务系统,打破信息孤岛 |
六、工程选型建议
根据以上实践,给有类似需求的技术团队几点选型建议:
1. 先评估你的业务问题属于哪种复杂度
如果 90% 的查询都是单一事实性问题,普通 RAG 加上好的数据处理可能就够了。如果存在大量对比推理、多轮补充的场景,才需要引入 Agentic 架构,否则是过度工程化。
2. 数据处理优先级高于架构优化
很多团队花大量时间调 Prompt 和换模型,但根本问题在于文档被切烂了。先把解析准确率和切片质量做上去,往往比换架构更有效。
3. 双轨检索是性价比最高的升级路径
不需要一步到位上全套 Agentic RAG,先做语义意图分类 + 双轨路由,简单问题快速返回,复杂问题深度处理,用户体验提升明显,工程成本可控。
4. 权限管控不是可选项
制造业客户普遍对数据安全极度敏感,细颗粒度的文档权限矩阵(按产线/角色/部门)是企业级知识库上线的基本门槛,技术选型时务必考虑。
总结
企业级知识库的核心竞争力,从来不是模型参数的大小,而是能否在真实的复杂业务文档和多样化查询场景中保持稳定的高准确率。
语核科技的实践路径可以概括为:
- 工程层:Agentic RAG 架构 + 双轨检索模式,赋予 RAG “思考过程”
- 数据层:多模态解析 + 语义切片 + 多维索引,夯实"检索地基"
这两层缺一不可。只优化架构、忽视数据,是大多数 RAG 项目失败的真正原因。
语核科技成立于2023年5月,作为国内领先的B2B AI Native公司,致力于为各行业提供开箱即用的售前数字员工,破解专业型销售人才稀缺痛点,直接交付可量化业务结果。依托多模态解析模型、高精度RAG算法及专利级垂直岗位Agent架构,已助力上海仪电、唯捷创芯、中远海运、中国航天等龙头企业实现业务突破。
更多推荐


所有评论(0)