1. 项目概述从“读”网页到“懂”网页的AI进化最近在折腾一个很有意思的玩意儿怎么让AI模型比如ChatGPT或者本地部署的大语言模型真正“读懂”一篇网页文章并且能基于文章内容进行精准的问答。这听起来像是让AI拥有了“阅读理解”的能力而实现这个能力的核心技术就是RAG。RAG全称是检索增强生成。你可以把它想象成给一个博闻强识但记忆力不牢靠的学者配了一个超级高效的私人图书馆管理员。这个学者大语言模型本身知识渊博能说会道但当你问他一个非常具体、细节的问题时他可能因为“记不清”而开始胡编乱造也就是我们常说的“幻觉”。而RAG里的“检索”环节就是那位管理员。当学者被提问时管理员会立刻冲进图书馆你的知识库找到与问题最相关的几本书文本片段塞到学者手里。学者看了这些精准的资料后再结合自己的知识进行回答这样答案的准确性和可靠性就大大提升了。我这个项目的核心就是搭建这个“私人图书馆”的第一步知识入库。我选择了一篇技术社区“掘金”上的文章作为目标因为它结构清晰、内容专业是测试知识处理流程的绝佳样本。整个流程可以概括为用Cheerio这个工具把网页“爬”下来提取出纯净的文本内容然后用TextSplitter文本分割器把这些长篇大论“切”成易于消化的小块最后把这些文本块转换成数学意义上的“向量”存进专门的“向量数据库”里。这样一来当用户提问时系统就能快速计算出哪个文本块和问题最相关从而实现精准检索。下面我就带你一步步拆解这个过程中的每一个技术选择和实操细节。2. 技术栈选型与核心思路拆解为什么是这套组合拳每一个工具的选择背后都有其明确的场景适配性和效率考量。这不是随便抓几个热门词拼凑起来的而是针对“处理网页技术文章并构建可检索知识库”这个具体任务经过权衡后的方案。2.1 为什么用Cheerio而不是Puppeteer或Selenium处理网页第一关就是获取内容。面对一个动态渲染的现代网页你可能听过Puppeteer或Selenium这些“重量级”选手它们能模拟完整浏览器环境执行JavaScript适合处理高度动态、依赖JS渲染的内容。但掘金、知乎、CSDN这类技术博客的文章详情页其核心文章内容通常在初次HTML请求中就已经包含并不需要等待复杂的JS交互来生成。这时候动用Puppeteer就等于“高射炮打蚊子”——杀鸡用牛刀。Cheerio的核心优势就在这里轻量、快速、纯粹。它不是一个浏览器而是一个在服务器端Node.js运行的HTML解析库。它的API设计几乎完全模仿了jQuery对于前端开发者来说上手极其友好。你只需要把网页的HTML字符串扔给它它就能让你用熟悉的$(‘selector’)语法来遍历和操作DOM节点提取你想要的任何元素。对于我们的目标——提取文章标题、正文、作者信息——这再合适不过。它不执行JS不加载图片和CSS因此速度极快资源消耗极小非常适合构建自动化的内容抓取管道。注意Cheerio的“阿喀琉斯之踵”也正是它不执行JS。如果目标文章的内容是通过JavaScript异步加载的比如某些单页面应用Cheerio抓取到的div可能是一片空白。这时就需要评估是否换用Puppeteer。好在主流技术博客平台为了SEO友好普遍采用服务端渲染核心内容都在初始HTML中Cheerio足以胜任。2.2 RAG流程中的关键角色Loader, Splitter, Embedding Model, Vector DB构建RAG系统就像一条流水线每个环节都有专门的角色负责。Loader加载器它的任务是从各种数据源网页、PDF、Word、Notion、数据库中读取原始数据并转换成统一的文本格式。在我们的项目里Cheerio结合Node.js的axios或fetch完成了Loader的工作——获取HTML并提取文本。Text Splitter文本分割器这是本项目的一个核心难点。大语言模型有上下文窗口限制比如4096或128K tokens你不能把一整篇上万字的文章直接塞给模型。同时为了检索的精度我们需要把文章切分成语义相对完整的小块Chunks。分割的策略直接影响后续检索的效果。切得太碎语义支离破碎切得太大会包含无关信息降低检索精度。我们稍后会深入讨论分割策略。Embedding Model嵌入模型这是将文本“向量化”的关键。它接受一段文本输入输出一个固定长度的、高维度的向量一组数字。这个向量就像是这段文本在数学空间中的“坐标”或“DNA指纹”。语义相近的文本它们的向量在空间中的距离通常用余弦相似度衡量也会很近。我们使用开源的sentence-transformers库或OpenAI的text-embeddingAPI来完成这一步。Vector Database向量数据库专门为存储和检索向量数据而优化的数据库。它不仅能存向量更能基于向量之间的相似度进行快速检索近似最近邻搜索ANN。当用户提问时我们会先将问题用同样的Embedding Model转换成向量然后去向量库中搜索与它最相似的几个文本块向量。常见的向量库有Chroma轻量、易用、Pinecone云服务、强大、Qdrant、Weaviate等。我选择Chroma是因为它可以本地运行无需网络适合个人项目和快速原型验证。2.3 本地化与成本考量整个流程我坚持“本地化”原则。Cheerio、文本分割、本地嵌入模型如all-MiniLM-L6-v2、Chroma向量库都可以在本地环境运行。这带来了几个好处一是完全免费没有API调用费用二是数据隐私有保障原始文本和向量都在自己机器上三是网络依赖性低离线也可工作。这对于处理内部技术文档、构建个人知识库助理等场景非常有吸引力。当然如果你追求顶级的嵌入效果如OpenAI的text-embedding-3系列或需要处理海量数据云服务是更专业的选择。3. 实操详解从网页到向量库的完整流水线理论说再多不如一行代码。我们直接进入实战环节我会以Node.js环境为例展示每一个步骤的具体实现和关键代码。3.1 第一步使用Cheerio精准抓取与内容清洗首先我们需要安装必要的依赖axios用于网络请求cheerio用于解析。npm install axios cheerio然后我们编写抓取脚本。这里的关键在于精准定位和清洗。const axios require(‘axios’); const cheerio require(‘cheerio’); async function fetchJuejinArticle(url) { try { // 1. 获取HTML const { data: html } await axios.get(url, { headers: { ‘User-Agent’: ‘Mozilla/5.0 ...‘ // 模拟浏览器避免被反爬 } }); // 2. 加载HTML到Cheerio const $ cheerio.load(html); // 3. 精准定位元素以掘金文章页为例需实际分析DOM结构 const title $(‘.article-title‘).text().trim(); // 文章标题 const content $(‘.article-content‘).html(); // 文章正文HTML // 4. 清洗内容移除代码块、图片、无关标签保留纯文本段落 // 这里使用一个简单的清洗函数 const cleanText cleanHtmlContent(content); return { title, content: cleanText, source: url }; } catch (error) { console.error(‘抓取文章失败:‘, error.message); return null; } } function cleanHtmlContent(html) { const $ cheerio.load(html); // 移除脚本、样式、注释 $(‘script, style, noscript, iframe‘).remove(); // 处理代码块可以保留但标记或直接移除。这里选择移除因为后续可能单独处理代码。 $(‘pre, code‘).remove(); // 将连续的br和多个空格、换行符标准化 let text $.text(); text text.replace(/\s/g, ‘ ‘).trim(); return text; } // 使用示例 (async () { const article await fetchJuejinArticle(‘https://juejin.cn/post/123456789‘); if (article) { console.log(‘标题:‘, article.title); console.log(‘正文长度:‘, article.content.length); } })();实操心得网页结构会变今天有效的CSS选择器明天平台改版可能就失效了。因此在生产环境中需要将选择器配置化并建立简单的监控或回退机制。另外cleanHtmlContent函数可以根据你的需求定制比如你想保留代码块作为特殊的知识片段就可以不删除pre标签而是提取其内容并加上“代码”前缀。3.2 第二步文本分割的艺术与科学拿到纯净的文本后接下来就是分割。这是RAG效果的核心杠杆之一。我使用langchain库提供的文本分割器它提供了多种策略。npm install langchain为什么不能简单按固定长度切分想象一下你有一句话“这个项目的核心技术是RAG它包含了检索和生成两个步骤。”如果你在“RAG”后面一刀切那么前半句“这个项目的核心技术是RAG”和后半句“它包含了检索和生成两个步骤”在语义上都不完整丢失了关键联系。这会导致检索时可能只命中半句话无法提供完整信息。理想的分割策略是在尽量保证语义完整性的前提下控制块的大小。langchain的RecursiveCharacterTextSplitter递归字符文本分割器是常用选择。它的工作原理是尝试用不同的分隔符如“\n\n”、“\n”、“。”、“”、“”、“”、空格递归地将文本分割开来直到每个块的大小满足要求。const { RecursiveCharacterTextSplitter } require(‘langchain/text_splitter’); async function splitText(content) { // 创建分割器实例 const splitter new RecursiveCharacterTextSplitter({ chunkSize: 500, // 目标块大小字符数 chunkOverlap: 50, // 块与块之间的重叠字符数 separators: [‘\n\n‘, ‘\n‘, ‘。‘, ‘‘, ‘‘, ‘‘, ‘ ‘, ‘‘] // 分隔符优先级 }); // 执行分割 const chunks await splitter.createDocuments([content]); // createDocuments返回的是Document对象数组每个有pageContent属性 return chunks.map(doc doc.pageContent); } // 使用示例 const cleanText ‘...‘; // 上一步清洗后的长文本 const textChunks await splitText(cleanText); console.log(共分割成 ${textChunks.length} 个块); console.log(‘第一个块:‘, textChunks[0]);关键参数解析chunkSize块大小这是最常被问到的参数。设置多少合适这没有银弹取决于你的嵌入模型上下文长度和文档类型。对于技术文章我的经验是200-500字符适合短问答、事实性检索精度高但可能上下文不足。500-1000字符通用性较好能容纳一个小节或几个段落平衡了精度和上下文。1000-2000字符适合需要较长上下文理解的概念性内容但检索可能引入更多噪声。我选择500作为一个起点因为它能容纳2-3个自然段对于解释一个概念通常足够。chunkOverlap重叠大小这个参数至关重要它让相邻的块之间有一部分重复的文本。这样做是为了防止一个完整的句子或概念被硬生生割裂在两个块中。当检索到其中一个块时重叠部分提供了必要的上下文。通常设置为chunkSize的10%-20%。我设置50字符大约是一到两句话的长度。separators分隔符定义了分割的优先级。它会先尝试用“\n\n”空行分割如果分出来的块还是太大就用“\n”换行依此类推。中文环境下把句号、问号等加入分隔符列表非常重要。3.3 第三步文本转向量——嵌入模型的选择与使用现在我们有了一堆文本块需要把它们变成向量。我选择在本地运行一个轻量级但效果不错的嵌入模型all-MiniLM-L6-v2。它由sentence-transformers提供体积小速度快在多语言语义相似度任务上表现良好。首先安装依赖npm install xenova/transformersxenova/transformers是一个在浏览器和Node.js中运行Transformer模型的纯JavaScript库无需Python环境。const { pipeline } require(‘xenova/transformers’); class LocalEmbedder { constructor() { this.model null; this.tokenizer null; } async init() { // 加载嵌入模型和分词器 const { pipeline } await import(‘xenova/transformers’); this.embedder await pipeline(‘feature-extraction‘, ‘Xenova/all-MiniLM-L6-v2‘); } async embed(text) { if (!this.embedder) { await this.init(); } // 执行嵌入输出是一个Tensor我们需要提取数据并转换为普通数组 const output await this.embedder(text, { pooling: ‘mean‘, normalize: true }); // output.data 是一个Float32Array将其转为普通数组 return Array.from(output.data); } async embedBatch(texts) { // 批量嵌入效率更高 if (!this.embedder) { await this.init(); } const embeddings []; for (const text of texts) { const emb await this.embed(text); embeddings.push(emb); } return embeddings; } } // 使用示例 (async () { const embedder new LocalEmbedder(); await embedder.init(); const sampleText ‘RAG是检索增强生成的缩写。‘; const vector await embedder.embed(sampleText); console.log(‘向量维度:‘, vector.length); // all-MiniLM-L6-v2 输出384维向量 console.log(‘向量前5个值:‘, vector.slice(0, 5)); })();注意事项首次运行init()时会从Hugging Face下载模型文件约90MB需要一定时间。下载后模型会缓存到本地。all-MiniLM-L6-v2生成的向量是384维。对于生产环境如果追求更高精度可以考虑all-mpnet-base-v2768维但计算量和存储开销也会更大。你需要权衡效果与资源。3.4 第四步构建本地向量库——以Chroma为例向量准备好了需要一个地方存起来并能快速查找。Chroma是一个开源的嵌入式向量数据库设计目标就是简单易用尤其适合AI应用和原型开发。npm install chromadbconst { ChromaClient } require(‘chromadb’); async function createAndPopulateVectorStore(chunks, embeddings, metadatas) { // 1. 创建Chroma客户端持久化到磁盘 const client new ChromaClient({ path: ‘./chroma_db‘ // 指定本地存储路径 }); // 2. 创建或获取一个集合Collection相当于一张表 const collectionName ‘juejin_articles‘; let collection; try { collection await client.getCollection({ name: collectionName }); console.log(‘已存在集合清空旧数据...‘); await collection.delete(); // 清空旧数据根据需求决定是否保留 collection await client.createCollection({ name: collectionName }); } catch (error) { // 如果集合不存在则创建 collection await client.createCollection({ name: collectionName }); } // 3. 准备数据 // IDs: 为每个块生成唯一ID const ids chunks.map((_, index) chunk_${index}_${Date.now()}); // Metadatas: 每个块的元数据如来源文章标题、原始URL等 // 假设metadatas是传入的元数据数组 const documents chunks; // 原始文本 // 4. 向集合中添加数据 await collection.add({ ids: ids, embeddings: embeddings, // 二维数组每个元素是一个块的向量 metadatas: metadatas, documents: documents, }); console.log(成功将 ${chunks.length} 个文本块存入向量库集合 ${collectionName}); return collection; } // 整合前几步完成入库流程 (async () { // 假设我们已经有了 article 和 textChunks const article await fetchJuejinArticle(‘some_url‘); const textChunks await splitText(article.content); // 生成嵌入向量 const embedder new LocalEmbedder(); await embedder.init(); const embeddings await embedder.embedBatch(textChunks); // 准备元数据 const metadatas textChunks.map((chunk, index) ({ source: article.title, url: article.source, chunk_index: index, chunk_size: chunk.length })); // 存入Chroma const collection await createAndPopulateVectorStore(textChunks, embeddings, metadatas); })();至此我们已经完成了从网页抓取、清洗、分割、向量化到存储的完整流水线。你的本地./chroma_db文件夹下就是构建好的向量知识库。4. 效果验证与检索测试库建好了怎么知道它有没有用我们需要模拟一个检索问题来测试。async function searchSimilarChunks(question, collection, embedder, topK 3) { // 1. 将问题转换为向量 const questionVector await embedder.embed(question); // 2. 在集合中查询最相似的前topK个块 const results await collection.query({ queryEmbeddings: [questionVector], nResults: topK, // 可以选择同时返回文档、元数据和距离 include: [‘documents‘, ‘metadatas‘, ‘distances‘] }); // 3. 格式化结果 if (results results.documents results.documents[0]) { const topChunks results.documents[0]; const topMetadatas results.metadatas[0]; const topDistances results.distances[0]; console.log(\n问题: ${question}); console.log(返回最相似的 ${topK} 个片段:\n); for (let i 0; i topChunks.length; i) { console.log(--- 结果 ${i 1} (距离: ${topDistances[i].toFixed(4)}) ---); console.log(来源: ${topMetadatas[i].source}); console.log(内容预览: ${topChunks[i].substring(0, 150)}...\n); } return { topChunks, topMetadatas, topDistances }; } else { console.log(‘未找到相关结果‘); return null; } } // 测试检索 (async () { const client new ChromaClient({ path: ‘./chroma_db‘ }); const collection await client.getCollection({ name: ‘juejin_articles‘ }); const embedder new LocalEmbedder(); await embedder.init(); // 问一个文章里可能涉及的问题 await searchSimilarChunks(‘RAG中的检索步骤是怎么做的‘, collection, embedder); await searchSimilarChunks(‘文本分割时重叠部分有什么用‘, collection, embedder); })();如果一切顺利你会看到系统返回了与问题语义最相关的文章片段并按相似度排序。这个“距离”值通常是余弦相似度或欧氏距离Chroma默认使用余弦相似度值越接近1越相似直观地展示了匹配程度。5. 常见问题、优化策略与避坑指南在实际操作中你肯定会遇到各种问题。下面是我踩过坑后总结的一些经验和进阶优化思路。5.1 分割效果不理想怎么办症状检索到的块要么太碎回答不完整要么太大包含太多无关信息。排查与解决调整分割参数这是首要手段。重新审视chunkSize和chunkOverlap。对于结构严谨的技术文档可以尝试按标题分割。langchain提供了MarkdownHeaderTextSplitter如果你的原始内容能转换成Markdown并带有标题它能根据标题层级进行智能分割效果更好。尝试不同的分割器除了递归分割还有按字符、按token更准确但需调用模型API、按句子分割。对于中文可以结合jieba或pkuseg等分词库进行更细粒度的句子检测后再分割。后处理合并小片段分割后检查是否有长度极短如少于50字符的块这些可能是孤立的标题、列表项或标点。可以将它们与前后块合并。语义分割高级使用嵌入模型本身或一个小型语言模型来计算句子间的语义连贯性在语义边界处进行分割。这更智能但计算成本高。5.2 检索精度不够高怎么办症状返回的块似乎相关但又不是最切中要害的那个。排查与解决优化嵌入模型all-MiniLM-L6-v2是通用模型。如果你的领域非常专业如医学、法律可以考虑在该领域语料上微调过的嵌入模型或者使用效果更好的开源模型如bge-large-zh中文效果优异。丰富查询Query Expansion单一问题可能表述简单。可以用大语言模型即使是小模型对原问题进行改写、生成同义词或相关问题用这组问题去检索然后合并结果。引入元数据过滤在存入向量时除了文本和向量还可以存入丰富的元数据如“章节标题”、“段落类型正文/代码/图表说明”、“关键词”等。检索时可以先根据问题类型用元数据过滤一波例如问代码相关的问题优先检索类型为“代码”的块再进行向量相似度搜索。Chroma支持基于元数据的过滤。重排序Re-ranking向量检索是“召回”阶段追求全。召回top K比如10个个相关块后可以使用一个更精细的、专门做文本匹配的交叉编码器模型Cross-Encoder对这K个块与问题进行重新打分和排序选出最相关的top M比如3个个用于生成。这是提升最终答案精度的有效手段。5.3 本地嵌入模型速度慢或内存不足症状处理大量文档时嵌入步骤耗时过长或程序内存占用激增。排查与解决批量处理确保使用embedBatch而不是循环调用embed。批处理能极大利用计算资源。选择更轻量模型all-MiniLM-L6-v2已经是权衡后的选择。如果还不行可以考虑paraphrase-albert-small-v2等更小的模型但需接受精度损失。量化与加速使用支持ONNX Runtime或TensorRT的模型版本并进行量化如INT8可以显著提升推理速度并降低内存。异步与队列对于海量文档设计一个生产-消费队列将嵌入任务异步化避免阻塞主流程。考虑云API如果文档量巨大且对延迟敏感评估使用OpenAI或Cohere的嵌入API可能是更经济考虑总拥有成本的选择。5.4 如何评估整个RAG系统的效果构建完流水线只是开始评估是关键。不能只看检索出来的块“像不像”要看最终生成的答案好不好。人工评估黄金标准准备一组“问题-标准答案”对让系统回答人工评判答案的准确性、相关性和完整性。自动化指标检索阶段计算“命中率”检索到的相关块数量 / 总相关块数量和“平均精度”。生成阶段使用基于LLM的评估器如让GPT-4对比系统答案和标准答案从事实一致性、信息相关性等维度打分。端到端评估使用RAGAS等专门框架它可以从“忠实度”、“答案相关性”、“上下文相关性”等多个维度进行量化评估。5.5 一个容易被忽略的坑字符编码与文本清洗网页文本中常常包含各种不可见字符、HTML实体如nbsp;、lt;、Emoji、特殊空格等。如果清洗不干净这些“噪音”会被一起向量化可能干扰语义。解决方案在清洗函数中增加更强的规范化步骤。function deepCleanText(text) { // 1. 替换HTML实体 text text.replace(/nbsp;/g, ‘ ‘).replace(/lt;/g, ‘‘).replace(/gt;/g, ‘‘).replace(/amp;/g, ‘‘); // 2. 移除或替换控制字符和不可见字符 text text.replace(/[\x00-\x09\x0B\x0C\x0E-\x1F\x7F]/g, ‘‘); // 3. 标准化空白字符将各种空格、制表符、换行符统一 text text.replace(/\s/g, ‘ ‘).trim(); // 4. (可选) 移除或规范化Emoji取决于你的需求 // text text.replace(/\p{Emoji}/gu, ‘‘); // 使用Unicode属性转义 return text; }走完这一整套流程你不仅拥有了一个可以运行的、让AI“读”网页的管道更关键的是理解了每个环节背后的“为什么”。从轻量级爬取工具的选择到文本分割这个微妙而重要的艺术再到本地化嵌入与向量存储的实践最后到效果验证和持续优化的思路这其中的每一步都充满了工程上的权衡与技巧。