去年我参与了一个面向市场监管场景的智能问答智能体项目技术栈定的是 Go gin gorm RAG 千问大模型 pgvector。说实话刚开始我心里是没底的因为 RAG 相关组件大部分都长在 Python 生态里Go 这边能直接用的不多等于要把整套链路从零拼一遍。但做完之后发现这套组合反而比预想的稳尤其是在并发能力、部署体积和运维成本上优势非常明显。很多朋友问我到底该怎么落地我干脆把整个设计思路、代码实现和踩过的坑完整整理出来给准备做类似智能体的人一份能直接参考的路线图。1. 项目背景与需求拆解1.1 智能问答智能体到底要干什么这个项目要做的不是传统 FAQ 问答而是一个具备理解、检索、查询和生成能力的智能体。在市场监管场景里用户可能是企业办事人员也可能是窗口工作人员他们的问题往往是复合型的比如“开餐饮店要办哪些证”“食品经营许可证到期了怎么续”“我们公司的股东变更记录能不能查一下”。这类问题既有知识问答成分又有业务查询成分单纯用关键词匹配或者只靠大模型对话都没法满足。所以智能体需要做到三件事第一理解用户的口语化表达甚至能处理“它”“那个证”之类的指代第二将问题转化为可执行的检索或查询动作第三给出有依据的回答并且把引用来源一起返回。说白了它更像一个包在业务系统前面的“AI 客服”而不是一个聊天机器人。这里有个关键点智能体的“智能”不是体现在自由发挥上而是体现在能准确把问题路由到正确的知识源或数据源。知识类问题走 RAG 检索内部文档数据类问题走函数调用查询业务库无关问题直接转人工。我把这个边界在项目第一天就定死了后面所有技术方案都围绕它展开。1.2 市场监管问答的三大痛点做了两周需求梳理后我把项目方反馈最多的问题归成三类。第一知识来源分散且更新快。法规条款、办事指南、填表示例、内部操作规程分散在不同的文档和系统里而且经常出现地方性细则。人工维护一份静态问答库根本不现实一条新规出来所有相关答案都得改一遍。第二提问方式千差万别。同样是问“开餐馆要什么资质”有人会说“餐饮许可怎么办”有人说“食品经营许可证办理流程”还有人直接问“新店开业需要哪些材料”。关键词完全对不上必须依赖语义检索也就是把用户问题向量化后去知识库里找语义最接近的内容。第三答案必须负责任。在监管场景下回答很可能会被用户当作办事依据。如果大模型一本正经地编一个不存在的材料清单后果很严重。所以系统必须有引用来源、置信度阈值和人工兜底机制宁可告诉用户“查不到”也不能给出误导性答案。这三个痛点决定了技术选型方向语义检索靠 embedding 模型加向量数据库可溯源靠知识块元数据和引用回传多轮对话靠会话管理和问题改写实时查询靠工具调用。下一步就是选型。1.3 为什么不直接用大模型对话有同行听说我用千问大模型后第一反应是“那你是不是只要调 API 就行了为什么还要搞 RAG”我当时就解释过大模型虽然知道很多通用知识但对市场监管这类垂直领域答案的有效性和时效性都不够。第一大量内部办事数据根本不在公网训练语料里第二大模型没有实时访问业务系统的能力第三纯大模型回答没有可验证的引用出了问题没法追溯。更现实的一点是很多问题根本不是问答而是查询。例如“帮我查下这家公司有没有异常名录记录”这需要输入企业名称去业务系统里精确查库再返回结构化结果。大模型做不到这一点只能靠函数调用或工具调用。所以最终我们把千问定位成“思考中枢”不是“知识库”它负责理解意图、整理话述、判断工具调用结果而事实性内容全部来自外部检索和数据库查询。2. 技术选型解析与方案对比2.1 Go gin gorm 的组合优势在哪里项目最开始考虑过 Python因为 RAG 生态最丰富LangChain 之类的框架直接搬过来就能用。但后来权衡了长期运维和并发压力还是定了 Go。原因很简单智能体上线后要接受线上大量请求每个请求背后可能还有多轮对话Go 的 goroutine 在处理高并发 IO 等待时非常轻量开发时不用操心线程池和异步回调。我用一台 2 核 4G 的测试机做过压测Go 服务可以稳定扛住几百 QPS换成同等配置跑 Python 服务内存和 CPU 早就告警了。gin 作为 Web 框架没什么好说的路由、中间件、参数绑定、JSON 序列化都很顺手性能也排在 Go 框架前列。很多人会因为项目简单而直接用 net/http我建议还是上 gin因为后面要加鉴权中间件、日志中间件、恢复中间件gin 的中间件机制能省很多事。gorm 是我反复权衡后才选的。项目里有知识文档、知识块、会话记录、问答日志、用户表好几张表如果全部手写 SQL开发效率太低。gorm 的自动迁移和预加载能减少大量样板代码。当然它也不是没有缺点复杂 SQL 的可读性会差点所以我在项目里约定简单 CRUD 用 gorm复杂统计和全文检索使用原生 SQL。这里要特别说明技术选型没有银弹关键是选团队最熟悉、最便于维护的组合。2.2 为什么选 pgvector 而不是专门的向量数据库向量数据库这块我们当时评估了三种方案Milvus、Elasticsearch 向量插件、pgvector。最后选了 pgvector理由有三点。第一数据一致性更好。项目本身的业务数据企业信息、许可记录、问答日志都存在 PostgreSQL如果知识库向量再单独放到另一个系统就要维护两份数据之间的同步关系。pgvector 是 PostgreSQL 扩展知识块正文和向量存在同一张表里文档更新时的正文修改和向量重新计算可以放在同一个事务里不存在跨系统一致性问题。第二运维成本低。一个小团队不可能专门安排人维护一个 Milvus 集群pgvector 不需要额外部署只要在现有数据库上执行一条CREATE EXTENSION vector就能用。它对中小规模知识库几万到几十万个知识块的检索速度完全够用一次 TopK 查询基本在几十毫秒到几百毫秒。第三能利用 SQL 能力做过滤。专门向量库通常不支持像WHERE category 餐饮许可 AND is_active true这种灵活过滤即使支持语法也非常受限。而 pgvector 可以跟普通字段一起做条件过滤这一点在实际项目中太重要了。当然如果未来知识库规模到了几百万甚至上千万pgvector 可能不够用但那是以后的事。架构上我们已经在检索层做了接口隔离如果真需要换不会伤筋动骨。2.3 千问大模型与 RAG 的配合逻辑千问系列大模型我们走的是官方 API用到了两个能力一个是文本向量化用于离线给知识块生成 embedding另一个是文本生成用于在线根据检索结果组织答案。很多人以为 RAG 就是“把检索结果拼到 Prompt 里再丢给模型”这是不对的。Prompt 的结构直接决定回答质量。我的做法是System 部分固定身份和规则告诉模型“你是市场监管智能助手只能基于给定资料回答”User 部分拆成“已知资料”“用户问题”“对话历史”三段。已知资料里的每个知识块都加编号和来源并要求模型回答时按编号引用。这样既降低幻觉又能让用户看到答案出处。千问的长上下文能力也是选它的一大原因。一个知识块几百字TopK 取 5 个也就两三千字再加上历史会话依然在上下文窗口内。而且千问对中文语义的理解比很多国外模型更贴合垂直场景尤其在专有名词和口语问题上效果更稳定。3. 核心架构与关键实现3.1 整体流程从知识入库到答案生成整个系统分成两条链路。一条是离线知识入库链路文档上传后先解析出纯文本和表格做清洗再按标题层级和段落切分为知识块。每个知识块保留文档编号、章节路径和发布时间。然后调用 embedding 接口生成向量批量写入 pgvector。另一条是在线问答链路请求进来后先取出当前会话的历史记录做问题改写把指代词还原成具体实体再交给意图识别模块。意图识别有两条路一条是知识类问题走向量检索取 TopK 后过滤低分结果再组装 Prompt 调用千问另一条是查询类问题走工具调用解析出参数查业务库再把结果交给模型整理成自然语言。这两条链路各自独立中间用接口解耦。这样做的最大好处是离线入库跑挂了不影响在线服务在线服务升级时也可以只改检索策略或 Prompt 模板不需要动入库逻辑。3.2 数据模型设计一张表搞定向量检索核心表叫知识块表字段包括 ID、文档 ID、内容、向量、来源、章节路径、启用状态和创建时间。下面是我在 gorm 里的建模方式package model import ( time github.com/pgvector/pgvector-go gorm.io/gorm ) type KnowledgeChunk struct { ID uint64 gorm:primaryKey;autoIncrement DocID uint64 gorm:index Content string gorm:type:text Embedding pgvector.Vector gorm:type:vector(1024) Source string gorm:size:255 Chapter string gorm:size:255 IsActive bool gorm:index;default:true CreatedAt time.Time gorm:index }关键点是pgvector.Vector这个类型它负责把 Go 的[]float32编码成 PostgreSQL 的 vector 类型。向量维度必须和 embedding 模型输出维度一致我用的是 1024 维如果你的模型输出 1536 维就把vector(1024)改成vector(1536)。这一点千万不能猜必须去查模型官方文档或者先跑一次验证。除了知识块表还建议加三张辅助表文档表存文件名、上传时间、解析状态会话表存会话 ID、用户标识、历史消息摘要问答日志表存每次请求的完整入参、检索到的知识块 ID、模型返回内容和耗时。日志表是后期做评测和排查的命根子我后面会专门讲。3.3 智能体设计意图识别与工具调用这个项目叫“智能体”而不是简单的问答接口关键就在工具调用。我实现的思路是不在代码里写死所有意图分支而是把工具列表和工具 Schema 描述给模型让模型自己判断应该调用哪个工具、抽取哪些参数。举个例子用户说“我想办一个食品经营许可证”模型判断这是一个知识类问题没有匹配到工具就进入 RAG 检索。用户如果说“帮我查一下这家店的许可证状态”模型会识别出这是业务查询应该调用工具check_license参数是许可证号或企业名称。代码层拿到模型返回的 JSON 后去调用业务查询接口再把查询结果塞给模型让模型组织最终回答。具体实现不复杂。我先定义一个工具结构体包含名称、描述、参数 JSON Schema。在调用千问的 Prompt 里把工具列表完整描述一遍并且要求模型在需要调用工具时输出特定格式的 JSON。比如{ tool: check_license, params: { license_no: JY2023xxxx } }我的处理函数会先尝试解析这个 JSON如果模型没有返回工具调用就按普通 RAG 回答处理。如果返回了就执行工具再把结果拼到下一轮 Prompt 里。这里有个实践细节工具返回的结果往往很长你不要把整个查询结果全部丢给模型而是只摘取关键字段否则既占 token 又容易让模型抓不住重点。4. 实操过程与代码落地4.1 环境准备数据库与项目初始化我强烈建议用 Docker 启动带 pgvector 的 PostgreSQL避免在本地手动安装扩展。启动后先建库建用户然后执行CREATE EXTENSION IF NOT EXISTS vector;接着创建 Go 项目go mod init qa-agent go get -u gorm.io/gorm gorm.io/driver/postgres github.com/gin-gonic/gin github.com/pgvector/pgvector-gogorm 连接 PostgreSQL 时连接池参数一定要配。我之前用默认配置大批量入库时经常报connection reset后来设置了SetMaxOpenConns(30)和SetMaxIdleConns(10)问题就没再出现过。另一个容易踩的坑是连接串里的 search_path如果扩展装在 public schema一般没问题但如果你用了自定义 schema一定要确保search_path包含它否则查询会报relation does not exist。4.2 文档入库解析、切分与向量化文档解析是 RAG 项目里最脏最累的活。PDF、Word、Excel 格式各不相同我用的方案是分类型走不同解析器统一输出纯文本加表格。解析完还要清洗把页眉页脚、目录、空行全部去掉。切分策略我反复调了很久。固定按 500 个字符切经常把一个条款拦腰拆成两段导致检索到的片段语义不完整。后来改成了“按标题和段落语义切分”先用文档标题把内容分成大节大节内按段落切段落太长再按句子边界截断。每个知识块控制在 300 到 500 字并且把“文档名 章节路径”拼在正文开头保证模型即使只看到这块片段也知道它处于文档的哪个位置。切分完后调 embedding 接口向量化。这里要注意并发控制我用的方式是一个 channel 信号量同一时间最多 8 个并发请求每批 50 条全部成功后批量插入。批量插入用了 gorm 的CreateInBatches速度会明显提升。4.3 问答接口实战检索、拼 Prompt、调模型下面是一个简化版问答接口路径是POST /api/query用 gin 绑定请求参数func QueryHandler(c *gin.Context) { var req QueryRequest if err : c.ShouldBindJSON(req); err ! nil { c.JSON(400, gin.H{error: err.Error()}) return } queryVec, err : embeddingService.Embed(req.Question) if err ! nil { c.JSON(500, gin.H{error: embedding failed}) return } chunks, err : knowledgeRepo.SearchTopK(queryVec, 5, 0.75) if err ! nil { c.JSON(500, gin.H{error: search failed}) return } answer, err : qwenService.AnswerWithContext(req.Question, chunks, req.History) if err ! nil { c.JSON(500, gin.H{error: qwen failed}) return } c.JSON(200, gin.H{answer: answer, sources: chunks}) }检索部分的实现如下func (r *KnowledgeRepo) SearchTopK(vec pgvector.Vector, k int, threshold float64) ([]KnowledgeChunk, error) { var chunks []KnowledgeChunk err : r.db. Select(id, content, source, chapter, 1 - (embedding ?) AS similarity, vec). Where(is_active ?, true). Where(embedding ? ?, vec, 1-threshold). Order(embedding ?, vec). Limit(k). Find(chunks).Error return chunks, err }这里用的是余弦距离相似度等于1 - 距离。所以要过滤相似度大于 0.75等价于距离小于 0.25。这个阈值不是拍脑袋定的而是通过一批真实问题的相似度分布分析出来的后面我会细说。Prompt 组装阶段我把知识块按“编号 正文 来源”的格式拼接到 System 和 User 之间并明确要求模型必须基于给定资料回答回答中要标注资料编号如果没有足够依据就明确说不知道。模型返回后我再单独抽取引用来源列表返回给前端展示。5. 测试优化与问题排查5.1 知识库效果差的几个常见原因很多项目上线后效果不好第一反应是“换个大模型”但问题往往出在知识库侧。我总结了三种高频原因。第一种是切分不当。切得太碎检索到的片段只有半句话模型根本看不懂切得太长又会在 Prompt 里混入大量无关内容降低回答精度。我后来以“业务条款完整”为硬约束每块最多 500 字如果某条款本身就长就保留完整段落不强行截断。第二种是 embedding 模型版本不一致。知识库存量数据是用旧模型生成的线上查询却用了新模型两个模型的向量分布完全不一样结果就是相似度普遍偏低怎么调阈值都没用。这里建议把“模型名称 维度 版本”记录在配置表里每次入库和查询前校验一致性。第三种是过滤条件误伤。比如is_active false的老数据没被过滤或者知识块没有正确设置所属分类导致查询时召回范围过大。排查时可以先去掉过滤条件看召回结果是不是变准再逐步加回条件定位是哪一层过滤出了问题。5.2 千问 API 调用时的限流与超时问题接入外部大模型 API稳定性是绕不开的话题。我在压测阶段就遇到过大量超时和限流刚开始还在代码里写死重试三次结果有些请求连重试都被限流整体耗时反而更差。后来改为三管齐下第一HTTP 客户端设置连接池如果开了长连接空闲连接会自动复用第二给请求设置合理的超时时间一般是 30 秒如果超过就返回降级提示“服务繁忙请稍后再试”第三重试只针对网络错误和 5xx并且用指数退避首次等 1 秒第二次等 2 秒第三次等 4 秒最多三次。如果遇到 429 限流不要立刻重试最好解析响应头里的Retry-After或者记录限流窗口。我还在网关层做了并发信号量限制同时最多 8 个请求调用千问 API超过的请求进队列等待。这样即使前端突然来一波流量也不会把模型 API 打爆。多轮会话的 token 问题也值得注意。历史记录如果全量保留几轮下来就接近上下文上限。我的做法很简单只保留最近两轮原始对话再额外维护一个“滚动摘要”字段每轮结束后让模型把之前的要点压缩成摘要下次请求时用摘要加最近两轮替代完整历史。这招能省大量 token而且对回答质量影响很小。5.3 向量检索阈值怎么调关于阈值我提供一个可复现的调试流程。上线前收集 50 到 100 条真实问题每条问题都手工标注“正确答案所属文档和段落”。然后用系统检索这些问题的 TopK 结果画出“相似度分数分布图”。你会看到相关问题和无关问题的分数有明显分层有的项目在 0.75 附近分层有的可能要到 0.7。阈值设太高召回率不够很多问题查不到阈值设太低精确率下降容易把不相关内容塞给模型。在市场监管这种对错误零容忍的场景里我的原则是“宁缺毋滥”宁可告诉用户查不到并转人工也不要硬编一个答案。所以最后阈值定在 0.78TopK 取 5返回给前端时还会展示相似度评分让用户和运营人员都能看到信任度依据。还有一个容易被忽略的点阈值不是一劳永逸。知识库更新、新增文档类型后分数分布会变建议每个月或每次大批量导入后重新跑一遍评测集动态调整阈值。6. 部署运维与合规心得6.1 用 Docker 部署整套服务部署我选择了 Docker 加 Compose 的方式。Go 服务编译成单一二进制放进一个轻量镜像启动只需要几毫秒PostgreSQL 镜像里通过初始化 SQL 自动创建扩展。Compose 文件把服务、数据库、前端静态资源编排在一起内网环境一键起停。部署中有几个细节踩过坑的都知道。第一个是密钥管理千问 API Key、数据库密码不能写进代码仓库我用环境变量注入在 Compose 里用${QWEN_API_KEY}引用外部.env文件。第二个是日志持久化问答日志和系统日志必须挂载到宿主机目录否则容器一重建就全没了。第三个是健康检查根路径提供/healthz返回数据库连接状态和模型 API 连通性编排系统每 10 秒探活一次。最后还要注意后端服务的并发模型。Go 自带GOMAXPROCS会根据宿主机核数调整但容器环境有时识别不准建议在部署时显式设置GOMAXPROCS2或根据压测结果调整避免容器内线程暴涨。6.2 安全合规与答案审核在监管场景里做智能问答合规问题必须在技术方案里提前想清楚。我做的第一件事是设置“回答边界”低于置信度阈值的问题不允许生成答案只返回“未检索到足够资料建议联系人工窗口”。第二件事是完整留痕每次问答的入参、出参、检索到的知识块、模型原始返回、耗时、用量全部写入日志表绝不只存最终答案。这样万一出了问题可以追溯整个推理链路。第三件事是内容安全过滤。虽然技术内容本身不涉及敏感话题但用户输入可能是无关闲聊甚至恶意刷屏所以我在 gin 中间件里做了基础过滤明显无关的问题直接拦截不调用模型避免浪费配额。这里单独提一个产品层面的设计最终回答页面上一定要显示“该回答由智能助手生成仅供参考请以官方答复为准”。这句话看起来是免责声明其实是给用户建立正确预期。真实业务里再好的模型也不能替代人工审核尤其是涉及具体办理结果的时候。6.3 一些项目之外的体会做这个项目给我最大的体会是RAG 智能体的难点不在“模型”而在“知识工程”。核心链路看着很简单但真正把知识库处理到能稳定支撑业务需要投入大量时间做文档清洗、切分、标注和评测。Go 这套生态虽然缺少成熟框架所有组件都要自己拼但好处是每个环节都完全透明出了问题能直接定位到具体代码。我后来反复提醒团队的一件事是模型升级前一定要跑全量回归测试。有一次我把 embedding 模型升了级没注意向量维度变了结果生产环境所有知识库查询全部报错只能紧急回滚。之后我把“模型版本 向量维度”的校验做成了启动检查项每次服务启动都会自动比对配置表和知识库里的实际维度不一致就直接拒绝启动。这个小机制帮我避免了很多次事故。如果让我给正准备做类似项目的人一个建议那就是不要把智能体当成一个一次性交付而要当成一个需要持续维护的知识系统。先把需求边界定清楚再把知识结构梳理好最后才是模型和代码。技术栈永远在变但这条底层的做事逻辑放哪个项目都一样。