1. 项目概述为什么RAG知识库搭建是个精细活儿最近和几个做AI应用的朋友聊天发现大家一提到RAG检索增强生成眼睛都放光觉得这是让大模型“说真话”、解决幻觉问题的银弹。但真上手去搭一个从爬数据开始到最终能稳定、准确地回答用户问题中间踩的坑能写满一本错题集。这个项目标题“从零搭建 RAG 知识库爬虫→分词→向量化→检索一步都不能错”可以说精准地戳中了所有实践者的痛点。它不是一个简单的流程串联而是一个环环相扣、每一步都充满技术选型和细节打磨的系统工程。我自己在搭建企业内部知识库、行业资讯分析系统时反复验证过这个流程。RAG的核心价值在于为LLM提供一个精准、可靠的外部知识“记忆体”。但这个记忆体的质量直接决定了最终回答的靠谱程度。你可以把整个过程想象成给一位博闻强识但记忆模糊的学者LLM建造一个私人图书馆。爬虫是采购员负责从各处搜集书籍数据分词和向量化是图书管理员负责给书籍编目、贴标签、做摘要把非结构化的文本变成机器能理解的索引卡片检索则是学者的助手当学者被问到问题时助手能快速从海量索引卡片中找到最相关的那几本递给学者参考。这个链条里任何一环的粗糙处理都会导致“垃圾进垃圾出”。爬虫抓得不全或格式混乱后续处理就无从谈起分词分得不好语义被割裂向量化就成了“歪曲事实”向量模型选得不对或者索引建得不好检索召回的就是一堆不相关的文档最后即使召回了如果排序策略不行最关键的答案也可能被埋没在噪音里。所以标题强调“一步都不能错”绝非危言耸听而是血泪教训的总结。接下来我就结合实战把这四步拆开揉碎了讲清楚尤其是那些容易踩坑、文档里不会写的细节。2. 第一步爬虫——数据源的“清洁度”决定天花板很多人觉得爬虫就是requests加BeautifulSoup把HTML拖下来就完事了。但在RAG的语境下爬虫的目标不是“抓到数据”而是“抓到干净、结构化的高质量文本数据”。你的下游所有工序都在为这一步的成果买单。2.1 爬虫策略与工具选型不只是Python提到爬虫第一反应是Python的Scrapy或requestsparsel组合。这没错但对于RAG项目我们需要更全面地考虑静态页面对于新闻网站、博客、文档站如许多开源项目的Docsrequests/httpx配合BeautifulSoup或parsel速度更快是经典选择。重点在于编写健壮的CSS选择器或XPath并处理好编码问题。import httpx from parsel import Selector async def fetch_page(url): async with httpx.AsyncClient(timeout10.0, follow_redirectsTrue) as client: try: resp await client.get(url, headers{User-Agent: Mozilla/5.0 ...}) resp.raise_for_status() return resp.text except Exception as e: print(fFailed to fetch {url}: {e}) return None def parse_content(html): selector Selector(texthtml) # 核心精准定位正文剔除导航、广告、评论、页脚 main_content selector.css(article .post-content ::text).getall() # 示例选择器 # 更通用的策略通过标签密度、聚类算法识别正文区域 text .join([txt.strip() for txt in main_content if txt.strip()]) return text注意不要依赖单一的标签选择器。不同网站结构千差万别。一个实战技巧是使用readability库或trafilatura这类专门用于正文提取的工具它们通过算法识别网页核心内容区域成功率远高于手写规则。动态渲染页面越来越多的网站如单页应用SPA内容由JavaScript动态加载。这时requests只能拿到空壳。解决方案是Selenium/Playwright模拟浏览器行为功能强大但重量级适合复杂交互如登录、点击。资源消耗大不适合大规模爬取。Pyppeteer/Puppeteer (Node.js)无头Chrome控制库比Selenium更轻量高效。逆向工程API最高效的方法。打开浏览器开发者工具F12切换到Network网络标签刷新页面观察XHR/Fetch请求。直接找到数据接口用requests模拟调用。这需要一些耐心但一旦成功速度和稳定性极佳。特定平台爬虫如微信公众号、小红书、抖音等。这些平台反爬严格通常需要模拟登录获取Cookie或Token。调用官方或非官方API有些平台有未公开的移动端API通过抓包分析获得。使用现成的SDK或工具例如wechatpy微信、inscrapperInstagram等但要注意合规性和稳定性。重要提示爬取此类数据务必严格遵守robots.txt协议和平台用户协议评估法律风险仅用于个人学习研究且控制请求频率避免对目标服务器造成压力。2.2 数据清洗与标准化容易被忽视的“脏活”爬下来的原始文本通常包含大量噪音直接丢给分词模型会严重影响后续效果。去除无关元素HTML/JS/CSS标签用BeautifulSoup.get_text()或正则表达式彻底清除。广告、推荐阅读、版权声明通过常见的文本模式如“猜你喜欢”、“相关阅读”、“Copyright”进行过滤。导航栏、页眉页脚在解析阶段就应剔除。特殊字符和乱码使用unicodedata.normalize()进行Unicode规范化并用正则过滤非目标语言的字符集。文本规范化统一编码确保全部文本为UTF-8。全角转半角中文环境下将全角字母、数字、符号转换为半角保证一致性。日期、数字格式标准化将“2023年12月1日”、“2023-12-01”、“12/1/2023”统一为一种格式便于后续可能的信息抽取。去除多余空白将连续的换行符、空格、制表符压缩为单个空格或标准段落分隔。质量过滤长度过滤剔除过短如少于20字符的文本块这可能是导航碎片或广告。语言检测如果你的知识库只针对中文使用langdetect库过滤掉非中文内容。去重对高度相似或完全相同的文本进行去重避免在向量库中引入冗余。可以使用SimHash或MinHash算法进行近似去重。实操心得建立一个可配置的清洗管道Pipeline至关重要。我为每个数据源定义了一套清洗规则并保存清洗前的原始文本和清洗后的版本方便回溯和调试。清洗效果直接影响分词和嵌入的质量这里多花一天时间后面能省下一周的调试功夫。3. 第二步文本分词与切片——如何让机器“读懂”段落清洗后的文本是连续的字符串我们需要将其切割成适合向量化和检索的片段Chunks。这一步直接决定了检索的粒度。3.1 分词Word Segmentation与分句对于中文RAG分词是基础。但这里的“分词”更多指的是为后续的语义切片做准备而不是简单的词语切分。工具选择Jieba最常用的中文分词库速度快自定义词典功能强大。适合作为基础分词器。HanLP功能更全面除了基础分词还提供词性标注、命名实体识别NER、依存句法分析等。在Spring Boot等Java生态中集成良好如hanlp-spring-boot-starter。如果你的知识库涉及大量实体人名、地名、机构名、专业术语HanLP的NER能帮你更好地识别和保留关键信息。PKUSeg、LTP北大和哈工大的工具在学术文本上分词准确率较高。大模型分词使用ChatGLM、Qwen等模型的tokenizer进行分词可以保证与后续使用的LLM在词汇表上对齐但速度较慢适合对齐要求高的场景。# 使用Jieba进行基础分词和关键词提取 import jieba import jieba.analyse text 这是一段关于人工智能技术的示例文本。 # 精确模式分词 words jieba.lcut(text, cut_allFalse) # 提取TF-IDF关键词 keywords jieba.analyse.extract_tags(text, topK5, withWeightFalse) # 使用TextRank算法提取关键词 keywords_tr jieba.analyse.textrank(text, topK5, withWeightFalse)分句Sentence Splitting将文本按句号、问号、感叹号等分割成独立的句子。这是更细粒度的切片基础。可以使用简单的正则也可以使用更智能的库如pysbd适用于多种语言。3.2 知识切片Chunking策略核心中的核心这是RAG项目成败的关键技术点之一。切片太大会引入无关噪声降低检索精度切片太小会丢失上下文导致语义不完整。固定长度重叠切片最常用、最稳定的方法。使用字符数或token数作为窗口大小并设置一个重叠区域overlap以保持上下文连贯。from langchain.text_splitter import RecursiveCharacterTextSplitter # LangChain提供的递归字符文本分割器效果很好 text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 目标块大小字符数 chunk_overlap50, # 块之间的重叠字符数 length_functionlen, separators[\n\n, \n, 。, , , , ] # 按此优先级尝试分割 ) chunks text_splitter.split_text(long_text)chunk_size选择一般建议在256-1024个字符或tokens之间。需要权衡较小的size如256检索更精准但可能信息不全较大的size如1024信息完整但可能包含无关内容。一个经验是让你的块大小大致等于你期望LLM在生成答案时参考的上下文长度。chunk_overlap选择通常为chunk_size的10%-20%。重叠是为了防止一个完整的句子或概念被生硬地切到两个块中导致检索时只召回一半。基于语义的切片更高级的方法试图在语义边界如段落、章节处进行切割。可以使用自然断点优先在\n\n空行、标题标记#、##、p标签等处切割。语义分割模型使用预训练模型判断哪里是自然的语义边界。这更智能但计算成本高且模型本身可能引入误差。混合切片Hybrid Chunking对于结构清晰的文档如PDF、Markdown采用分层切片。先按章节/标题切大块再在大块内按固定长度切小块。为每个块保留其层级信息如{“chapter”: “3”, “section”: “3.1”, “content”: “...”}检索时可以利用层级进行过滤或加权。注意事项不要破坏表格和代码对于技术文档表格和代码块应被视为一个整体不应被切开。需要在分割前进行预处理将这些部分标记并保护起来。保留元数据为每个切片chunk附加来源信息如URL、文件名、标题、时间戳、作者等。这些元数据在后续检索和结果展示中非常有用。测试你的切片随机抽样一些切片人工阅读检查其语义是否完整重叠是否合理。这是调试切片策略最直接有效的方法。4. 第三步向量化嵌入——将文本映射到语义空间向量化也叫嵌入Embedding是把文本切片转换成高维空间中的向量一组数字。语义相似的文本其向量在空间中的距离如余弦相似度也相近。这是实现语义检索的数学基础。4.1 嵌入模型选型开源与闭源的权衡开源模型本地部署BGEBAAI General Embedding系列智源研究院出品如BGE-large-zh、BGE-small-zh在中文语义相似度任务上表现SOTA最先进且针对检索任务进行了优化。这是目前中文RAG项目的首选。Sentence-BERTSBERT有中文变体paraphrase-multilingual-MiniLM-L12-v2在多语言场景下表现稳健。M3E系列专门为中文优化的嵌入模型在部分中文评测集上表现不错。开源模型优势数据隐私安全、可离线运行、定制化微调、无调用费用。劣势需要本地GPU或CPU资源推理速度取决于硬件模型管理需要自行负责。闭源API在线服务OpenAItext-embedding-3系列性能强大且稳定使用简单。百度文心、阿里通义、智谱ChatGLM等国内厂商的嵌入API符合数据合规要求。API优势免运维性能稳定随模型升级自动更新。劣势有调用成本和数据出境风险对于国外API存在网络延迟和速率限制。选型建议对于企业内部或对数据安全要求高的项目优先选择BGE这类优秀的开源模型在本地部署。对于快速原型验证或中小规模应用可以考虑国内大厂的嵌入API。一个折中方案是用开源模型处理核心敏感数据用API处理非敏感或公开数据。4.2 嵌入实践与优化批量处理与性能调用嵌入模型是耗时的。务必使用批量推理batch inference来提升效率。from sentence_transformers import SentenceTransformer import numpy as np model SentenceTransformer(BAAI/bge-large-zh-v1.5) # 准备文本列表 texts [段落1, 段落2, ...] # 批量编码指定batch_size embeddings model.encode(texts, batch_size32, normalize_embeddingsTrue, show_progress_barTrue) # embeddings 是一个 numpy 数组 shape 为 (文本数, 向量维度)normalize_embeddingsTrue将向量归一化为单位向量。强烈建议开启这样后续计算余弦相似度就简化为点积np.dot(a,b)计算更快且余弦相似度范围在[-1,1]或[0,1]归一化后。向量维度不同模型的输出维度不同如BGE-large是1024维OpenAI text-embedding-3-small是1536维。这会影响向量数据库的存储和检索效率但通常更高维度的模型表征能力更强。选择时需权衡效果和成本。指令微调模型的使用像BGE这类为检索优化的模型通常经过了指令微调。这意味着在编码查询query时需要添加指令前缀而在编码被检索的文档passage时则不需要或使用不同的前缀以达到最佳效果。# 对于BGE模型 query 什么是机器学习 passages [机器学习是人工智能的一个分支..., 深度学习是机器学习的一种...] # 编码查询时添加指令 query_embedding model.encode([f为这个句子生成表示以用于检索相关文章{query}], normalize_embeddingsTrue) # 编码文档时不需要或使用其他指令具体看模型说明 passage_embeddings model.encode(passages, normalize_embeddingsTrue)务必查阅所用模型的官方文档或Hugging Face页面了解其推荐的编码方式这是发挥模型性能的关键。5. 第四步检索与排序——从海量向量中精准定位有了高质量的向量下一步就是建立索引并实现快速准确的检索。检索系统通常分为“召回”Recall和“排序”Rerank两步。5.1 向量数据库选型与索引构建向量数据库负责高效存储向量并提供近似最近邻ANN搜索。选型考虑因素性能、易用性、社区生态、云服务支持。数据库特点适用场景Milvus功能全面性能强劲生态丰富支持标量过滤、动态Schema。大规模、高并发生产环境需要复杂过滤和混合搜索。Chroma轻量级API简单与LangChain集成极佳入门快。原型开发、小规模项目、快速验证想法。QdrantRust编写性能好支持丰富的数据类型和过滤条件有云服务。对性能和过滤有较高要求的生产环境。PGVectorPostgreSQL的扩展利用现有PG生态支持ACID。已在使用PostgreSQL希望简化技术栈。Weaviate集成了向量、图、关键词搜索自带模块化设计。需要结合多种搜索方式或图关系的复杂应用。以Milvus为例的索引构建流程连接与集合Collection创建定义集合的Schema包括向量字段和元数据字段如id、text、source等。选择索引类型常用的有IVF_FLAT平衡精度与速度、HNSW高召回率高速度内存占用大、SCANN磁盘索引内存占用小。对于中等规模数据百万级IVF_FLAT是不错的选择。插入数据将文本切片、其对应的向量和元数据批量插入集合。加载集合在搜索前需要将集合加载到内存。from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType # 1. 连接 connections.connect(hostlocalhost, port19530) # 2. 定义Schema fields [ FieldSchema(nameid, dtypeDataType.INT64, is_primaryTrue, auto_idTrue), FieldSchema(nametext, dtypeDataType.VARCHAR, max_length65535), FieldSchema(nameembedding, dtypeDataType.FLOAT_VECTOR, dim1024), # 维度与模型匹配 FieldSchema(namesource, dtypeDataType.VARCHAR, max_length255), ] schema CollectionSchema(fields, description知识库文档集合) # 3. 创建集合 collection_name rag_knowledge_base collection Collection(namecollection_name, schemaschema) # 4. 创建索引 index_params { index_type: IVF_FLAT, metric_type: IP, # 内积因为我们的向量是归一化的内积余弦相似度 params: {nlist: 1024} # 聚类中心数值越大搜索越准越慢通常取 sqrt(数据量) } collection.create_index(field_nameembedding, index_paramsindex_params) # 5. 插入数据假设chunks是文本列表embeddings是向量列表metas是元数据列表 data [ chunks, # 文本 embeddings.tolist(), # 向量转为list [meta[source] for meta in metas] # 元数据例如来源 ] collection.insert(data) collection.load() # 加载到内存5.2 多路召回与混合检索单一的向量检索语义检索有时会漏掉一些关键词匹配但语义稍远的文档。因此工业级RAG系统常采用“多路召回”策略。向量检索语义召回如上所述利用余弦相似度查找语义最接近的片段。关键词检索稀疏召回使用BM25、TF-IDF等算法。它更注重关键词的精确匹配能有效召回那些包含查询关键词但语义嵌入可能不近的文档例如包含特定产品型号、错误代码、人名。BM25是TF-IDF的改进版考虑了文档长度归一化效果更好。可以使用rank_bm25库实现。from rank_bm25 import BM25Okapi import jieba # 准备语料库分好词的文档列表 tokenized_corpus [list(jieba.cut(doc)) for doc in chunks] bm25 BM25Okapi(tokenized_corpus) # 对查询进行分词和检索 query 如何解决网络连接超时 tokenized_query list(jieba.cut(query)) doc_scores bm25.get_scores(tokenized_query) top_keyword_indices np.argsort(doc_scores)[::-1][:10] # 取BM25分数最高的10个混合检索Hybrid Search将向量检索和关键词检索的结果融合。最简单的方法是加权求和Reciprocal Rank Fusion, RRF 是更鲁棒的方法。def hybrid_search(query, vector_collection, bm25_index, tokenized_corpus, top_k10, alpha0.5): # 1. 向量检索 query_embedding model.encode([f为这个句子生成表示以用于检索相关文章{query}]) vector_results vector_collection.search(query_embedding, anns_fieldembedding, param{nprobe: 10}, limittop_k) vector_ids [hit.id for hit in vector_results[0]] vector_scores [hit.score for hit in vector_results[0]] # 2. 关键词检索 tokenized_query list(jieba.cut(query)) bm25_scores bm25_index.get_scores(tokenized_query) top_bm25_indices np.argsort(bm25_scores)[::-1][:top_k] # 3. 融合简单加权实际可用RRF fused_scores {} # 为向量检索结果赋分 for vid, vscore in zip(vector_ids, vector_scores): fused_scores[vid] alpha * vscore # 为BM25检索结果赋分需归一化到与向量分数相近的范围 max_bm25 max(bm25_scores) if max(bm25_scores) 0 else 1 for idx in top_bm25_indices: normalized_score bm25_scores[idx] / max_bm25 fused_scores[idx] fused_scores.get(idx, 0) (1 - alpha) * normalized_score # 4. 按融合分数排序 sorted_items sorted(fused_scores.items(), keylambda x: x[1], reverseTrue) final_ids [item[0] for item in sorted_items[:top_k]] return final_idsalpha参数控制语义检索和关键词检索的权重通常需要在一个验证集上调试。5.3 重排序Reranking提升精度的最后一道关卡召回Recall阶段我们可能找回了100个相关文档但其中真正有用的可能只有前5个。重排序的目标是利用一个更精细的模型通常是交叉编码器Cross-Encoder对召回的Top N个结果进行两两比较或与查询进行精细匹配重新打分排序将最相关的结果推到最前面。为什么需要重排序用于召回的向量模型双编码器Bi-Encoder为了效率将查询和文档独立编码损失了一些交互信息。而交叉编码器将查询和文档同时输入模型进行深度的注意力交互判断相关性更准确但速度慢只适合对少量候选进行精排。重排序模型BGE-Reranker智源推出的中文重排序模型与BGE嵌入模型是绝配。Sentence-BERT Cross-Encoder也有多语言版本。from FlagEmbedding import FlagReranker reranker FlagReranker(BAAI/bge-reranker-large, use_fp16True) # 使用FP16加速 query 如何配置Python虚拟环境 retrieved_docs [文档A的文本..., 文档B的文本..., ...] # 从召回阶段获得 # 准备 (query, document) 对 pairs [(query, doc) for doc in retrieved_docs] # 计算相关性分数 scores reranker.compute_score(pairs) # 返回一个分数列表 # 根据分数对retrieved_docs重新排序 reranked_indices np.argsort(scores)[::-1] final_docs [retrieved_docs[i] for i in reranked_indices]重排序的位置在混合召回得到Top K例如K50个候选文档后使用重排序模型对这50个文档进行精排选出最终的Top M例如M5个文档送入LLM生成答案。6. 全链路集成与效果调优将以上四个模块串联起来就形成了一个完整的RAG流水线。但搭建完成只是开始持续的调优才是让系统变得好用的关键。6.1 流水线搭建与框架选择你可以完全从零手写这个流水线但对于快速开发和维护使用框架是更明智的选择。LangChain/LlamaIndex这两个是当前最流行的RAG应用框架。LangChain更像一个“胶水”框架提供了丰富的组件Document Loaders, Text Splitters, Vector Stores, Retrievers, Chains灵活性极高你可以自由组合。学习曲线稍陡但能深度定制。LlamaIndex更专注于RAG和数据索引提供了更高级的检索抽象如索引、查询引擎开箱即用的体验更好对复杂查询带过滤、汇总支持更友好。选择建议如果你需要高度定制化或者你的应用逻辑非常复杂LangChain可能更适合。如果你希望快速构建一个标准且高效的RAG系统LlamaIndex可能更省心。核心流程代码示意以LangChain为例from langchain_community.document_loaders import WebBaseLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_huggingface import HuggingFaceEmbeddings from langchain_community.vectorstores import Milvus from langchain.chains import RetrievalQA from langchain_community.llms import ChatGLM # 示例可用其他LLM # 1. 加载文档 loader WebBaseLoader(https://example.com/doc) documents loader.load() # 2. 分割文本 text_splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) docs text_splitter.split_documents(documents) # 3. 嵌入并存入向量库 embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-large-zh-v1.5) vector_store Milvus.from_documents( docs, embeddings, connection_args{host: localhost, port: 19530}, collection_namemy_rag_collection ) retriever vector_store.as_retriever(search_kwargs{k: 5}) # 创建检索器 # 4. 构建QA链 llm ChatGLM(endpoint_urlhttp://localhost:8000, max_tokens2048) qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, # 还有其他如map_reduce, refine等 retrieverretriever, return_source_documentsTrue ) # 5. 提问 result qa_chain.invoke({query: 什么是RAG}) print(result[result]) print(来源, [doc.metadata.get(source) for doc in result[source_documents]])6.2 效果评估与迭代调优一个RAG系统的好坏不能凭感觉需要量化评估。评估指标检索阶段命中率Hit Rate在Top K个检索结果中至少包含一个正确答案文档的比例。平均倒数排名MRR正确答案在检索结果中排名的倒数的平均值。衡量系统把正确答案排在前面的能力。生成阶段忠实度Faithfulness生成的答案是否严格基于检索到的文档有没有“胡编乱造”幻觉。可以用LLM本身或专门模型来评判。答案相关性Answer Relevance生成的答案是否直接回答了问题。人工评估最终的金标准。设计一批测试问题让人来评判答案的准确性、有用性和流畅性。迭代调优的闭环收集bad cases记录系统回答错误或不好的问题。归因分析是检索没找到相关文档还是文档找到了但排序不对还是LLM在生成时误解了文档针对性优化检索问题调整切片策略chunk_size/overlap、尝试混合检索、调整重排序模型、优化查询对用户原始查询进行改写或扩展即Query Rewriting/Expansion。生成问题优化提示词Prompt明确要求LLM“严格根据给定上下文回答”并设计更好的上下文组织方式如将最相关的文档放在最前面。一个关键的提示词技巧在给LLM的Prompt中明确指令和上下文格式至关重要。你是一个专业的助手请严格根据以下提供的上下文信息来回答问题。如果上下文中的信息不足以回答问题请直接说“根据已知信息无法回答该问题”不要编造信息。 上下文 {context} 问题{question} 请根据上下文回答同时可以在{context}中按照相关性从高到低排列文档并在每个文档前加上[文档1]、[文档2]的标识有助于LLM更好地利用信息。7. 常见问题与避坑指南在实际搭建过程中你会遇到各种各样的问题。这里记录一些高频问题和解决思路。问题现象可能原因排查与解决思路检索结果完全不相关1. 嵌入模型不适合领域。2. 文本切片不合理破坏了语义。3. 查询未用指令格式化针对BGE等模型。4. 向量索引类型或参数设置不当。1. 用领域内句子对测试嵌入模型相似度。2. 人工检查切片调整chunk_size和overlap。3. 确认查询编码格式符合模型要求。4. 检查索引的metric_type应为IP或L2调整nprobe等搜索参数。LLM回答出现幻觉不依据上下文1. 检索到的上下文本身不相关或质量差。2. Prompt指令不够强硬LLM自由发挥。3. 上下文太长或格式混乱LLM无法有效处理。1. 先检查检索阶段返回的文档是否真的相关。2. 强化Prompt使用“严格根据”、“必须引用”等措辞并让LLM指出引用来源。3. 尝试map_reduce或refine等链式方式处理长上下文或对检索到的文档进行摘要后再输入。系统响应速度慢1. 嵌入模型推理慢未用GPU或批处理。2. 向量索引未加载到内存或ANN参数nprobe太大。3. LLM生成速度慢。4. 网络延迟使用远程API时。1. 使用GPU推理并增大encode的batch_size。2. 确认集合已load()适当调小nprobe以平衡速度与精度。3. 考虑使用更小的LLM或启用流式输出改善体验。4. 考虑缓存频繁查询的嵌入或结果。对于简单事实性问题效果好复杂推理问题差1. 检索粒度太细单个切片无法提供完整推理链条。2. 未实现多跳检索Multi-hop Retrieval。1. 尝试增大chunk_size或采用基于章节的切片策略。2. 实现迭代检索用LLM从第一轮答案中提炼出新的查询进行第二轮检索如此循环。如何处理文档更新全量重建向量库成本高。1.增量更新为新文档生成向量并插入为已删除文档标记为无效软删除。定期如每周合并增量重建索引以优化性能。2. 使用支持动态更新的向量数据库如Milvus、Qdrant。最后一点个人体会RAG系统是一个典型的“木桶效应”工程最终效果取决于最短的那块板。不要只盯着最炫的LLM或最复杂的检索算法往往花时间把最基础的数据清洗和文本切片做好整个系统的效果就能提升一个档次。从简单的流程开始构建一个可工作的最小版本MVP然后基于真实的用户问题和bad cases有针对性地、一步一步地去迭代优化每一个环节这才是搭建一个健壮RAG知识库的正道。 
长河君 · 2026/8/13 11:56:28 · 阅读 1.2k RAG知识库搭建全流程解析：从数据爬取到向量检索的工程实践
1. 项目概述为什么RAG知识库搭建是个精细活儿最近和几个做AI应用的朋友聊天发现大家一提到RAG检索增强生成眼睛都放光觉得这是让大模型“说真话”、解决幻觉问题的银弹。但真上手去搭一个从爬数据开始到最终能稳定、准确地回答用户问题中间踩的坑能写满一本错题集。这个项目标题“从零搭建 RAG 知识库爬虫→分词→向量化→检索一步都不能错”可以说精准地戳中了所有实践者的痛点。它不是一个简单的流程串联而是一个环环相扣、每一步都充满技术选型和细节打磨的系统工程。我自己在搭建企业内部知识库、行业资讯分析系统时反复验证过这个流程。RAG的核心价值在于为LLM提供一个精准、可靠的外部知识“记忆体”。但这个记忆体的质量直接决定了最终回答的靠谱程度。你可以把整个过程想象成给一位博闻强识但记忆模糊的学者LLM建造一个私人图书馆。爬虫是采购员负责从各处搜集书籍数据分词和向量化是图书管理员负责给书籍编目、贴标签、做摘要把非结构化的文本变成机器能理解的索引卡片检索则是学者的助手当学者被问到问题时助手能快速从海量索引卡片中找到最相关的那几本递给学者参考。这个链条里任何一环的粗糙处理都会导致“垃圾进垃圾出”。爬虫抓得不全或格式混乱后续处理就无从谈起分词分得不好语义被割裂向量化就成了“歪曲事实”向量模型选得不对或者索引建得不好检索召回的就是一堆不相关的文档最后即使召回了如果排序策略不行最关键的答案也可能被埋没在噪音里。所以标题强调“一步都不能错”绝非危言耸听而是血泪教训的总结。接下来我就结合实战把这四步拆开揉碎了讲清楚尤其是那些容易踩坑、文档里不会写的细节。2. 第一步爬虫——数据源的“清洁度”决定天花板很多人觉得爬虫就是requests加BeautifulSoup把HTML拖下来就完事了。但在RAG的语境下爬虫的目标不是“抓到数据”而是“抓到干净、结构化的高质量文本数据”。你的下游所有工序都在为这一步的成果买单。2.1 爬虫策略与工具选型不只是Python提到爬虫第一反应是Python的Scrapy或requestsparsel组合。这没错但对于RAG项目我们需要更全面地考虑静态页面对于新闻网站、博客、文档站如许多开源项目的Docsrequests/httpx配合BeautifulSoup或parsel速度更快是经典选择。重点在于编写健壮的CSS选择器或XPath并处理好编码问题。import httpx from parsel import Selector async def fetch_page(url): async with httpx.AsyncClient(timeout10.0, follow_redirectsTrue) as client: try: resp await client.get(url, headers{User-Agent: Mozilla/5.0 ...}) resp.raise_for_status() return resp.text except Exception as e: print(fFailed to fetch {url}: {e}) return None def parse_content(html): selector Selector(texthtml) # 核心精准定位正文剔除导航、广告、评论、页脚 main_content selector.css(article .post-content ::text).getall() # 示例选择器 # 更通用的策略通过标签密度、聚类算法识别正文区域 text .join([txt.strip() for txt in main_content if txt.strip()]) return text注意不要依赖单一的标签选择器。不同网站结构千差万别。一个实战技巧是使用readability库或trafilatura这类专门用于正文提取的工具它们通过算法识别网页核心内容区域成功率远高于手写规则。动态渲染页面越来越多的网站如单页应用SPA内容由JavaScript动态加载。这时requests只能拿到空壳。解决方案是Selenium/Playwright模拟浏览器行为功能强大但重量级适合复杂交互如登录、点击。资源消耗大不适合大规模爬取。Pyppeteer/Puppeteer (Node.js)无头Chrome控制库比Selenium更轻量高效。逆向工程API最高效的方法。打开浏览器开发者工具F12切换到Network网络标签刷新页面观察XHR/Fetch请求。直接找到数据接口用requests模拟调用。这需要一些耐心但一旦成功速度和稳定性极佳。特定平台爬虫如微信公众号、小红书、抖音等。这些平台反爬严格通常需要模拟登录获取Cookie或Token。调用官方或非官方API有些平台有未公开的移动端API通过抓包分析获得。使用现成的SDK或工具例如wechatpy微信、inscrapperInstagram等但要注意合规性和稳定性。重要提示爬取此类数据务必严格遵守robots.txt协议和平台用户协议评估法律风险仅用于个人学习研究且控制请求频率避免对目标服务器造成压力。2.2 数据清洗与标准化容易被忽视的“脏活”爬下来的原始文本通常包含大量噪音直接丢给分词模型会严重影响后续效果。去除无关元素HTML/JS/CSS标签用BeautifulSoup.get_text()或正则表达式彻底清除。广告、推荐阅读、版权声明通过常见的文本模式如“猜你喜欢”、“相关阅读”、“Copyright”进行过滤。导航栏、页眉页脚在解析阶段就应剔除。特殊字符和乱码使用unicodedata.normalize()进行Unicode规范化并用正则过滤非目标语言的字符集。文本规范化统一编码确保全部文本为UTF-8。全角转半角中文环境下将全角字母、数字、符号转换为半角保证一致性。日期、数字格式标准化将“2023年12月1日”、“2023-12-01”、“12/1/2023”统一为一种格式便于后续可能的信息抽取。去除多余空白将连续的换行符、空格、制表符压缩为单个空格或标准段落分隔。质量过滤长度过滤剔除过短如少于20字符的文本块这可能是导航碎片或广告。语言检测如果你的知识库只针对中文使用langdetect库过滤掉非中文内容。去重对高度相似或完全相同的文本进行去重避免在向量库中引入冗余。可以使用SimHash或MinHash算法进行近似去重。实操心得建立一个可配置的清洗管道Pipeline至关重要。我为每个数据源定义了一套清洗规则并保存清洗前的原始文本和清洗后的版本方便回溯和调试。清洗效果直接影响分词和嵌入的质量这里多花一天时间后面能省下一周的调试功夫。3. 第二步文本分词与切片——如何让机器“读懂”段落清洗后的文本是连续的字符串我们需要将其切割成适合向量化和检索的片段Chunks。这一步直接决定了检索的粒度。3.1 分词Word Segmentation与分句对于中文RAG分词是基础。但这里的“分词”更多指的是为后续的语义切片做准备而不是简单的词语切分。工具选择Jieba最常用的中文分词库速度快自定义词典功能强大。适合作为基础分词器。HanLP功能更全面除了基础分词还提供词性标注、命名实体识别NER、依存句法分析等。在Spring Boot等Java生态中集成良好如hanlp-spring-boot-starter。如果你的知识库涉及大量实体人名、地名、机构名、专业术语HanLP的NER能帮你更好地识别和保留关键信息。PKUSeg、LTP北大和哈工大的工具在学术文本上分词准确率较高。大模型分词使用ChatGLM、Qwen等模型的tokenizer进行分词可以保证与后续使用的LLM在词汇表上对齐但速度较慢适合对齐要求高的场景。# 使用Jieba进行基础分词和关键词提取 import jieba import jieba.analyse text 这是一段关于人工智能技术的示例文本。 # 精确模式分词 words jieba.lcut(text, cut_allFalse) # 提取TF-IDF关键词 keywords jieba.analyse.extract_tags(text, topK5, withWeightFalse) # 使用TextRank算法提取关键词 keywords_tr jieba.analyse.textrank(text, topK5, withWeightFalse)分句Sentence Splitting将文本按句号、问号、感叹号等分割成独立的句子。这是更细粒度的切片基础。可以使用简单的正则也可以使用更智能的库如pysbd适用于多种语言。3.2 知识切片Chunking策略核心中的核心这是RAG项目成败的关键技术点之一。切片太大会引入无关噪声降低检索精度切片太小会丢失上下文导致语义不完整。固定长度重叠切片最常用、最稳定的方法。使用字符数或token数作为窗口大小并设置一个重叠区域overlap以保持上下文连贯。from langchain.text_splitter import RecursiveCharacterTextSplitter # LangChain提供的递归字符文本分割器效果很好 text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 目标块大小字符数 chunk_overlap50, # 块之间的重叠字符数 length_functionlen, separators[\n\n, \n, 。, , , , ] # 按此优先级尝试分割 ) chunks text_splitter.split_text(long_text)chunk_size选择一般建议在256-1024个字符或tokens之间。需要权衡较小的size如256检索更精准但可能信息不全较大的size如1024信息完整但可能包含无关内容。一个经验是让你的块大小大致等于你期望LLM在生成答案时参考的上下文长度。chunk_overlap选择通常为chunk_size的10%-20%。重叠是为了防止一个完整的句子或概念被生硬地切到两个块中导致检索时只召回一半。基于语义的切片更高级的方法试图在语义边界如段落、章节处进行切割。可以使用自然断点优先在\n\n空行、标题标记#、##、p标签等处切割。语义分割模型使用预训练模型判断哪里是自然的语义边界。这更智能但计算成本高且模型本身可能引入误差。混合切片Hybrid Chunking对于结构清晰的文档如PDF、Markdown采用分层切片。先按章节/标题切大块再在大块内按固定长度切小块。为每个块保留其层级信息如{“chapter”: “3”, “section”: “3.1”, “content”: “...”}检索时可以利用层级进行过滤或加权。注意事项不要破坏表格和代码对于技术文档表格和代码块应被视为一个整体不应被切开。需要在分割前进行预处理将这些部分标记并保护起来。保留元数据为每个切片chunk附加来源信息如URL、文件名、标题、时间戳、作者等。这些元数据在后续检索和结果展示中非常有用。测试你的切片随机抽样一些切片人工阅读检查其语义是否完整重叠是否合理。这是调试切片策略最直接有效的方法。4. 第三步向量化嵌入——将文本映射到语义空间向量化也叫嵌入Embedding是把文本切片转换成高维空间中的向量一组数字。语义相似的文本其向量在空间中的距离如余弦相似度也相近。这是实现语义检索的数学基础。4.1 嵌入模型选型开源与闭源的权衡开源模型本地部署BGEBAAI General Embedding系列智源研究院出品如BGE-large-zh、BGE-small-zh在中文语义相似度任务上表现SOTA最先进且针对检索任务进行了优化。这是目前中文RAG项目的首选。Sentence-BERTSBERT有中文变体paraphrase-multilingual-MiniLM-L12-v2在多语言场景下表现稳健。M3E系列专门为中文优化的嵌入模型在部分中文评测集上表现不错。开源模型优势数据隐私安全、可离线运行、定制化微调、无调用费用。劣势需要本地GPU或CPU资源推理速度取决于硬件模型管理需要自行负责。闭源API在线服务OpenAItext-embedding-3系列性能强大且稳定使用简单。百度文心、阿里通义、智谱ChatGLM等国内厂商的嵌入API符合数据合规要求。API优势免运维性能稳定随模型升级自动更新。劣势有调用成本和数据出境风险对于国外API存在网络延迟和速率限制。选型建议对于企业内部或对数据安全要求高的项目优先选择BGE这类优秀的开源模型在本地部署。对于快速原型验证或中小规模应用可以考虑国内大厂的嵌入API。一个折中方案是用开源模型处理核心敏感数据用API处理非敏感或公开数据。4.2 嵌入实践与优化批量处理与性能调用嵌入模型是耗时的。务必使用批量推理batch inference来提升效率。from sentence_transformers import SentenceTransformer import numpy as np model SentenceTransformer(BAAI/bge-large-zh-v1.5) # 准备文本列表 texts [段落1, 段落2, ...] # 批量编码指定batch_size embeddings model.encode(texts, batch_size32, normalize_embeddingsTrue, show_progress_barTrue) # embeddings 是一个 numpy 数组 shape 为 (文本数, 向量维度)normalize_embeddingsTrue将向量归一化为单位向量。强烈建议开启这样后续计算余弦相似度就简化为点积np.dot(a,b)计算更快且余弦相似度范围在[-1,1]或[0,1]归一化后。向量维度不同模型的输出维度不同如BGE-large是1024维OpenAI text-embedding-3-small是1536维。这会影响向量数据库的存储和检索效率但通常更高维度的模型表征能力更强。选择时需权衡效果和成本。指令微调模型的使用像BGE这类为检索优化的模型通常经过了指令微调。这意味着在编码查询query时需要添加指令前缀而在编码被检索的文档passage时则不需要或使用不同的前缀以达到最佳效果。# 对于BGE模型 query 什么是机器学习 passages [机器学习是人工智能的一个分支..., 深度学习是机器学习的一种...] # 编码查询时添加指令 query_embedding model.encode([f为这个句子生成表示以用于检索相关文章{query}], normalize_embeddingsTrue) # 编码文档时不需要或使用其他指令具体看模型说明 passage_embeddings model.encode(passages, normalize_embeddingsTrue)务必查阅所用模型的官方文档或Hugging Face页面了解其推荐的编码方式这是发挥模型性能的关键。5. 第四步检索与排序——从海量向量中精准定位有了高质量的向量下一步就是建立索引并实现快速准确的检索。检索系统通常分为“召回”Recall和“排序”Rerank两步。5.1 向量数据库选型与索引构建向量数据库负责高效存储向量并提供近似最近邻ANN搜索。选型考虑因素性能、易用性、社区生态、云服务支持。数据库特点适用场景Milvus功能全面性能强劲生态丰富支持标量过滤、动态Schema。大规模、高并发生产环境需要复杂过滤和混合搜索。Chroma轻量级API简单与LangChain集成极佳入门快。原型开发、小规模项目、快速验证想法。QdrantRust编写性能好支持丰富的数据类型和过滤条件有云服务。对性能和过滤有较高要求的生产环境。PGVectorPostgreSQL的扩展利用现有PG生态支持ACID。已在使用PostgreSQL希望简化技术栈。Weaviate集成了向量、图、关键词搜索自带模块化设计。需要结合多种搜索方式或图关系的复杂应用。以Milvus为例的索引构建流程连接与集合Collection创建定义集合的Schema包括向量字段和元数据字段如id、text、source等。选择索引类型常用的有IVF_FLAT平衡精度与速度、HNSW高召回率高速度内存占用大、SCANN磁盘索引内存占用小。对于中等规模数据百万级IVF_FLAT是不错的选择。插入数据将文本切片、其对应的向量和元数据批量插入集合。加载集合在搜索前需要将集合加载到内存。from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType # 1. 连接 connections.connect(hostlocalhost, port19530) # 2. 定义Schema fields [ FieldSchema(nameid, dtypeDataType.INT64, is_primaryTrue, auto_idTrue), FieldSchema(nametext, dtypeDataType.VARCHAR, max_length65535), FieldSchema(nameembedding, dtypeDataType.FLOAT_VECTOR, dim1024), # 维度与模型匹配 FieldSchema(namesource, dtypeDataType.VARCHAR, max_length255), ] schema CollectionSchema(fields, description知识库文档集合) # 3. 创建集合 collection_name rag_knowledge_base collection Collection(namecollection_name, schemaschema) # 4. 创建索引 index_params { index_type: IVF_FLAT, metric_type: IP, # 内积因为我们的向量是归一化的内积余弦相似度 params: {nlist: 1024} # 聚类中心数值越大搜索越准越慢通常取 sqrt(数据量) } collection.create_index(field_nameembedding, index_paramsindex_params) # 5. 插入数据假设chunks是文本列表embeddings是向量列表metas是元数据列表 data [ chunks, # 文本 embeddings.tolist(), # 向量转为list [meta[source] for meta in metas] # 元数据例如来源 ] collection.insert(data) collection.load() # 加载到内存5.2 多路召回与混合检索单一的向量检索语义检索有时会漏掉一些关键词匹配但语义稍远的文档。因此工业级RAG系统常采用“多路召回”策略。向量检索语义召回如上所述利用余弦相似度查找语义最接近的片段。关键词检索稀疏召回使用BM25、TF-IDF等算法。它更注重关键词的精确匹配能有效召回那些包含查询关键词但语义嵌入可能不近的文档例如包含特定产品型号、错误代码、人名。BM25是TF-IDF的改进版考虑了文档长度归一化效果更好。可以使用rank_bm25库实现。from rank_bm25 import BM25Okapi import jieba # 准备语料库分好词的文档列表 tokenized_corpus [list(jieba.cut(doc)) for doc in chunks] bm25 BM25Okapi(tokenized_corpus) # 对查询进行分词和检索 query 如何解决网络连接超时 tokenized_query list(jieba.cut(query)) doc_scores bm25.get_scores(tokenized_query) top_keyword_indices np.argsort(doc_scores)[::-1][:10] # 取BM25分数最高的10个混合检索Hybrid Search将向量检索和关键词检索的结果融合。最简单的方法是加权求和Reciprocal Rank Fusion, RRF 是更鲁棒的方法。def hybrid_search(query, vector_collection, bm25_index, tokenized_corpus, top_k10, alpha0.5): # 1. 向量检索 query_embedding model.encode([f为这个句子生成表示以用于检索相关文章{query}]) vector_results vector_collection.search(query_embedding, anns_fieldembedding, param{nprobe: 10}, limittop_k) vector_ids [hit.id for hit in vector_results[0]] vector_scores [hit.score for hit in vector_results[0]] # 2. 关键词检索 tokenized_query list(jieba.cut(query)) bm25_scores bm25_index.get_scores(tokenized_query) top_bm25_indices np.argsort(bm25_scores)[::-1][:top_k] # 3. 融合简单加权实际可用RRF fused_scores {} # 为向量检索结果赋分 for vid, vscore in zip(vector_ids, vector_scores): fused_scores[vid] alpha * vscore # 为BM25检索结果赋分需归一化到与向量分数相近的范围 max_bm25 max(bm25_scores) if max(bm25_scores) 0 else 1 for idx in top_bm25_indices: normalized_score bm25_scores[idx] / max_bm25 fused_scores[idx] fused_scores.get(idx, 0) (1 - alpha) * normalized_score # 4. 按融合分数排序 sorted_items sorted(fused_scores.items(), keylambda x: x[1], reverseTrue) final_ids [item[0] for item in sorted_items[:top_k]] return final_idsalpha参数控制语义检索和关键词检索的权重通常需要在一个验证集上调试。5.3 重排序Reranking提升精度的最后一道关卡召回Recall阶段我们可能找回了100个相关文档但其中真正有用的可能只有前5个。重排序的目标是利用一个更精细的模型通常是交叉编码器Cross-Encoder对召回的Top N个结果进行两两比较或与查询进行精细匹配重新打分排序将最相关的结果推到最前面。为什么需要重排序用于召回的向量模型双编码器Bi-Encoder为了效率将查询和文档独立编码损失了一些交互信息。而交叉编码器将查询和文档同时输入模型进行深度的注意力交互判断相关性更准确但速度慢只适合对少量候选进行精排。重排序模型BGE-Reranker智源推出的中文重排序模型与BGE嵌入模型是绝配。Sentence-BERT Cross-Encoder也有多语言版本。from FlagEmbedding import FlagReranker reranker FlagReranker(BAAI/bge-reranker-large, use_fp16True) # 使用FP16加速 query 如何配置Python虚拟环境 retrieved_docs [文档A的文本..., 文档B的文本..., ...] # 从召回阶段获得 # 准备 (query, document) 对 pairs [(query, doc) for doc in retrieved_docs] # 计算相关性分数 scores reranker.compute_score(pairs) # 返回一个分数列表 # 根据分数对retrieved_docs重新排序 reranked_indices np.argsort(scores)[::-1] final_docs [retrieved_docs[i] for i in reranked_indices]重排序的位置在混合召回得到Top K例如K50个候选文档后使用重排序模型对这50个文档进行精排选出最终的Top M例如M5个文档送入LLM生成答案。6. 全链路集成与效果调优将以上四个模块串联起来就形成了一个完整的RAG流水线。但搭建完成只是开始持续的调优才是让系统变得好用的关键。6.1 流水线搭建与框架选择你可以完全从零手写这个流水线但对于快速开发和维护使用框架是更明智的选择。LangChain/LlamaIndex这两个是当前最流行的RAG应用框架。LangChain更像一个“胶水”框架提供了丰富的组件Document Loaders, Text Splitters, Vector Stores, Retrievers, Chains灵活性极高你可以自由组合。学习曲线稍陡但能深度定制。LlamaIndex更专注于RAG和数据索引提供了更高级的检索抽象如索引、查询引擎开箱即用的体验更好对复杂查询带过滤、汇总支持更友好。选择建议如果你需要高度定制化或者你的应用逻辑非常复杂LangChain可能更适合。如果你希望快速构建一个标准且高效的RAG系统LlamaIndex可能更省心。核心流程代码示意以LangChain为例from langchain_community.document_loaders import WebBaseLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_huggingface import HuggingFaceEmbeddings from langchain_community.vectorstores import Milvus from langchain.chains import RetrievalQA from langchain_community.llms import ChatGLM # 示例可用其他LLM # 1. 加载文档 loader WebBaseLoader(https://example.com/doc) documents loader.load() # 2. 分割文本 text_splitter RecursiveCharacterTextSplitter(chunk_size500, chunk_overlap50) docs text_splitter.split_documents(documents) # 3. 嵌入并存入向量库 embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-large-zh-v1.5) vector_store Milvus.from_documents( docs, embeddings, connection_args{host: localhost, port: 19530}, collection_namemy_rag_collection ) retriever vector_store.as_retriever(search_kwargs{k: 5}) # 创建检索器 # 4. 构建QA链 llm ChatGLM(endpoint_urlhttp://localhost:8000, max_tokens2048) qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, # 还有其他如map_reduce, refine等 retrieverretriever, return_source_documentsTrue ) # 5. 提问 result qa_chain.invoke({query: 什么是RAG}) print(result[result]) print(来源, [doc.metadata.get(source) for doc in result[source_documents]])6.2 效果评估与迭代调优一个RAG系统的好坏不能凭感觉需要量化评估。评估指标检索阶段命中率Hit Rate在Top K个检索结果中至少包含一个正确答案文档的比例。平均倒数排名MRR正确答案在检索结果中排名的倒数的平均值。衡量系统把正确答案排在前面的能力。生成阶段忠实度Faithfulness生成的答案是否严格基于检索到的文档有没有“胡编乱造”幻觉。可以用LLM本身或专门模型来评判。答案相关性Answer Relevance生成的答案是否直接回答了问题。人工评估最终的金标准。设计一批测试问题让人来评判答案的准确性、有用性和流畅性。迭代调优的闭环收集bad cases记录系统回答错误或不好的问题。归因分析是检索没找到相关文档还是文档找到了但排序不对还是LLM在生成时误解了文档针对性优化检索问题调整切片策略chunk_size/overlap、尝试混合检索、调整重排序模型、优化查询对用户原始查询进行改写或扩展即Query Rewriting/Expansion。生成问题优化提示词Prompt明确要求LLM“严格根据给定上下文回答”并设计更好的上下文组织方式如将最相关的文档放在最前面。一个关键的提示词技巧在给LLM的Prompt中明确指令和上下文格式至关重要。你是一个专业的助手请严格根据以下提供的上下文信息来回答问题。如果上下文中的信息不足以回答问题请直接说“根据已知信息无法回答该问题”不要编造信息。 上下文 {context} 问题{question} 请根据上下文回答同时可以在{context}中按照相关性从高到低排列文档并在每个文档前加上[文档1]、[文档2]的标识有助于LLM更好地利用信息。7. 常见问题与避坑指南在实际搭建过程中你会遇到各种各样的问题。这里记录一些高频问题和解决思路。问题现象可能原因排查与解决思路检索结果完全不相关1. 嵌入模型不适合领域。2. 文本切片不合理破坏了语义。3. 查询未用指令格式化针对BGE等模型。4. 向量索引类型或参数设置不当。1. 用领域内句子对测试嵌入模型相似度。2. 人工检查切片调整chunk_size和overlap。3. 确认查询编码格式符合模型要求。4. 检查索引的metric_type应为IP或L2调整nprobe等搜索参数。LLM回答出现幻觉不依据上下文1. 检索到的上下文本身不相关或质量差。2. Prompt指令不够强硬LLM自由发挥。3. 上下文太长或格式混乱LLM无法有效处理。1. 先检查检索阶段返回的文档是否真的相关。2. 强化Prompt使用“严格根据”、“必须引用”等措辞并让LLM指出引用来源。3. 尝试map_reduce或refine等链式方式处理长上下文或对检索到的文档进行摘要后再输入。系统响应速度慢1. 嵌入模型推理慢未用GPU或批处理。2. 向量索引未加载到内存或ANN参数nprobe太大。3. LLM生成速度慢。4. 网络延迟使用远程API时。1. 使用GPU推理并增大encode的batch_size。2. 确认集合已load()适当调小nprobe以平衡速度与精度。3. 考虑使用更小的LLM或启用流式输出改善体验。4. 考虑缓存频繁查询的嵌入或结果。对于简单事实性问题效果好复杂推理问题差1. 检索粒度太细单个切片无法提供完整推理链条。2. 未实现多跳检索Multi-hop Retrieval。1. 尝试增大chunk_size或采用基于章节的切片策略。2. 实现迭代检索用LLM从第一轮答案中提炼出新的查询进行第二轮检索如此循环。如何处理文档更新全量重建向量库成本高。1.增量更新为新文档生成向量并插入为已删除文档标记为无效软删除。定期如每周合并增量重建索引以优化性能。2. 使用支持动态更新的向量数据库如Milvus、Qdrant。最后一点个人体会RAG系统是一个典型的“木桶效应”工程最终效果取决于最短的那块板。不要只盯着最炫的LLM或最复杂的检索算法往往花时间把最基础的数据清洗和文本切片做好整个系统的效果就能提升一个档次。从简单的流程开始构建一个可工作的最小版本MVP然后基于真实的用户问题和bad cases有针对性地、一步一步地去迭代优化每一个环节这才是搭建一个健壮RAG知识库的正道。