从零搭建网页知识库：让Chatbot联网检索并带引用回答

你是不是也遇到过这种场景把某个刚发布的问题丢给Chatbot它一本正经地回答了一大段结果关键信息全是过时的甚至直接编了个出处。想让它查一下某个最新网页它又只会说“我无法实时访问互联网”。把网页变成可引用知识给Chatbot加一套联网工具目的就是解决这个问题不是给机器人装个浏览器而是让它先检索、再阅读、最后带着来源回答。这篇文章我会把整个思路拆开讲清楚。从网页内容怎么抓、怎么清洗、怎么切成知识块到如何用向量检索把问题映射到相关片段再到如何让Chatbot在回答时附上可点击的引用来源完整走一遍。方案不依赖任何特定厂商大部分模块你都可以自己动手搭适合想做私人知识助手、垂直问答机器人或者单纯想给聊天机器人补上“联网能力”的开发者。1. 为什么要把网页变成“可引用知识”1.1 离线大模型的天花板知识截止时间与幻觉问题现在大多数Chatbot底层是预训练好的大模型它学到的是训练数据截止之前的内容。哪怕模型再强关于半年后的新版本发布、某个网站的实时报价、某篇刚上线技术文档里的参数它都没见过。这种“不知道还能装知道”的情况就是幻觉。模型会基于已有的概率分布去补全一个看似合理的答案但它没有任何依据结果就是答错、编造来源、甚至自创术语。我之前做过一个小工具让机器人回答某技术框架的新特性。它把上一个版本的API特性当成最新的回答得特别笃定还附上了样式很真实的文档引用结果一查根本没有那个接口。这个教训让我意识到与其想办法让模型“记住更多”不如换一条路在用户提问的时候实时把相关网页内容拉过来作为生成回答的参考资料。这不光是解决“最新”问题也是解决“不确定”问题的通用思路。1.2 联网不是“开浏览器”而是把网页变成结构化知识块很多人想象联网工具就是让Chatbot调个浏览器像人一样上网冲浪。实际操作中完全不是这样。要Chatbot真正利用网页内容必须把网页从HTML变成可处理的文本再切成适合检索的知识块然后让模型基于这些知识块回答。关键点在于“可引用”。如果只是把整个网页内容扔给模型模型依然可能混着自己的知识来回答。我们希望它回答的每一句重点都能对应回网页中的某一段所以网页内容必须被结构化、分块、附带来源信息。可以理解成先给网页内容贴好标签、放进盒子再让机器人在回答时从盒子里拿证据并且把盒子编号亮出来。这个流程技术圈叫RAG检索增强生成。1.3 两种实现路线对比插件式搜索与本地RAG式知识注入现在市面上常见的联网Chatbot有两种做法。第一种是插件式搜索Chatbot调用一个搜索引擎接口拿到搜索结果后直接让模型浏览若干条网页摘要然后生成回答。这种方式部署快但问题在于搜索引擎返回的摘要信息很有限很多网页的关键内容在摘要里根本没有而且引用不够细往往只能给到“来自某个网页”没法具体到哪句话。第二种是本地RAG式先抓取网页全文清洗后切块保存成向量索引。用户提问时系统先检索出最相关的几个知识块再连同原始网页URL一起交给模型。这种方式的优势是引用能精确到段落回答质量更可控适合对准确度要求高的场景。对比项插件式搜索本地RAG式部署复杂度低接入搜索接口即可较高需要抓取、清洗、索引、检索模块信息颗粒度依赖搜索引擎摘要较粗可精确到网页段落引用可溯源性只能到网页级别可以到片段级别对动态网页的支持依赖搜索引擎收录可自行抓取控制力更强本文后面主要围绕本地RAG式来展开因为它更能体现“把网页变成可引用知识”的价值。2. 网页知识化的三步基础工作2.1 抓取前先回答三个问题授权、稳定性、解析成本很多人一上来就写爬虫把网页抓下来结果踩一堆坑。我建议动手前先过一遍三个问题。第一个是授权。不是所有网页都能随便抓。要在代码里做两件事抓取之前查看目标站点的robots.txt尊重里面允许抓取的路径优先使用站点提供的开放API或官方文档尽量抓那些公开、不需要登录就能访问的内容。如果某些内容明确写了禁止采集那就不要碰。第二个是稳定性。网页内容会变今天抓到的东西明天可能就改了。要给每次抓取打上时间戳并且在引用时附上“抓取时间”这样至少出问题时能定位。第三个是解析成本。有些网站页面结构很复杂正文藏在多层嵌套的div里需要专门写提取规则有些是动态渲染返回的HTML里根本没有正文得额外跑一次无头浏览器。所以第一步先抓少量页面摸清结构别一上来就批量采集。2.2 正文提取与去噪从HTML里找出真正有用的段落网页的HTML里正文之外的东西太多了导航菜单、侧边栏、推荐模块、广告脚本、评论区。如果把这些噪声全塞进知识库检索效果会非常差因为模型分不清哪个是重点。我常用的流程是先去掉script、style、noscript标签里的内容再用HTML解析器抽取文本然后根据文本密度来判断哪些区域更像正文。一个简单但好用的经验是正文区域的文本密度高、链接密度低。导航和侧边栏通常是一堆短链接文本密度低。像“Readability”这类正文提取算法本质也是基于这个特征。清洗完HTML标签后还要做文本规范化把多个空白字符压缩成空格去掉奇怪的零宽字符统一换行符。这个步骤看似简单但如果漏了后续分块时会出现一个句子被拦腰截断或者知识块夹杂大量不可见字符导致向量化质量下降。我踩过的坑是某些网站的正文里有“下一页”链接被当成正文文本提取出来导致知识块里出现“下一页 上一页 返回顶部”这种垃圾片段。后来我在清洗阶段把常见导航关键词过滤掉效果立竿见影。这里的关键是宁可清洗策略保守一点也不要让噪声进入知识库。2.3 分块长文本切不好检索效果直接崩把清好的正文文本按固定长度切块是最容易犯的错误。固定长度切块会把完整语义切断。比如一个技术步骤的前半句在第1块后半句在第2块检索时可能只命中其中一块Chatbot根据一半信息回答自然出错。我推荐按语义边界来分块。至少要做到优先按段落切把长段落再按句子切并且让相邻块之间有少量重叠。重叠的目的是避免一个关键事件被切成两半时丢失上下文。比如每块500字相邻块重叠50字这样即使检索命中了边界区域上下文也能保持完整。分块长度不是越大越好。块太大向量化后的语义过于笼统检索时容易把不相关的内容也召回块太小上下文信息不够模型难以组织完整回答。实际操作中500到800字是多数场景的甜点区。如果你处理的网页是技术文档可以把块再小一点如果是新闻类文章则可以稍微大一点因为新闻段落本身信息密度高。另外分块时要把来源信息绑定在每个块上。每条知识块至少有三个字段文本内容、来源URL、抓取时间。这样后面做引用标注时才有数据可用。3. 让Chatbot“查得到也答得对”检索与引用机制3.1 向量化与召回把用户问题翻译成向量网页文本切好块之后要转成向量才能被检索。这里说的向量是让文本变成一组数字语义相近的文本在数字空间里距离更近。比如“苹果公司股价”和“苹果收盘价”字面上差别很大但语义接近它们的向量距离就会比较近。嵌入模型负责做这个转换。你可以用一个开源的句向量模型也可以调用某个大模型服务商提供的向量接口。要注意的是用于索引网页文本的模型和用于检索用户问题时的模型必须是同一个模型。很多人在这一步翻车因为文本嵌入选了A模型用户问题却用B模型转换两个模型向量空间不一致相似度计算完全不准。召回阶段不需要太复杂的算法。把用户的问题向量和所有知识块向量做余弦相似度计算取分数最高的前几块。数据量小的时候直接内存里算数据量大了再上专门的向量检索服务。对一个个人项目几千个知识块完全没必要上重型组件简单方案就能跑。我个人的经验检索时不要把问题直接丢进去可以做一次轻量改写。比如用户问“这个工具怎么配置”可以改写成“这个工具的配置步骤”。改写的目的是让问题更像知识库里的文风。实现起来要么让模型改写要么人工维护几个模板不必过度设计。3.2 重排序与相关性阈值宁可答“不知道”也别乱引用向量召回的结果往往只有前几名是真正有用的后面几名可能只是沾边。我强烈建议加一个重排序步骤。简单做法是把召回的候选块和用户问题拼成一个文本对让一个更强的模型输出相关性分数再按这个分数重新排序。重排序能解决很多尴尬场景。比如用户问“如何在项目里接入图片压缩”向量召回可能把一篇讲“图片格式选型”的文章排在前面但真正讲“接入压缩工具”的段落排名反而靠后。重排序之后更相关的段落会浮上来。还要设置一个最低相关性阈值。低于阈值的知识块不要让Chatbot强行引用。否则它会把一个无关网页的内容当成依据生成看似合理但实际跑偏的回答。宁可让它说“暂时没有找到相关资料”也比给一个带链接的错误答案好。这个阈值没有通用值需要在你的知识库上调。我的做法是先跑一批测试问题看看哪些正确回答对应的分数分布再拿高分中的最低分作为参考线。3.3 引用溯源设计让每句话都能找到出处可引用知识的核心就是回答要有来源。实现方案很直接Chatbot生成回答时在关键句后面标记引用编号比如[1]、[2]然后在回答末尾列出编号对应的来源URL和页面标题。这里的关键是你要把知识块本身作为“证据”传进提示词并明确告诉模型只能基于这些证据回答且引用编号必须和证据编号一一对应。如果模型引用了某个证据那这个证据必须实际出现在输入里而不能自创编号。我在调试时发现一个坑模型有时候会把多个来源的内容缝合起来然后给每个来源都标上引用结果某个来源根本没有支撑这句话。为了解决这个问题可以要求模型在引用时引用完整证据编号并在输出结构上做一次校验检查所有出现的引用编号是否都在输入证据列表里。凡是出现不存在编号的回答直接判定为非法输出重新生成或者丢弃。提示词里的措辞也很重要。我常写的一段是“以下是从网页中抽取的知识片段每个片段前面有编号。请只根据这些片段回答用户问题。回答中使用[编号]标注信息来源。如果片段中没有相关信息请明确回答不知道。”这种明确约束比单纯说“请引用来源”有效得多。3.4 与Chatbot的接入方式函数调用/工具调用要让整个人能跑起来Chatbot必须知道自己什么时候该调用联网工具。目前主流做法是功能调用Function Calling。你定义一个函数比如“搜索网页知识库”描述参数和返回内容然后把函数定义随着用户消息一起传给模型。模型判断需要调用时会返回一个结构化的调用请求系统执行函数把结果作为新消息传回给模型模型再基于结果生成最终回复。这里要特别注意不要把整个网页原文全部返回给模型而是只返回检索到的几个知识块。知识块要控制总量一般3到5块、每块五六百字已经足够。如果返回太多上下文模型会“淹没”在无关信息里回答质量不升反降还可能把生成时间拖得很长。接入方式做到这里整个闭环已经形成了用户提问模型决定调用联网工具系统抓取并检索网页知识块模型根据知识块生成带引用的回答。下一步就是把它真正实现出来。4. 手把手搭一个最小可用的“网页知识Chatbot助手”4.1 整体流程与模块划分我建议把系统拆成两个模块离线的“网页知识入库”和在线的“检索生成”。离线模块负责把指定网页抓下来、清洗、分块、向量化并存储在线模块负责把用户问题向量化、检索知识块、调用生成模型回答。离线入库可以设计成定时任务也可以做成输入URL即可更新的接口。在线生成则是每次对话实时执行的。两个模块共用同一个embedding函数和分块函数避免两边逻辑不一致。4.2 关键代码网页处理模块下面这段代码是网页抓取和正文提取的最小示例。用Python标准库加上一点点正则处理就能跑通。真实项目建议换成更成熟的解析库。import urllib.request import re import html as html_lib def fetch_page(url): req urllib.request.Request(url, headers{User-Agent: knowledge-bot/1.0}) with urllib.request.urlopen(req, timeout10) as resp: return resp.read().decode(utf-8, errorsignore) def extract_main_content(raw_html): # 去掉脚本和样式 raw_html re.sub(r(script|style)[^]*.*?/\\1, , raw_html, flagsre.S) # 去掉标签 text re.sub(r[^], , raw_html) # 反转义 text html_lib.unescape(text) # 压缩空白 text re.sub(r\\s, , text) return text.strip() def chunk_text(text, max_len500, overlap50): # 优先按句子切超过max_len再截断 sentences re.split(r(?[。.!?]), text) chunks [] cur for sent in sentences: if len(cur) len(sent) max_len: cur sent else: if cur: chunks.append(cur) # 如果句子本身特别长按max_len硬切 while len(sent) max_len: chunks.append(sent[:max_len]) sent sent[max_len - overlap:] cur sent if cur: chunks.append(cur) return chunks这个实现的正文提取比较粗糙但足以作为原型。抓回来的页面如果发现正文提取结果里混入了大量导航文字你就需要换更复杂的提取策略比如参考开源的正文提取算法。前面之所以说先用少量页面测试就是避免把粗糙的正则策略直接铺到全部页面上。注意抓取时一定要设置超时时间并且做好异常捕获。有些站点响应很慢如果不加超时整个入库流程会被一个网页卡死。还应当做好抓取频率控制不要对同一站点短时间高频请求。4.3 关键代码检索生成模块接下来是向量化和检索部分。嵌入函数我先用embed_text()代指实际项目里替换成你自己的模型接口。import numpy as np def embed_text(text): # 实际使用开源的句向量模型或向量服务接口 # 返回一个list[float] return model.encode(text) def cosine_sim(a, b): a np.array(a) b np.array(b) return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))) def search_knowledge_base(query, chunks, top_k5): q_vec embed_text(query) scored [] for chunk in chunks: score cosine_sim(q_vec, chunk[embedding]) scored.append((score, chunk)) scored.sort(keylambda x: x[0], reverseTrue) return scored[:top_k]这里的chunks是从知识库里读出来的每条包含text、url、embedding。检索结果拿到后再送进重排序模块。重排序可以复用大模型也可以用一个更轻量的相关性分类模型。就个人项目而言直接用和Chatbot相同的模型对候选块打分也够用。重排序后的结果要拼装成给Chatbot的提示词。每条证据前加编号编号建议用稳定的ID而不是列表下标避免后续插入新证据时串号。4.4 关键代码带引用的回答生成生成环节的伪代码长这样def generate_answer(query, top_chunks): evidence_prompt for idx, item in enumerate(top_chunks): evidence_prompt f[{idx}] 来源: {item[url]}\\n内容: {item[text]}\\n\\n prompt f请根据以下知识片段回答用户问题。 要求 1. 只能使用片段中出现的信息。 2. 回答中每个关键句末尾用[编号]标注来源。 3. 如果片段中没有相关信息直接说“未找到相关内容”。 知识片段 {evidence_prompt} 用户问题{query} response call_chat_model(prompt) return response运行之后Chatbot会输出带[1][2]标记的回答。你在展示层把标记渲染成可点击的链接即可。这一步看似简单但要注意提示词里的“只能使用片段中出现的信息”这一句不能少。没有这个约束模型一遇到不确定内容就会放飞自我。4.5 参数调优让结果更可靠的小实验搭好原型后一定不要急着上线。拿二三十个包含不同类型问题的测试集跑一遍人工判断每个回答有没有答非所问、有没有错误引用。需要调的参数主要是分块大小、重叠长度、召回数量、相关性阈值。我见过一个项目把召回数量从3调到5准确率反而下降因为多出来的两块都是噪声模型被带偏了。参数这事没有银弹必须基于你的数据亲自测。5. 我从零搭这个工具踩过的坑5.1 动态网页内容抓不到先找接口再渲染我最初处理某个资料站时用普通HTTP请求抓到的HTML里干干净净正文完全不在。检查后才发现页面是JavaScript渲染出来的浏览器显示的内容都是后端异步加载后填充的。第一反应是上无头浏览器但无头浏览器很重吃内存抓取速度还慢。后来我打开浏览器的开发者工具观察页面加载时的网络请求发现正文数据其实是一个独立的JSON接口返回的。直接请求这个接口效率高得多。经验是遇到动态页面先找找背后的数据接口实在找不到再用无头浏览器。无头浏览器是兜底方案不应该成为默认方案。5.2 网页被改了、链接失效引用要兜底网页内容是活的。我上个月刚索引完的一篇文章这个月再点开链接已经404了。如果Chatbot还把这个链接引用出来用户点过去就是死链。后来我做了两层兜底第一层入库时除了存原始URL还存一份抓取时的HTML快照第二层在回答展示时如果链接失效自动把引用切换成“已缓存页面”的入口。这样即使源头失效用户至少还能看到当时的文本。这个体验差异非常大。5.3 部分网页的正文里全是广告和推荐链接有个页面提取出来的文本前两段是正文后面一大段都是“大家都在看”“热门推荐”。会让模型误以为推荐内容也是正文的一部分回答时把无关内容扯进来。处理办法是在清洗阶段过滤掉包含特定关键词的段落比如“推荐”“热门”“点击查看”。但关键词过滤要谨慎有些正文本身也会用这些词。更好的办法是引入文本密度分析只保留正文主区域。5.4 别让每个问题都重新抓网页刚开始我把“联网”理解为实时抓取用户每次提问都去抓一遍网页。结果速度慢、接口成本高还容易被站点屏蔽。后来改成离线定时入库每天定时抓取指定网页列表更新知识索引用户提问时只从已入库的知识块里检索。这样实时性虽然差了一些但稳定性和成本都友好很多。如果确实需要抓取最新页面可以做一层URL级缓存同一个URL在十分钟内只抓一次。6. 还能怎么扩展从演示到生产级知识库6.1 增量更新与定时巡检手工维护URL列表肯定不是长久之计。生产级系统应该支持增量更新你可以订阅站点的RSS或者定时跑一遍URL列表对比网页指纹判断内容是否变化。只有内容变化过的页面才重新抓取和向量化节省大量资源。定时巡检还可以顺带做一些清理工作遇到内容已删除的页面及时从知识库中标记失效。6.2 多源聚合与去重当你同时抓取多个同类站点会发现大量内容重复。同一篇技术文章可能在几个站点都被转载。如果不去重检索时会召回语义几乎一样的多个知识块浪费提示词空间也可能让回答变啰嗦。做法是在入库前计算正文的SimHash或MinHash重复度过高的内容只保留一个来源或者把多个来源合并成一个证据引用时列出所有地址。6.3 离线缓存与权限控制如果你的知识库里包含非公开内容引用时要注意权限控制。不要让Chatbot把需要登录才能看的内容通过工具接口输出给未授权用户。简单方案是给每个知识块打权限标签检索时根据当前用户身份过滤。还有一个容易被忽略的点聊天记录的展示层要有“来源不代表背书”的提示因为网页本身也可能出错。6.4 评测闭环让每一次提问都变成一次数据记录无论功能多么完善没有评测体系就无法持续优化。我建议把每次问答的数据都记录下来用户问题、召回的候选块、最终引用编号、用户是否点了引用链接、是否对回答点了“有帮助”。这些数据攒多了能非常清楚地暴露出检索模块和提示词的问题。比如某类问题总是命中低质量页面你会看到这类问题下用户点击来源的比例很低这时候就该去调知识库的过滤规则了。我做完这套工具后的体会是联网Chatbot真正难的不是调用模型而是让“网页知识”变成可信、可溯源、可维护的资产。抓取和向量化只是基本功检索质量的调试、引用链路的设计、内容的持续更新才是长期要打磨的地方。如果你的聊天机器人也经常被说“瞎编”不妨按照这个思路给它配一套能查会引用的联网工具。