在本地把开源模型跑起来之后很多人都会遇到同一个问题模型会答但不会“查”。它不知道今天天气如何不知道最新新闻更不知道你问的那款产品现在卖多少钱。原因很简单——模型的知识有截止日期而搜索是实时的。把两者接起来让AI在回答问题之前先去网上查一圈这就是联网搜索增强也是今天要聊的这套组合拳的核心MoltBot 负责把大模型包装成服务Bocha 负责把搜索结果喂给模型两者拼在一起就是一个自带实时信息检索能力的开源 AI 助手方案。这套方案适合谁适合那些已经在本地或云端部署了开源模型、想要快速给模型加上联网搜索能力、又不愿意碰复杂编排框架的开发者。它不需要你从头搭一套 RAG 流水线也不需要你写一堆调度代码。核心思路就一句话让模型在需要的时候主动调用一个搜索函数把返回结果拼进上下文再生成答案。听起来简单真做起来还是有不少细节值得抠一抠。这篇文章就把我实际搭建这套方案的完整过程、踩过的坑、以及调参心得一次讲清楚。1. 整体设计与思路拆解1.1 为什么是 MoltBot Bocha 这个组合先聊选型。MoltBot 是一个开源的 AI 助手框架底层接的是各类开源大模型支持 API 方式对外提供服务。它最大的特点是轻——不依赖重型运行时配置好模型路径和 API Key 就能跑起来适合快速把模型能力暴露成 HTTP 接口。相比那些动辄要起数据库、要装向量引擎、要配消息队列的重框架MoltBot 更像是一个“尽职的传话筒”接收请求、组织上下文、调用模型、返回结果。Bocha 这边就是一个专门为 AI 场景设计的联网搜索服务。它跟我之前用过的一些通用搜索 API 不太一样返回的不是一长串网页链接而是经过提炼的搜索结果块每条都带着标题、摘要、原文链接和发布时间。这种结构对模型非常友好——模型不需要自己去解析一堆 HTML直接拿结构化文本就能用。这两者放在一起正好互补。MoltBot 解决了“模型怎么被调用”的问题Bocha 解决了“模型怎么获取实时信息”的问题。前者是骨架后者是血肉。1.2 核心流程从用户提问到带搜索结果的回答整体链路是这样的用户向 MoltBot 发起请求MoltBot 先把问题交给大模型。模型在 MoltBot 里注册了一个搜索工具当它判断自己不知道答案、或者问题需要实时信息时会生成一个搜索调用请求。MoltBot 拦截这个请求转发给 BochaBocha 返回结构化搜索结果。MoltBot 把结果追加到对话上下文中再让模型基于这些新信息生成最终回答。这个流程里有三个关键点第一模型必须支持函数调用Function Calling或者至少支持工具调用格式。如果模型本身不支持这条路走不通。好在现在主流开源模型基本都支持了包括比较新的那几个量级不大的模型也都带这个能力。第二搜索结果的插入位置有讲究。不能把一堆搜索结果直接堆在历史对话后面那会让模型分不清哪些是它自己说的、哪些是外部信息。我通常的做法是在系统提示词里预留一个明确的区域比如“以下是搜索到的参考资料请基于这些内容回答”然后把搜索结果放在这里同时把用户的原始问题放在最后这样模型才知道该干什么。第三超时处理。搜索是个外部调用慢的时候可能要好几秒。MoltBot 默认的推理超时可能不够用需要单独调大工具调用阶段的超时时间否则经常会出现“模型还没等到搜索结果就自己瞎编一个答案”的情况。1.3 我为什么放弃更重的 RAG 方案说实话我也试过用向量数据库 离线知识库的方式给模型做增强。效果在某些场景下确实好但问题也很明显知识库的更新太折磨人。今天新增了一条新闻你就要重新切片、重新向量化、重新灌库不然模型永远答的是旧信息。而搜索增强的方案天然就没有这个负担——每次提问都实时去网上查查到的永远是最新的。另外RAG 方案对硬件的要求也更高。向量检索虽然不重但切片和 embedding 的过程很耗 CPU如果想让检索质量好一点还得上重排模型。对于个人开发者或者小团队来说这整套东西的维护成本已经超过收益了。搜索增强的方案则简单得多——一个搜索 API 搞定全部检索逻辑模型该干嘛干嘛。2. 核心细节解析与实操要点2.1 MoltBot 的部署方式与配置关键MoltBot 的部署不算复杂但对配置文件的细节要求比较高。我第一次部署的时候就是吃了配置不够细的亏模型虽然加载成功了但一调用就报错折腾了半天才发现是一个参数单位填错了。主要的配置文件围绕着模型加载和 API 服务两部分展开。模型加载部分要关注的是模型路径、上下文长度、显存分配这几个指标。API 服务部分则要注意监听地址、端口、以及和搜索服务对接时的超时设置。我用的配置大致是这样的思路模型路径指向已经转换好的模型文件上下文长度设置成模型训练的默认长度采样参数保持默认。关键是推理超时那一项我专门为了搜索场景调大了一些。因为启用搜索后一次回答的时间 模型思考时间 搜索耗时 模型生成时间比纯对话多了一个外部调用环节。如果不把这个时间留够进程会被频繁中断。2.2 Bocha 搜索结果的结构化处理Bocha 返回的数据结构是我比较满意的地方。它不像传统搜索接口那样丢给你一堆 JSON 嵌套的原始链接而是在每个搜索结果里都保留了“标题、摘要、链接、发布时间”这样清晰的字段。我需要做的只是把它们拼成一段文本。但这里有个细节很多人会忽略拼文本的时候要按相关度排序并且把发布时间靠前的排在前面。模型对顺序很敏感如果你把旧闻排在前面它就容易优先引用旧信息。另外摘要如果太长要截断。我试过把整段摘要全塞进去结果模型回答的时候反而抓不住重点开始大段复述搜索摘要。后来我把每条摘要限制在一个可控的长度内回答的精准度立刻就上来了。还有一个关键点要过滤掉广告或推广性质的结果。Bocha 的搜索结果里偶尔会有一些带有明显推广倾向的链接这些内容混入上下文后模型可能会一本正经地引用这是很尴尬的事情。我在接入时通过关键词过滤和域名白名单的方式做了简单的清洗。2.3 模型选择对搜索效果的直接影响不是所有模型都适合做搜索增强。我踩过的坑包括有些模型虽然支持工具调用但理解力不够经常把搜索参数填错有些模型即使拿到了搜索结果也分不清哪些是事实、哪些是搜索摘要里的观点回答还是会跑偏。我给这套方案的实际模型建议是优先选择在工具调用评测集上分数较高的模型同时参数量不能太小。参数量太小的模型即使支持工具调用指令遵循能力也很弱经常出现“调了搜索但无视搜索结果继续瞎编”的情况。另外一个重点是系统提示词。很多人在用开源模型时完全不写系统提示词这是不对的。在搜索增强的场景下系统提示词的作用是告诉模型你有一个搜索工具当知识不够或信息可能过时时必须使用搜索工具当搜索结果返回后必须基于搜索结果回答不能编造。这两句话看着简单但直接决定了模型会不会用搜索、以及敢不敢编答案。3. 实操过程与核心环节实现3.1 环境准备Python 环境与基础服务我这次实操的环境比较朴素一台带 GPU 的 Linux 服务器Python 3.10 环境模型用的是公开渠道可以下载的开源权重。整个过程不依赖额外的第三方库主要就是 MoltBot 自身的依赖以及一个 HTTP 请求库。需要说明的是我没有用任何需要申请审核或填写复杂表单的平台所有依赖都是公开的 Python 包直接从软件源安装即可。这一步大概耗时十几分钟主要是网络传输的时间。3.2 MoltBot 配置编写与模型加载安装好 MoltBot 之后下一步就是改配置。我的配置内容大概长这样去掉了敏感信息后仍然可以跑通整个流程# MoltBot 服务配置示例 host: 0.0.0.0 port: 8000 model: path: /data/models/your-model-path context_length: 8192 max_new_tokens: 2048 temperature: 0.7 tool_call: enabled: true timeout: 30这里特别说一下tool_call.timeout。默认值是 10 秒左右但对搜索场景来说太短了。Bocha 的正常响应时间在 2 到 5 秒之间但网络波动时可能到 8 秒以上加上模型生成搜索调用参数的时间总耗时很容易突破 10 秒。我把它调到 30 秒之后就没再遇到过搜索超时的问题。模型加载这块没什么好说的MoltBot 会自动根据显存分配模型到 GPU。我唯一要提醒的是如果模型文件是散开的多个分片一定要让它们放在同一个目录下并且配置路径指向目录而不是某个具体文件。3.3 Bocha API 接入与搜索结果格式拼接Bocha 接入不算难核心就是发一个 POST 请求带上问题和一个 API Key。返回的 JSON 里直接就有结构化的搜索结果。我封装成了一个函数方便 MoltBot 调用。import requests def bocha_search(query: str, count: int 6) - str: url https://api.bochaai.com/v1/web-search headers { Authorization: fBearer {BOCHA_API_KEY}, Content-Type: application/json } payload { query: query, count: count, freshness: noLimit } resp requests.post(url, jsonpayload, headersheaders, timeout10) data resp.json() results data[data][webPages][value] formatted [] for item in results[:count]: title item.get(name, ) snippet item.get(summary, )[:200] link item.get(url, ) publish item.get(dateLastCrawled, )[:10] formatted.append(f[{publish}] {title}: {snippet} 源: {link}) return \n.join(formatted)这个函数会把搜索结果拼成一个多行字符串。每条结果里包含发布时间、标题、摘要和来源链接。摘要截断到 200 字以内避免太长导致上下文膨胀。freshness字段可以根据场景改成oneDay、oneWeek比如做新闻类问答时限定一天内的结果会准很多。3.4 在 MoltBot 中注册搜索工具接下来就是把这个函数注册成 MoltBot 能调用的工具。这一步要看 MoltBot 当前版本的工具定义格式但核心思路都是一样的给工具起一个名字描述它的功能列出参数结构然后绑定到具体的 Python 函数上。我习惯把工具描述写清楚一点不要写“搜索工具”而要写“联网搜索工具用于获取实时信息、新闻、天气、价格、最新动态等当用户询问实时信息或模型知识过期时使用”。描述越详细模型越知道什么时候该调用它。注册完成后我简单测试了一下。我问模型“今天某地天气怎么样”模型立刻生成了一个搜索调用请求参数是“某地 今天 天气”MoltBot 把请求转发给 BochaBocha 返回搜索结果模型基于结果给出了回答。整个流程跑通的那一刻还是有点小成就感的。4. 常见问题与排查技巧实录4.1 模型不调用搜索工具总是直接回答这是最常见的坑。模型明明支持工具调用也正确注册了搜索函数但它就是不用所有问题都凭记忆硬答。排查思路分两步。第一步确认模型在 MoltBot 的配置里已经启用了工具调用能力。有些模型的服务端默认关闭工具调用需要在配置里显式打开。我之前就遇到过配置文档里默认值是非启用的情况。第二步检查系统提示词。很多模型在没有明确指示时会倾向于直接回答因为训练数据里大部分指令都不涉及外部搜索。你需要把“必须使用搜索工具”的指令写得非常明确甚至可以带上触发规则。比如“当用户询问实时信息或你不确定答案时必须先调用搜索工具再基于搜索结果回答”。4.2 搜索结果返回了但模型答非所问这个问题的典型表现是搜索功能正常Bocha 也返回了不错的摘要但模型的回答完全没有引用搜索结果还在自顾自地发挥。原因往往是上下文拼接的格式不够规范。模型需要非常清楚地知道哪些内容是“参考资料”哪些内容是“用户问题”。我推荐的做法是在发送给模型的 prompt 里用分隔线把搜索结果和问题隔开。格式大概这样请阅读以下搜索结果并基于这些内容回答用户问题。 搜索结果 [发布日期] 标题: 摘要 源: 链接 /搜索结果 用户问题: 今天天气怎么样这样模型就很容易理解它不是在做开放问答而是在做基于给定材料的阅读理解和摘要。加上这个结构之后答非所问的频率明显下降了。4.3 Bocha 搜索超时或返回错误码搜索 API 偶尔会不稳定尤其是在高峰期。我自己遇到过比较多的是 429请求过于频繁和 5xx服务端错误。针对这类问题我的处理方式是在搜索函数外包一层简单的重试机制第一次请求失败后等待两秒重试最多重试三次如果还是失败就返回一个“搜索暂时不可用”的占位文本并让模型直接基于自身知识回答。有人可能会问搜索不可用时让模型硬答不是又会胡说八道吗我的想法是两害相权取其轻。如果搜索挂了至少用户还能得到一个交互式的回答而不是干等超时。同时可以在占位文本里注明“搜索结果暂无”这样模型会倾向于用更谨慎的语气回答比如加上“根据我的了解”“可能”这类措辞。4.4 上下文窗口被搜索结果撑爆搜索结果如果太多或者摘要太长很容易把上下文窗口塞满。尤其是当历史对话已经很长的时候再加一段搜索结果模型可能直接报错。我的经验是给搜索结果设置一个上限。Bocha 返回的结果数量可以调我默认设置 6 条每条摘要截断 200 字这样算下来搜索结果的文本量基本能控制在 1500 字以内。如果要追求更精准的答案可以把数量减少到 4 条但摘要截断放宽到 300 字。另外还要注意历史对话的裁剪。MoltBot 内部有历史消息管理在开启搜索后建议把历史消息的最大轮数减少一些比如从 20 轮降到 10 轮。因为搜索占用的 token 是额外开销你不给历史对话留出余量上下文迟早会溢出。5. 优化思路与实际体验5.1 让搜索触发更智能一点目前的触发机制依赖模型自己判断是否调用搜索这有个天然缺陷——模型偶尔会过度调用明明能答的问题也要搜一下偶尔又过于自信该搜的不搜。针对这个问题可以在系统提示词里做更细粒度的规则约束。我自己试过比较有效的一个办法是给模型举例子。在系统提示词里写上几条用户问题和对应的工具调用行为比如用户问“帮我写一首关于秋天的诗” - 不调用搜索用户问“今天股票行情怎么样” - 调用搜索用户问“介绍一下某个新发布的产品” - 调用搜索这种 few-shot 示例的方式比单一规则约束要有效得多。模型通过类比来判断什么时候该搜、什么时候不该搜比理解抽象的“实时性”和“确定性”概念容易得多。5.2 搜索范围预筛选限定地区、语言、时间Bocha 的搜索参数里还有一些可以调整的项比如结果的语言偏好、搜索地区、以及前面提到的时间范围。做中文场景时把语言参数设定为中文返回的结果相关性会明显好于默认设置。做新闻追踪场景时把时间范围限定在一天内可以过滤掉大量旧内容。这一层筛选如果放到代码层面就是在调用搜索之前先判断一下用户问题的语义。比如问题里含“天气”就给搜索结果加上当天的限制含“最新”“发布”就加上一周或一天的限制。这样每一类问题都用最合适的时间窗口去搜索检索质量会提升不少。5.3 回答质量的实测对比我拿一些常见问题做了对比测试。在同一组问题上关闭搜索和开启搜索的回答质量差异还是挺明显的。涉及具体数字、最新发布、热点事件的问题开启搜索后的准确率大幅提升。而一些常识类问题比如“某个经典编程概念是什么”两者差别不大模型本身的储备已经足够。这里想给一个比较中肯的建议搜索增强不是所有场景的银弹。如果你的用户群体问的都是稳定的知识类问题模型本身就能答得不错加搜索反而增加了延迟。但如果你的场景涉及咨询、比价、资讯获取、政策更新这类实时性强的需求搜索增强带来的收益是立竿见影的。5.4 延迟与成本的权衡加了搜索之后回答延迟不可避免会增加。纯对话可能一两秒就出结果了搜索增强后至少要等搜索请求往返的时间整体耗时大概在 4 到 8 秒之间。这在异步消息场景下完全没问题但如果你的前端是流式输出用户会明显感觉到首字变慢。成本方面搜索 API 是按调用次数计费的每次搜索的调用成本通常很低但架不住调用量大。我这里做了一个简单的限制策略同一个用户在五分钟内的搜索次数最多 10 次。防止高频调用把每个月的搜索配额烧光。这个限制对正常使用来说完全够用。6. 实际部署中的注意事项6.1 安全与隐私你的搜索会留下痕迹任何联网搜索服务都会记录你的搜索词。如果你做的事情涉及敏感数据建议不要把原始问题直接拿去搜索而是让模型先对问题做一次脱敏改写再提交给搜索服务。比如用户问“我的项目某配置该怎么调”模型先提取出关键的技术关键词再搜索避免原样把完整问题发出去。MoltBot 本身支持在工具调用前对参数做处理可以在搜索函数内部实现这个脱敏逻辑。多写几行代码换来的是隐私层面的安心这笔账还是划得来的。6.2 请求体大小限制与响应处理无论服务跑在本地还是容器里建议检查一下反向代理或网关对请求体的限制。搜索结果拼接后的字符串虽然不大但如果并发量高还是会占一些带宽。另外搜索函数的异常处理要做得健壮一些。我和 MoltBot 联调时发现如果搜索函数抛异常MoltBot 会把它当作工具调用的执行失败有时候会把错误信息直接回传给模型导致模型回答时前言不搭后语。正确的做法是在函数内部捕获所有异常返回一个标准化的失败占位文本这样模型能理解“搜索没成功”而不是看到一堆堆栈信息。6.3 日志与调试的实用技巧调试搜索功能时强烈建议把工具调用的完整参数和搜索结果记录到日志里。MoltBot 本身带了日志模块但默认的日志级别可能不够详细。可以把工具调用相关的日志级别调到调试模式这样能看到模型生成的搜索参数以及函数返回的结果。我实际排查问题的时候最常用的一招就是把搜索函数返回的文本原样保存到文件里然后用命令行工具查看拼接后的 prompt 实际长什么样。很多时候你觉得模型答得不好看了 prompt 才发现是拼接格式的问题模型其实是无辜的。掌握这个技巧之后很多玄学问题都能一眼定位。我在实际使用中还有一个习惯在开发环境里单独写一个测试脚本不经过 MoltBot直接调搜索函数验证返回的文本里有没有广告、有没有乱码、时间格式对不对。等这一层验证通过了再去 MoltBot 里集成。把复杂链路拆成独立环节来调试效率会高很多这也是我踩过多次坑之后总结出来的经验。这套 MoltBot Bocha 的方案本质上是用最轻量的方式给开源模型补上了实时信息这块短板。它不算完美偶尔模型还是会出现“搜了也不看”的情况但它已经能覆盖大部分需要联网知识的真实场景。如果你也正在为模型的时效性发愁不妨照着这个思路自己搭一套试试成本不高收获却非常直接。