1,377
社区成员
发帖
与我相关
我的任务
分享
ChatGPT 等大语言模型出现之后,人机交互方式发生了明显变化。过去的软件更多依赖菜单、按钮和固定流程,而大语言模型让用户可以直接使用自然语言提出需求。
但在实际项目中,仅仅拥有一个大模型通常还不够。
比如企业员工询问:
“公司去年第三季度华东地区哪款产品退款率最高?相关售后规定是什么?”
这个问题同时涉及销售数据库、售后文档、公司内部制度以及计算过程。单纯依靠模型参数中的知识,很难给出可靠答案。
于是,“大语言模型 + 外部知识”的知识协同技术开始变得重要。
大语言模型本质上是根据上下文预测后续内容的生成模型。
它很强,但仍存在几个现实问题:
模型训练完成后,参数不会自动同步企业刚发布的文件、当天数据库记录或者实时业务数据。
企业内部可能拥有:
这些内容通常并不存在于公开训练语料中。
当模型不知道答案时,它仍可能生成语言上非常合理的内容。
因此,企业真正需要的往往不是:
“一个知道很多东西的大模型。”
而是:
“一个知道什么时候应该查询知识,并能够基于真实知识回答问题的大模型系统。”
可以把整个系统理解为三层。
flowchart LR
A[用户问题] --> B[大语言模型]
B --> C{需要外部知识?}
C -->|需要| D[知识协同层]
C -->|不需要| H[直接回答]
D --> E[向量知识库]
D --> F[知识图谱]
D --> G[数据库/API]
E --> B
F --> B
G --> B
B --> H[生成最终答案]
第一层是语言模型,负责理解问题和生成答案。
第二层是知识系统,负责保存真实信息。
第三层则是协同机制,决定:
这一层实际上是整个系统最值得研究的部分。
RAG,即 Retrieval-Augmented Generation,中文一般翻译为检索增强生成。
基本流程是:
用户提问 → 检索相关资料 → 将资料放入Prompt → 大模型生成答案。
它也是目前企业知识库中非常常见的技术路线。
如果说向量数据库擅长解决:
“哪些文本和这个问题比较相似?”
那么知识图谱更加擅长解决:
“A和B之间究竟有什么关系?”
例如:
张三 → 负责 → 项目A
项目A → 使用 → NX
NX → 属于 → CAD软件
这种结构特别适合复杂关系查询。
传统RAG执行固定流程:
检索 → 回答
而Agent可以自己判断:
思考 → 查询数据库 → 阅读文档 → 调用计算工具 → 再思考 → 回答
模型开始从“回答问题”逐渐转变为“完成任务”。
模型还可以连接:
这时模型实际上成为了系统的自然语言控制入口。
例如用户提问:
“查询A产品最近三个月销售情况,并分析销量下降原因。”
系统可以执行:
flowchart TD
A[用户问题] --> B[问题理解]
B --> C[查询销售数据库]
B --> D[检索市场报告]
B --> E[检索客户反馈]
C --> F[数据分析]
D --> G[知识提取]
E --> G
F --> H[大模型综合推理]
G --> H
H --> I[生成分析报告]
这里,大模型已经不再是唯一的信息来源。
真正产生答案的是:
模型能力 + 企业知识 + 实时数据 + 工具能力。
未来企业部署AI时,很可能不会只部署一个聊天机器人。
模型会连接几十甚至几百个知识源:
大模型
│
┌──────────┼──────────┐
│ │ │
文档库 数据库 API
│ │ │
知识图谱 ERP CAD
│ │ │
邮件系统 CRM 搜索系统
用户只需要表达目标:
“帮我分析这个项目。”
系统负责判断调用哪些知识和工具。
因此,从工程角度来看,大语言模型的发展方向正在从:
Language Model
逐渐走向:
Knowledge + Reasoning + Tool + Agent。
大语言模型解决的是“理解和生成”的问题,而知识协同解决的是“知识从哪里来、是否真实、怎样被使用”的问题。
真正能够进入企业核心业务的大模型系统,通常不会只是一个单独的模型,而会形成:
LLM + RAG + Knowledge Graph + Database + Tools + Agent
的综合智能系统。
这可能也是未来大语言模型工程化落地最值得关注的技术方向之一。