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
工具自动进行知识检索 - 知识库管理:通过
enableSourceSync
启用智能同步机制,确保向量存储中的数据始终与用户配置的 source 保持一致
这种模式提供了:
- 智能检索:基于向量相似度的语义搜索
- 多源支持:支持文件、目录、URL 等多种知识来源
- 灵活存储:支持内存、PostgreSQL、TcVector 等多种存储后端
- 高性能处理:并发处理和批量文档加载
- 知识过滤:通过元数据,支持知识的静态过滤和 Agent 智能过滤
- 可扩展架构:支持自定义 Embedder、Retriever 和 Reranker
- 动态管理:支持运行时添加、移除和更新知识源
- 数据一致性保证:通过
enableSourceSync
开启智能同步机制,确保向量存储数据始终与用户配置的 source 保持一致,支持增量处理、变更检测和孤儿文档自动清理
Agent 集成
Knowledge 系统与 Agent 的集成方式:
- 自动工具注册:使用
WithKnowledge()
选项自动添加knowledge_search
工具 - 智能过滤工具:使用
WithEnableKnowledgeAgenticFilter(true)
启用knowledge_search_with_agentic_filter
工具 - 工具调用:Agent 可以调用知识搜索工具获取相关信息
- 上下文增强:检索到的知识内容自动添加到 Agent 的上下文中
- 元数据过滤:支持基于文档元数据进行精准搜索
快速开始
环境要求
- Go 1.24.1 或更高版本
- 有效的 LLM API 密钥(OpenAI 兼容接口)
- 向量数据库(可选,用于生产环境)
配置环境变量
最简示例
手动调用示例
核心概念
knowledge 模块 是 tRPC-Agent-Go 框架的知识管理核心,提供了完整的 RAG 能力。该模块采用模块化设计,支持多种文档源、向量存储后端和 embedding 模型。
使用指南
与 Agent 集成
Knowledge 系统提供了两种与 Agent 集成的方式:自动集成和手动构建工具。
方式一:自动集成(推荐)
使用 llmagent.WithKnowledge(kb)
将 Knowledge 集成到 Agent,框架会自动注册 knowledge_search
工具,无需手动创建自定义工具。
方式二:手动构建工具
使用手动构建SearchTool的方法来配置知识库,通过这个方法可以构建多个知识库
使用 NewKnowledgeSearchTool 创建基础搜索工具:
使用 NewAgenticFilterSearchTool 创建智能过滤搜索工具:
向量存储 (VectorStore)
向量存储可在代码中通过选项配置,配置来源可以是配置文件、命令行参数或环境变量,用户可以自行实现。
向量存储配置示例
Elasticsearch
Embedder
Embedder 负责将文本转换为向量表示,是 Knowledge 系统的核心组件。目前框架主要支持 OpenAI embedding 模型:
Reranker
Reranker 负责对检索结果的精排:
支持的 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()
;- 默认值在多数场景下较为均衡;需要更快速度可适当上调,遇到限流则下调。
过滤器功能
Knowledge 系统提供了强大的过滤器功能,允许基于文档元数据进行精准搜索。这包括静态过滤器和智能过滤器两种模式。
基础过滤器
基础过滤器支持两种设置方式:Agent 级别的固定过滤器和 Runner 级别的运行时过滤器。
Agent 级过滤器
在创建 Agent 时预设固定的搜索过滤条件:
Runner 级过滤器
在调用 runner.Run()
时动态传递过滤器,适用于需要根据不同请求上下文进行过滤的场景:
Runner 级过滤器的优先级高于 Agent 级过滤器,相同键的值会被覆盖:
智能过滤器 (Agentic Filter)
智能过滤器是 Knowledge 系统的高级功能,允许 LLM Agent 根据用户查询动态选择合适的过滤条件。
启用智能过滤器
过滤器优先级
系统支持多层过滤器,按以下优先级合并(后者覆盖前者):
- Agent 级过滤器:
WithKnowledgeFilter()
设置的固定过滤器(优先级最低) - Runner 级过滤器:运行时传递的过滤器(优先级中等)
- 智能过滤器:LLM 动态生成的过滤器(优先级最高)
配置元数据源
为了使智能过滤器正常工作,需要在创建文档源时添加丰富的元数据:
向量数据库过滤器支持
不同的向量数据库对过滤器的支持程度不同:
PostgreSQL + pgvector
- ✅ 支持所有元数据字段过滤
- ✅ 支持复杂查询条件
- ✅ 支持 JSONB 字段索引
TcVector
- ✅ 支持预定义字段过滤
- ⚠️ 需要预先建立过滤字段索引
内存存储
- ✅ 支持所有过滤器功能
- ⚠️ 仅适用于开发和测试
知识库管理功能
Knowledge 系统提供了强大的知识库管理功能,支持动态源管理和智能同步机制。
启用源同步 (enableSourceSync)
通过启用 enableSourceSync
,知识库会始终保持向量存储数据和配置的数据源一致,这里如果没有使用自定义的办法来管理知识库,建议开启此选项:
同步机制的工作原理:
- 加载前准备:刷新文档信息缓存,建立同步状态跟踪
- 处理过程跟踪:记录已处理的文档,避免重复处理
- 加载后清理:自动清理不再存在的孤儿文档
启用同步的优势:
- 数据一致性:确保向量存储与源配置完全同步
- 增量更新:只处理变更的文档,提升性能
- 孤儿清理:自动删除已移除源的相关文档
- 状态跟踪:实时监控同步状态和处理进度
动态源管理
Knowledge 支持运行时动态管理知识源,确保向量存储中的数据始终与用户配置的 source 保持一致:
动态管理的核心特点:
- 数据一致性保证:向量存储数据始终与用户配置的 source 保持一致
- 智能增量同步:只处理变更的文档,避免重复处理
- 精确源控制:支持按源名称精确添加/移除/重载
- 孤儿文档清理:自动清理不再属于任何配置源的文档
- 热更新支持:无需重启应用即可更新知识库
知识库状态监控
Knowledge 提供了丰富的状态监控功能,帮助用户了解当前配置源的同步状态:
状态监控输出示例:
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 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 |
|
其中,环境变量配置如下:
命令行参数
故障排除
常见问题与处理建议
-
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
做白名单过滤。