Knowledge 使用文档
概述
Knowledge 是 tRPC-Agent-Go 框架中的知识管理系统,为 Agent 提供检索增强生成(Retrieval-Augmented Generation, RAG)能力。通过集成向量数据、embedding 模型和文档处理组件,Knowledge 系统能够帮助 Agent 访问和检索相关的知识信息,从而提供更准确、更有依据的响应。
使用模式
Knowledge 系统的使用遵循以下模式:
- 创建 Knowledge:配置向量存储、Embedder 和知识源
- 加载文档:从各种来源加载和索引文档
- 集成到 Agent:使用
WithKnowledge()
将 Knowledge 集成到 LLM Agent 中 - Agent 自动检索:Agent 通过内置的
knowledge_search
工具自动进行知识检索
这种模式提供了:
- 智能检索:基于向量相似度的语义搜索
- 多源支持:支持文件、目录、URL 等多种知识来源
- 灵活存储:支持内存、PostgreSQL、TcVector 等多种存储后端
- 高性能处理:并发处理和批量文档加载
- 可扩展架构:支持自定义 Embedder、Retriever 和 Reranker
Agent 集成
Knowledge 系统与 Agent 的集成方式:
- 自动工具注册:使用
WithKnowledge()
选项自动添加knowledge_search
工具 - 工具调用:Agent 可以调用知识搜索工具获取相关信息
- 上下文增强:检索到的知识内容自动添加到 Agent 的上下文中
快速开始
环境要求
- Go 1.24.1 或更高版本
- 有效的 LLM API 密钥(OpenAI 兼容接口)
- 向量数据库(可选,用于生产环境)
配置环境变量
最简示例
核心概念
knowledge 模块 是 tRPC-Agent-Go 框架的知识管理核心,提供了完整的 RAG 能力。该模块采用模块化设计,支持多种文档源、向量存储后端和 embedding 模型。
使用指南
与 Agent 集成
使用 llmagent.WithKnowledge(kb)
将 Knowledge 集成到 Agent,框架会自动注册 knowledge_search
工具,无需手动创建自定义工具。
向量存储 (VectorStore)
向量存储可在代码中通过选项配置,配置来源可以是配置文件、命令行参数或环境变量,用户可以自行实现。
向量存储配置示例
Elasticsearch
Embedder
Embedder 负责将文本转换为向量表示,是 Knowledge 系统的核心组件。目前框架主要支持 OpenAI embedding 模型:
支持的 embedding 模型:
- OpenAI embedding 模型(text-embedding-3-small 等)
- 其他兼容 OpenAI API 的 embedding 服务
- Gemini embedding 模型(通过
knowledge/embedder/gemini
)
注意:
- Retriever 和 Reranker 目前由 Knowledge 内部实现,用户无需单独配置。Knowledge 会自动处理文档检索和结果排序。
OPENAI_EMBEDDING_MODEL
环境变量需要在代码中手动读取,框架不会自动读取。参考示例代码中的getEnvOrDefault("OPENAI_EMBEDDING_MODEL", "")
实现。
文档源配置
源模块提供了多种文档源类型,每种类型都支持丰富的配置选项:
批量文档处理与并发
Knowledge 支持批量文档处理和并发加载,可以显著提升大量文档的处理性能:
关于性能与限流:
- 提高并发会增加对 Embedder 服务(OpenAI/Gemini)的调用频率,可能触发限流;
- 请根据吞吐、成本与限流情况调节
WithSourceConcurrency()
、WithDocConcurrency()
;- 默认值在多数场景下较为均衡;需要更快速度可适当上调,遇到限流则下调。
高级功能
QueryEnhancer
QueryEnhancer 用于在搜索前对用户查询进行预处理和优化。目前框架只提供了一个默认实现:
注意: QueryEnhancer 不是必须的组件。如果不指定,Knowledge 会直接使用原始查询进行搜索。只有在需要自定义查询预处理逻辑时才需要配置此选项。
性能优化
Knowledge 系统提供了多种性能优化策略,包括并发处理、向量存储优化和缓存机制:
完整示例
以下是一个完整的示例,展示了如何创建具有 Knowledge 访问能力的 Agent:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 |
|
其中,环境变量配置如下:
命令行参数
故障排除
常见问题与处理建议
-
Create embedding failed/HTTP 4xx/5xx
-
可能原因:API Key 无效或缺失;BaseURL 配置错误;网络访问受限;文本过长;所配置的 BaseURL 不提供 Embeddings 接口或不支持所选的 embedding 模型(例如返回 404 Not Found)。
- 排查步骤:
- 确认
OPENAI_API_KEY
已设置且可用; - 如使用兼容网关,显式设置
WithBaseURL(os.Getenv("OPENAI_BASE_URL"))
; - 确认
WithModel("text-embedding-3-small")
或你所用服务实际支持的 embedding 模型名称; - 使用最小化样例调用一次 embedding API 验证连通性;
- 用 curl 验证目标 BaseURL 是否实现
/v1/embeddings
且模型存在: 若返回 404/模型不存在,请更换为支持 Embeddings 的 BaseURL 或切换到该服务提供的有效 embedding 模型名。 - 逐步缩短文本,确认非超长输入导致。
- 确认
-
参考代码:
-
加载速度慢或 CPU 占用高
-
可能原因:单核顺序加载;并发设置不合适;大文件分块策略不合理。
- 排查步骤:
- 设置源级/文档级并发:
WithSourceConcurrency(N)
、WithDocConcurrency(M)
; - 调整分块大小,避免过多小块;
- 临时关闭统计输出减少日志开销:
WithShowStats(false)
。
- 设置源级/文档级并发:
-
参考代码:
-
存储连接失败(pgvector/TcVector)
-
可能原因:连接参数错误;网络/鉴权失败;服务未启动或端口不通。
-
排查步骤:
- 使用原生客户端先连通一次(psql/curl);
- 显式打印当前配置(host/port/user/db/url);
- 为最小化示例仅插入/查询一条记录验证。
-
内存使用过高
-
可能原因:一次性加载文档过多;块尺寸/重叠过大;相似度筛选过宽。
-
排查步骤:
- 减小并发与分块重叠;
- 分批加载目录。
-
维度/向量不匹配
-
症状:搜索阶段报错或得分异常为 0。
-
排查:
- 确认 embedding 模型维度与存量向量一致(
text-embedding-3-small
为 1536); - 替换 embedding 模型后需重建(清空并重灌)向量库。
- 确认 embedding 模型维度与存量向量一致(
-
路径/格式读取失败
-
症状:加载日志显示 0 文档或特定源报错。
- 排查:
- 确认文件存在且后缀受支持(.md/.txt/.pdf/.csv/.json/.docx 等);
- 目录源是否需要
WithRecursive(true)
; - 使用
WithFileExtensions
做白名单过滤。