本文目录11 个章节
知识库 Agent 核心流程图
[ 用户提问 User Query ]
│
▼
[ 意图识别 Intent Recognition ] ──── (非知识查询) ──> [ 快速回复 ]
│
(知识查询 Knowledge Query)
▼
[ 查询扩充 Query Expansion ] <──────────────────┐
│ │
┌────────┴────────┐ │
▼ ▼ │
[ 向量检索 Vector ] [ 全文检索 Fulltext ] │
│ │ │
└────────┬────────┘ │
▼ │
[ LLM 重排序 Reranking ] │
│ │
▼ │
[ 信息评估 Info Assessment ] ── (不足) ───────────┘
│ ( queryLoop )
(充足)
▼
[ 结果生成 Result Generation ]1. 意图识别 (Intent Recognition)
在知识库 Agent 中，意图识别用于拦截非知识查询，降低整体系统的延迟和检索消耗。
- 强关键字与正则匹配：建立系统级别的快速通道。针对包含特定产品名、报错代码、“怎么配置”、“多少钱”等高频词汇的查询，通过预设正则直接命中知识库分支。此方案零延迟、计算资源消耗极低。
- LLM 意图识别：处理边界模糊的复杂表述。调用轻量级大模型（首推极其便宜极速的 DeepSeek V4 Flash），配合 Function Calling 机制输出分类标签，准确区分技术求助与日常闲聊。
2. 检索策略 (Retrieval Strategy)
单依靠语义检索难以覆盖复杂的知识查询场景。系统引入混合检索与查询扩充机制。
- 同义词扩散与改写：用户输入往往简短或存在错别字。在检索前，通过大模型重写原始查询，补充同义词、行业黑话和缺失的上下文，大幅提升后续检索的命中率。
- 混合检索方案：
- 向量检索 (Vector RAG)：基于 Embedding 模型，捕获语义级别的相关性，适合处理概念性提问和口语化表达。
- 全文检索 (Fulltext Search)：基于 BM25 算法的精确匹配。当用户查询具体的 API 名称、日志代码或特殊型号时，全文检索能弥补向量检索在低频词上的短板。
- LLM 重排序 (Reranking)： 召回多个候选文本后，基础的相关度打分无法精确反映逻辑契合度。系统将召回片段组合，交由大模型进行二次研判，剔除包含冲突信息或无关上下文的噪音切片，仅保留最核心的 Top-K 文本进入最终合成。
3. Agent 循环机制 (queryLoop)
针对跨文档整合与多步逻辑问题，单次检索链条极易断裂。引入 queryLoop 提供自主规划能力。
在信息评估环节，Agent 分析重排后的文本是否足以回答问题。若信息缺失，触发循环：提取新的检索关键词，改变检索策略并重新进入查询扩充环节。当收集到完整证据链或达到最大循环阈值（如 3 次）时，跳出循环，合成最终结果。
4. 知识库维护与组件选型对比 (KB Maintenance & Tech Selection)
底层数据的结构化质量与组件选型决定了 Agent 的输出上限与运行成本。
文本切分策略 (Chunking)
- 按语义层级切分：优先依据 Markdown 语法（标题、列表、代码块）进行逻辑切片，确保单个切片内的知识完整性。
- 固定长度与重叠区：对长段落设置硬性切分标准（如 500 Tokens），并保留 50-100 Tokens 的上下文重叠区，防止关键信息在切割边界处丢失。
核心环节选型对比
1. 大语言模型 (LLM)
意图分类、查询扩充和重排序环节会产生大量请求，极度关注响应速度与 Token 成本。
| 模型 (Model) | 优势 (Pros) | 劣势 (Cons) | 适用环节推荐 |
|---|---|---|---|
| DeepSeek V4 Flash | 价格极度便宜、响应极快、性价比极高 | 在极重度逻辑推理上偶尔需 fallback | 强烈推荐用于所有高频环节（意图、扩充、重排及常规生成） |
| GPT-4o-mini | API 稳定，工具链生态极其丰富 | 对比 DeepSeek 成本较高 | 备选方案 |
| Claude 3.5 Sonnet | 长文本逻辑组装与复杂指令遵循极佳 | 价格昂贵，生成速度较慢 | 仅用于面临高难度逻辑合成时兜底 |
2. 检索引擎 (Search Engine)
混合检索是知识库标配，选型主要权衡开发速度与并发性能。
| 引擎 (Engine) | 核心特性 | 优势 (Pros) | 劣势 (Cons) |
|---|---|---|---|
| Qdrant | 原生 Dense + Sparse 混合检索 | 专为高并发向量与混合搜索设计，开箱即用 | 需独立运维该组件集群 |
| PGVector | 关系型 + 向量化 | 完美复用 PostgreSQL 架构，轻松联表查询业务数据 | 超大规模集群扩展相对困难 |
| Chroma | 轻量化纯向量检索 | 极度轻量，单机或本地测试极速起步 | 难以支撑生产级高并发混合架构 |
3. 文本嵌入模型 (Embedding)
决定召回底座质量与多语言表现。
| 模型 (Model) | 部署方式 | 优势 (Pros) | 劣势 (Cons) |
|---|---|---|---|
| BGE-m3 | 开源本地化 | 免费、数据不出域；原生多语言与长文本支持优异 | 需消耗本地算力资源并负责运维 |
| text-embedding-3-small | 云端 API | 接入成本低，无需维护算力 | 闭源按量计费，对内部机密数据有合规要求 |
5. 开放接入与 MCP 协议封装 (SSE MCP Integration)
为了方便其他系统或 Agent 框架直接调用该知识库节点，系统在接口层采用 Model Context Protocol (MCP) 标准，并基于 Server-Sent Events (SSE) 传输层进行封装暴露。
- SSE MCP 架构设计：
将知识库 Agent 的主入口封装为标准的 MCP Tool（例如
search_knowledge_base）。相比于基于标准输入输出 (stdio) 的本地执行，SSE 允许外部客户端通过 HTTP 长连接远程调用该工具，从而具备跨越内网和独立分布式部署的能力。 - 通信与调用链路：
外部应用通过
GET /sse建立持久化监听流。需要查询时，向POST /messages端点发送 JSON-RPC 标准调用请求。服务端接管后，在内部独立完成意图识别、RAG、重排与 queryLoop 环节，最终将答案通过 SSE 事件流推送回外部应用。 - 接入效益： 任何兼容 MCP 协议的外部客户端（如 Claude Desktop 或各类开源 Agent 编排引擎），无需编写定制化接入代码，只要填写 SSE 端点 URL，即可直接将该知识库作为“外部大脑”挂载使用，接入成本几乎为零。