这次不聊花哨的框架对比直接看 RAG检索增强生成的完整业务流程。很多同学学 RAG 的时候总被一堆名词绕晕Embedding、向量检索、切块、Rerank、知识库、召回率……概念好像都见过真到自己搭一个能问答的项目又不知道从哪一步开始。这篇文章会把 RAG 的核心链路拆开讲文本怎么变成向量、向量怎么被检索、检索结果怎么交给大模型生成答案。同时给出本地部署的通用流程、接口调用示例、批量任务设计思路和常见坑点。不管是刚入门大模型开发还是想给现有系统接入知识库问答这篇都值得收藏。1. RAG 核心能力速览先给一张速览表把 RAG 技术方案的关键信息放在前面方便快速判断。能力项说明项目类型大模型应用开发技术方案 / 检索增强生成核心能力文档解析、文本切块、Embedding、向量检索、大模型生成常用模型Embedding 模型BGE-M3、BGE-large-zh、m3e生成模型Qwen、DeepSeek、ChatGLM 等支持硬件CPU 可运行GPU 加速检索与推理具体显存取决于 Embedding 模型和 LLM 大小启动方式命令行启动 / Docker 启动 / API 服务启动 / WebUI 或管理端接入是否支持 API支持可通过 FastAPI / Flask 封装检索和问答接口是否支持批量任务支持可批量处理文档入库、批量问题和批量生成答案常用向量库Chroma、Milvus、FAISS、Qdrant、pgvector核心流程文档加载 → 切块 → Embedding → 存储 → 查询 → 向量检索 → LLM 生成适合读者大模型应用开发者、知识库系统开发者、RAG 项目入门者这套流程的优势在于不需要微调大模型也能让模型回答出私有知识内容。因为 RAG 的核心思路是“先检索再生成”让模型基于检索到的资料来回答问题而不是凭空编造。2. RAG 适用场景与使用边界2.1 适合哪些场景RAG 最适合的场景可以总结为“文档多、知识更新快、不能随便微调”的企业内部知识库问答。企业文档问答把操作手册、规章制度、产品文档切片入库员工可以直接提问。客服助手把常见问题库、售后政策、产品参数接入问答系统。课程资料与学习助手基于教材或讲义做学习问答。代码库问答把项目文档和代码片段切块后可以按语义查找相关实现。舆情分析与报告辅助先检索相关新闻再让模型总结减少幻觉。RAG 的核心价值是给大模型提供“外部知识”。它不需要重新训练模型也不需要维护模型权重只需要维护知识库数据因此知识更新成本远低于微调。2.2 不适合什么场景RAG 不适合所有问答场景以下几个场景需要谨慎评估。需要强推理、多步计算的数学或逻辑题RAG 检索到的资料往往只是背景模型本身推理能力不够时仍然容易出错。知识库内容很差、错别字多、排版混乱的文档切块和 Embedding 效果都会受影响检索质量很难保证。高频实时交易类查询如果数据延迟要求毫秒级而知识库更新又慢RAG 不是最优解。需要完全确定性的规则系统RAG 本质是概率检索加概率生成不适合对输出格式和答案准确性要求极高的场景。2.3 使用边界与合规提醒RAG 涉及文档处理和私有大模型应用需要特别注意以下几点。文档授权上传到知识库的文档必须是已获得授权的资料不能把内部保密文件随意送入外部 API 或云服务。隐私保护如果要求数据不出内网建议使用本地部署的 Embedding 模型和 LLM比如 Ollama 部署本地模型。输出审核RAG 生成的结果仍然可能出现幻觉尤其是检索到的资料与问题不相关时。商用前需要人工抽查或增加答案置信度判断。版权合规生成内容不能侵犯第三方版权特别是在内容发布场景中需要对生成结果做复核。3. Embedding 嵌入模型运行机制要理解 RAG必须先理解 Embedding。3.1 什么是 EmbeddingEmbedding 是把文本转换成向量一串浮点数的过程。简单说就是把“自然语言文本”映射到一个高维向量空间中让语义相近的文本在向量空间中的位置更接近。例如“今天天气怎么样” → [0.12, 0.34, -0.56, 0.78, ...]“明天会不会下雨” → [0.14, 0.31, -0.51, 0.80, ...]这两个句子的向量距离会比较近因为它们语义相近。而“今晚吃什么”的向量会离上面的句子更远。这就是 Embedding 模型做的事情把文本变成向量用向量的空间距离表示语义距离。3.2 Embedding 模型怎么选择目前常见的 Embedding 模型有模型特点适用语言BGE-M3多语言、支持稠密检索和稀疏检索、长文本支持好中英文BGE-large-zh中文效果较好资源占用适中中文m3e-base / m3e-large轻量级中文 Embedding 模型中文text-embedding-ada-002老牌闭源模型调用 API 更方便多语言gte-large / gte-base开源可选多种语言支持中英文选择 Embedding 模型时主要看三个维度语义表征能力在检索评测集上的准确率。支持的语言中文场景优先选中文语料训练充分的模型。输入长度限制如 512 token、8192 token 等决定文本切块的粒度。推理资源大模型参数量大占用的显存和内存也大。从实际项目看BGE-M3 是很流行的选择因为它同时支持稠密检索和稀疏检索还能做长文本编码方便做混合检索。3.3 文本切块策略文本切片是 RAG 流程中最容易被忽略但又很重要的环节。同一篇文章切块方式不同Embedding 检索效果会有明显差异。常见的切块策略包括固定长度切块按字符数或 token 数切分简单粗暴。段落切块按文档换行、段落分割保留语义完整性。重叠切块相邻块保留一定重叠部分避免上下文被切断。结构化切块按 Markdown 标题、代码块、表格等结构切分适合技术文档。智能切块基于语义边界切分比如根据句子向量变化来确定边界。切块大小需要根据文档类型和 Embedding 模型能力调整。一般来说问答类文档每块 200 到 500 字左右比较合适。技术文档按章节或小节切保留标题层级。长文本如果 Embedding 模型支持长文本可以适当加大切块但检索精度可能下降。切块太大会导致检索到的内容包含太多无关信息回答不聚焦切块太小又可能丢失上下文导致语义不完整。建议在项目里多做几组切块实验验证问答质量再定方案。4. RAG 本地部署环境准备4.1 通用环境要求RAG 项目一般由四个部分组成文档处理层负责加载 PDF、Word、Markdown、HTML 等格式文档。Embedding 服务可以把自定义文档转成向量。向量数据库存储和检索向量。LLM 服务负责根据检索结果生成答案。最省事的部署方式是使用 Ollama 本地部署 Embedding 模型和生成模型再配合 Python 做流程编排。环境准备清单操作系统推荐 Linux 或 Windows WSL2macOS 也可运行。Python建议 3.10 以上。CUDA如果用 N 卡 GPU 加速需要安装对应版本的 CUDA 和显卡驱动。Ollama支持一键安装可以拉取 Embedding 模型和 LLM。向量数据库Chroma 适合快速学习Milvus 适合生产环境。磁盘空间10GB 以上比较稳妥具体取决于模型文件大小。4.2 安装 Python 依赖以 Python 环境为例核心依赖包括pip install langchain langchain-community langchain-ollama pip install chromadb pip install fastapi uvicorn pip install pymilvus # 如果使用 Milvus pip install pypdf # 解析 PDF4.3 通过 Ollama 拉取模型Ollama 是目前比较方便的本地模型管理工具支持命令行一键拉取模型。# 安装 OllamaWindows / macOS / Linux 官网下载即可 # 拉取中文 Embedding 模型 ollama pull bge-m3 # 拉取生成模型 ollama pull qwen2.5:7b如果机器没有 GPU也可以用 CPU 运行只是推理速度会慢一些。如果显存不够可以换小一点的模型比如qwen2.5:3b。4.4 初始化向量数据库使用 Chroma 作为本地向量库时代码如下from chromadb import PersistentClient client PersistentClient(path./data/chroma_db) collection client.get_or_create_collection( nameknowledge_base, embedding_functionNone # 我们用外部 Embedding不依赖 Chroma 内置 )如果有大量文档且需要分布式扩展可以考虑 Milvus。Milvus 属于更重的方案适合生产环境。5. RAG 功能测试与效果验证5.1 测试目标一个标准的 RAG 项目要验证以下能力文档能正常加载并切块。Embedding 能正确生成向量。向量库能正确存储和检索。检索结果与问题语义相关。大模型能基于检索结果生成回答。回答内容与文档事实一致。5.2 构建知识库流程先用一段测试文档走通流程。from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_ollama import OllamaEmbeddings from chromadb import PersistentClient # 1. 加载文档 loader PyPDFLoader(test_docs/product_manual.pdf) documents loader.load() # 2. 切块 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50 ) chunks splitter.split_documents(documents) # 3. 加载 Embedding 模型 embeddings OllamaEmbeddings(modelbge-m3) # 4. 写入向量库 client PersistentClient(path./data/chroma_db) collection client.get_or_create_collection(nameknowledge_base) for i, chunk in enumerate(chunks): vector embeddings.embed_query(chunk.page_content) collection.add( ids[fchunk_{i}], embeddings[vector], documents[chunk.page_content], metadatas[{source: chunk.metadata.get(source, )}] ) print(f入库完成共 {len(chunks)} 个文本块)5.3 向量检索测试检索时需要把用户问题也转换为向量然后在向量库中查找最近邻。question 这个产品的保修期是多久 question_vector embeddings.embed_query(question) results collection.query( query_embeddings[question_vector], n_results5 ) for idx, doc in enumerate(results[documents][0]): print(f第 {idx 1} 个结果) print(doc) print(---)判断检索效果的标准是返回的前几个文本块是否与问题相关。如果检索结果不相关可能是切块太粗、模型语义能力弱或者文档格式解析有问题。5.4 完整 RAG 问答测试把检索结果拼进 Prompt再让大模型生成答案。from langchain_ollama import OllamaLLM llm OllamaLLM(modelqwen2.5:7b, temperature0.3) def rag_answer(question, context): prompt f请基于以下资料回答问题。如果资料中找不到答案请直接说“资料中未找到相关信息”。 资料 {context} 问题{question} 回答 return llm.invoke(prompt) context \n.join(results[documents][0]) answer rag_answer(question, context) print(answer)这个流程是 RAG 最核心的 Mini 实现。实际项目中你还会加入 Rerank、混合检索、引用来源标注、对话历史等功能。6. 接口 API 与批量任务6.1 封装 FastAPI 接口当本地流程跑通后可以把 RAG 封装成 HTTP 接口方便上层应用调用。from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class QueryRequest(BaseModel): question: str top_k: int 5 class QueryResponse(BaseModel): answer: str sources: list[str] app.post(/query, response_modelQueryResponse) async def query(request: QueryRequest): # 这里复用上面的检索 生成逻辑 question_vector embeddings.embed_query(request.question) results collection.query( query_embeddings[question_vector], n_resultsrequest.top_k ) context \n.join(results[documents][0]) answer rag_answer(request.question, context) return QueryResponse(answeranswer, sourcesresults[documents][0]) if __name__ __main__: import uvicorn uvicorn.run(app, host127.0.0.1, port8000)启动接口服务python api_server.py调用接口curl -X POST http://127.0.0.1:8000/query \ -H Content-Type: application/json \ -d {question: 这个产品的保修期是多久, top_k: 3}也可以用 Python 调用import requests response requests.post( http://127.0.0.1:8000/query, json{question: 这个产品的保修期是多久, top_k: 3}, timeout120 ) print(response.json())6.2 批量任务设计生产环境中的 RAG 项目通常需要批量处理两类任务批量文档入库任务。批量问答生成任务。批量文档入库的任务队列可以这样设计任务输入input_docs/ 目录下多个文档 任务处理 1. 解析文档 2. 文本切块 3. 生成 Embedding 4. 写入向量库 任务输出入库日志、成功列表、失败列表批量问答生成则要特别注意每个问题单独记录日志。增加超时和失败重试机制。控制并发数避免把 LLM 服务打爆。输出结果保存为 JSONL 或 CSV方便后续分析。批量任务建议使用消息队列如 Redis Queue、Celery来管理而不是简单写一个 for 循环。因为 LLM 推理时间不稳定一旦中途失败没有任务队列就很难恢复。7. 向量检索性能优化与资源观察7.1 混合检索与 Rerank基础向量检索是稠密检索通过语义相似度找到相关文本。但在一些场景下关键词精确匹配更加可靠比如检索型号、编号、专有名词。这时就可以使用混合检索。混合检索的思路是把向量检索和关键词检索如 BM25结合再进行归一化融合。很多 RAG 框架已经内置了这种能力例如LangChain 中的 EnsembleRetriever。Milvus 的 Hybrid Search。BGE-M3 本身支持同时生成稠密向量和稀疏向量。Rerank 则是另一层优化先粗召回一批候选文本再用重排模型对候选结果重新打分把最相关的文本排到最前面。7.2 显存与内存观察本地部署 RAG 时主要资源消耗来自两部分Embedding 模型推理BGE-M3 这类模型在 CPU 上也可以跑但批量处理时 GPU 加速更明显。LLM 推理7B 级别模型需要至少 6GB 到 8GB 显存14B 及以上需要更多。实际占用取决于模型量化版本、上下文长度和并发数。观察显存占用的常用命令# 查看 GPU 显存占用 nvidia-smi # 查看内存占用 free -h如果是 CPU 推理建议把模型量化为 4bit 或 8bit能明显降低内存需求速度也有改善。7.3 如何降低资源占用使用量化模型GGUF 格式的 4bit 量化模型资源占用更少。控制上下文长度Prompt 不要无限拼接检索结果。限制向量库返回条数默认 top_k 设置为 3 到 5不要一次性返回 20 条。批量处理时限制并发一次处理 1 到 2 个请求避免显存溢出。使用轻量 Embedding 模型检索场景不一定非用最大的模型。8. RAG 常见问题与排查方法下面这张表总结了 RAG 项目中最常见的几类问题。问题现象可能原因排查方式解决方案启动时报模型不存在Ollama 模型未拉取或模型名拼写错误执行ollama list查看模型列表用ollama pull 模型名拉取正确模型PDF 解析乱码PDF 是扫描件或字体编码异常查看加载后的文档内容改用 OCR 解析工具或先用图片转文字检索结果不相关切块过大或过小、Embedding 模型不适合打印切块结果人工检查相关性调整切块策略更换 Embedding 模型回答内容与资料无关LLM 忽略上下文或 Prompt 设计不清检查输入给 LLM 的 Prompt 内容强化 Prompt 约束添加“资料中未找到”处理接口调用超时LLM 推理太慢或请求排队观察服务日志和 GPU 占用减小模型规模、限制并发、开启流式输出批量任务中断单条任务异常导致进程退出查看日志定位失败项使用任务队列增加超时和失败重试显存不足模型太大或并发太高运行nvidia-smi查看显存使用小模型、量化版本或降低并发向量库数据文件损坏写入中断或版本不兼容检查数据库日志重新导入数据定期备份向量库目录9. RAG 项目最佳实践与合规建议9.1 先用最小数据集跑通链路第一次做 RAG不要直接上一整本几百页的 PDF。先准备 3 到 5 个文档切块后手动检查每块的内容质量再验证检索效果。这样能快速定位是文档解析的问题还是切块、检索的问题。9.2 记录每次实验的关键参数RAG 项目的效果和参数强相关建议每次实验都记录切块大小与 overlap。Embedding 模型名称。向量库类型。Rerank 是否开启。LLM 模型与温度参数。检索 top_k。测试问题集和人工打分结果。这样后续优化时才知道是哪个环节发生了变化。9.3 知识库更新策略知识库不是一次性建完就不管了。生产环境中要考虑增量更新给每个文本块记录来源文档和更新时间。文档更新时删除对应向量重新入库。定期清理无效文本块。版本化知识库方便回滚。9.4 合规使用建议这里再强调一遍涉及本地部署和知识库问答时务必遵守以下原则只处理已获得授权的文档。内网数据优先选择本地部署模型不传外部 API。人脸、声纹、身份证号等敏感信息不得进入测试系统。商用发布前对生成答案做内容审核。10. 总结与下一步RAG 技术栈的核心链路并不复杂文档切块、Embedding、向量检索、LLM 生成四个环节打通就能做出一个可用的知识库问答系统。最难的不是跑通 Demo而是让检索结果稳定可靠。建议下一步做这几件事用 Ollama 部署 BGE-M3 和一个小参数 LLM跑通本地 RAG。准备一组真实业务文档测试不同切块策略下的检索质量。封装 FastAPI 接口把单独的知识库能力接到现有系统中。逐步引入混合检索和 Rerank观察回答准确率的变化。批量任务加上日志、重试和监控再考虑生产部署。RAG 项目入门不难但做好需要不断调试。建议收藏这篇文章做项目时对着流程一步步推进。 RAG完整业务流程：从Embedding到向量检索与LLM生成
这次不聊花哨的框架对比直接看 RAG检索增强生成的完整业务流程。很多同学学 RAG 的时候总被一堆名词绕晕Embedding、向量检索、切块、Rerank、知识库、召回率……概念好像都见过真到自己搭一个能问答的项目又不知道从哪一步开始。这篇文章会把 RAG 的核心链路拆开讲文本怎么变成向量、向量怎么被检索、检索结果怎么交给大模型生成答案。同时给出本地部署的通用流程、接口调用示例、批量任务设计思路和常见坑点。不管是刚入门大模型开发还是想给现有系统接入知识库问答这篇都值得收藏。1. RAG 核心能力速览先给一张速览表把 RAG 技术方案的关键信息放在前面方便快速判断。能力项说明项目类型大模型应用开发技术方案 / 检索增强生成核心能力文档解析、文本切块、Embedding、向量检索、大模型生成常用模型Embedding 模型BGE-M3、BGE-large-zh、m3e生成模型Qwen、DeepSeek、ChatGLM 等支持硬件CPU 可运行GPU 加速检索与推理具体显存取决于 Embedding 模型和 LLM 大小启动方式命令行启动 / Docker 启动 / API 服务启动 / WebUI 或管理端接入是否支持 API支持可通过 FastAPI / Flask 封装检索和问答接口是否支持批量任务支持可批量处理文档入库、批量问题和批量生成答案常用向量库Chroma、Milvus、FAISS、Qdrant、pgvector核心流程文档加载 → 切块 → Embedding → 存储 → 查询 → 向量检索 → LLM 生成适合读者大模型应用开发者、知识库系统开发者、RAG 项目入门者这套流程的优势在于不需要微调大模型也能让模型回答出私有知识内容。因为 RAG 的核心思路是“先检索再生成”让模型基于检索到的资料来回答问题而不是凭空编造。2. RAG 适用场景与使用边界2.1 适合哪些场景RAG 最适合的场景可以总结为“文档多、知识更新快、不能随便微调”的企业内部知识库问答。企业文档问答把操作手册、规章制度、产品文档切片入库员工可以直接提问。客服助手把常见问题库、售后政策、产品参数接入问答系统。课程资料与学习助手基于教材或讲义做学习问答。代码库问答把项目文档和代码片段切块后可以按语义查找相关实现。舆情分析与报告辅助先检索相关新闻再让模型总结减少幻觉。RAG 的核心价值是给大模型提供“外部知识”。它不需要重新训练模型也不需要维护模型权重只需要维护知识库数据因此知识更新成本远低于微调。2.2 不适合什么场景RAG 不适合所有问答场景以下几个场景需要谨慎评估。需要强推理、多步计算的数学或逻辑题RAG 检索到的资料往往只是背景模型本身推理能力不够时仍然容易出错。知识库内容很差、错别字多、排版混乱的文档切块和 Embedding 效果都会受影响检索质量很难保证。高频实时交易类查询如果数据延迟要求毫秒级而知识库更新又慢RAG 不是最优解。需要完全确定性的规则系统RAG 本质是概率检索加概率生成不适合对输出格式和答案准确性要求极高的场景。2.3 使用边界与合规提醒RAG 涉及文档处理和私有大模型应用需要特别注意以下几点。文档授权上传到知识库的文档必须是已获得授权的资料不能把内部保密文件随意送入外部 API 或云服务。隐私保护如果要求数据不出内网建议使用本地部署的 Embedding 模型和 LLM比如 Ollama 部署本地模型。输出审核RAG 生成的结果仍然可能出现幻觉尤其是检索到的资料与问题不相关时。商用前需要人工抽查或增加答案置信度判断。版权合规生成内容不能侵犯第三方版权特别是在内容发布场景中需要对生成结果做复核。3. Embedding 嵌入模型运行机制要理解 RAG必须先理解 Embedding。3.1 什么是 EmbeddingEmbedding 是把文本转换成向量一串浮点数的过程。简单说就是把“自然语言文本”映射到一个高维向量空间中让语义相近的文本在向量空间中的位置更接近。例如“今天天气怎么样” → [0.12, 0.34, -0.56, 0.78, ...]“明天会不会下雨” → [0.14, 0.31, -0.51, 0.80, ...]这两个句子的向量距离会比较近因为它们语义相近。而“今晚吃什么”的向量会离上面的句子更远。这就是 Embedding 模型做的事情把文本变成向量用向量的空间距离表示语义距离。3.2 Embedding 模型怎么选择目前常见的 Embedding 模型有模型特点适用语言BGE-M3多语言、支持稠密检索和稀疏检索、长文本支持好中英文BGE-large-zh中文效果较好资源占用适中中文m3e-base / m3e-large轻量级中文 Embedding 模型中文text-embedding-ada-002老牌闭源模型调用 API 更方便多语言gte-large / gte-base开源可选多种语言支持中英文选择 Embedding 模型时主要看三个维度语义表征能力在检索评测集上的准确率。支持的语言中文场景优先选中文语料训练充分的模型。输入长度限制如 512 token、8192 token 等决定文本切块的粒度。推理资源大模型参数量大占用的显存和内存也大。从实际项目看BGE-M3 是很流行的选择因为它同时支持稠密检索和稀疏检索还能做长文本编码方便做混合检索。3.3 文本切块策略文本切片是 RAG 流程中最容易被忽略但又很重要的环节。同一篇文章切块方式不同Embedding 检索效果会有明显差异。常见的切块策略包括固定长度切块按字符数或 token 数切分简单粗暴。段落切块按文档换行、段落分割保留语义完整性。重叠切块相邻块保留一定重叠部分避免上下文被切断。结构化切块按 Markdown 标题、代码块、表格等结构切分适合技术文档。智能切块基于语义边界切分比如根据句子向量变化来确定边界。切块大小需要根据文档类型和 Embedding 模型能力调整。一般来说问答类文档每块 200 到 500 字左右比较合适。技术文档按章节或小节切保留标题层级。长文本如果 Embedding 模型支持长文本可以适当加大切块但检索精度可能下降。切块太大会导致检索到的内容包含太多无关信息回答不聚焦切块太小又可能丢失上下文导致语义不完整。建议在项目里多做几组切块实验验证问答质量再定方案。4. RAG 本地部署环境准备4.1 通用环境要求RAG 项目一般由四个部分组成文档处理层负责加载 PDF、Word、Markdown、HTML 等格式文档。Embedding 服务可以把自定义文档转成向量。向量数据库存储和检索向量。LLM 服务负责根据检索结果生成答案。最省事的部署方式是使用 Ollama 本地部署 Embedding 模型和生成模型再配合 Python 做流程编排。环境准备清单操作系统推荐 Linux 或 Windows WSL2macOS 也可运行。Python建议 3.10 以上。CUDA如果用 N 卡 GPU 加速需要安装对应版本的 CUDA 和显卡驱动。Ollama支持一键安装可以拉取 Embedding 模型和 LLM。向量数据库Chroma 适合快速学习Milvus 适合生产环境。磁盘空间10GB 以上比较稳妥具体取决于模型文件大小。4.2 安装 Python 依赖以 Python 环境为例核心依赖包括pip install langchain langchain-community langchain-ollama pip install chromadb pip install fastapi uvicorn pip install pymilvus # 如果使用 Milvus pip install pypdf # 解析 PDF4.3 通过 Ollama 拉取模型Ollama 是目前比较方便的本地模型管理工具支持命令行一键拉取模型。# 安装 OllamaWindows / macOS / Linux 官网下载即可 # 拉取中文 Embedding 模型 ollama pull bge-m3 # 拉取生成模型 ollama pull qwen2.5:7b如果机器没有 GPU也可以用 CPU 运行只是推理速度会慢一些。如果显存不够可以换小一点的模型比如qwen2.5:3b。4.4 初始化向量数据库使用 Chroma 作为本地向量库时代码如下from chromadb import PersistentClient client PersistentClient(path./data/chroma_db) collection client.get_or_create_collection( nameknowledge_base, embedding_functionNone # 我们用外部 Embedding不依赖 Chroma 内置 )如果有大量文档且需要分布式扩展可以考虑 Milvus。Milvus 属于更重的方案适合生产环境。5. RAG 功能测试与效果验证5.1 测试目标一个标准的 RAG 项目要验证以下能力文档能正常加载并切块。Embedding 能正确生成向量。向量库能正确存储和检索。检索结果与问题语义相关。大模型能基于检索结果生成回答。回答内容与文档事实一致。5.2 构建知识库流程先用一段测试文档走通流程。from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_ollama import OllamaEmbeddings from chromadb import PersistentClient # 1. 加载文档 loader PyPDFLoader(test_docs/product_manual.pdf) documents loader.load() # 2. 切块 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap50 ) chunks splitter.split_documents(documents) # 3. 加载 Embedding 模型 embeddings OllamaEmbeddings(modelbge-m3) # 4. 写入向量库 client PersistentClient(path./data/chroma_db) collection client.get_or_create_collection(nameknowledge_base) for i, chunk in enumerate(chunks): vector embeddings.embed_query(chunk.page_content) collection.add( ids[fchunk_{i}], embeddings[vector], documents[chunk.page_content], metadatas[{source: chunk.metadata.get(source, )}] ) print(f入库完成共 {len(chunks)} 个文本块)5.3 向量检索测试检索时需要把用户问题也转换为向量然后在向量库中查找最近邻。question 这个产品的保修期是多久 question_vector embeddings.embed_query(question) results collection.query( query_embeddings[question_vector], n_results5 ) for idx, doc in enumerate(results[documents][0]): print(f第 {idx 1} 个结果) print(doc) print(---)判断检索效果的标准是返回的前几个文本块是否与问题相关。如果检索结果不相关可能是切块太粗、模型语义能力弱或者文档格式解析有问题。5.4 完整 RAG 问答测试把检索结果拼进 Prompt再让大模型生成答案。from langchain_ollama import OllamaLLM llm OllamaLLM(modelqwen2.5:7b, temperature0.3) def rag_answer(question, context): prompt f请基于以下资料回答问题。如果资料中找不到答案请直接说“资料中未找到相关信息”。 资料 {context} 问题{question} 回答 return llm.invoke(prompt) context \n.join(results[documents][0]) answer rag_answer(question, context) print(answer)这个流程是 RAG 最核心的 Mini 实现。实际项目中你还会加入 Rerank、混合检索、引用来源标注、对话历史等功能。6. 接口 API 与批量任务6.1 封装 FastAPI 接口当本地流程跑通后可以把 RAG 封装成 HTTP 接口方便上层应用调用。from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class QueryRequest(BaseModel): question: str top_k: int 5 class QueryResponse(BaseModel): answer: str sources: list[str] app.post(/query, response_modelQueryResponse) async def query(request: QueryRequest): # 这里复用上面的检索 生成逻辑 question_vector embeddings.embed_query(request.question) results collection.query( query_embeddings[question_vector], n_resultsrequest.top_k ) context \n.join(results[documents][0]) answer rag_answer(request.question, context) return QueryResponse(answeranswer, sourcesresults[documents][0]) if __name__ __main__: import uvicorn uvicorn.run(app, host127.0.0.1, port8000)启动接口服务python api_server.py调用接口curl -X POST http://127.0.0.1:8000/query \ -H Content-Type: application/json \ -d {question: 这个产品的保修期是多久, top_k: 3}也可以用 Python 调用import requests response requests.post( http://127.0.0.1:8000/query, json{question: 这个产品的保修期是多久, top_k: 3}, timeout120 ) print(response.json())6.2 批量任务设计生产环境中的 RAG 项目通常需要批量处理两类任务批量文档入库任务。批量问答生成任务。批量文档入库的任务队列可以这样设计任务输入input_docs/ 目录下多个文档 任务处理 1. 解析文档 2. 文本切块 3. 生成 Embedding 4. 写入向量库 任务输出入库日志、成功列表、失败列表批量问答生成则要特别注意每个问题单独记录日志。增加超时和失败重试机制。控制并发数避免把 LLM 服务打爆。输出结果保存为 JSONL 或 CSV方便后续分析。批量任务建议使用消息队列如 Redis Queue、Celery来管理而不是简单写一个 for 循环。因为 LLM 推理时间不稳定一旦中途失败没有任务队列就很难恢复。7. 向量检索性能优化与资源观察7.1 混合检索与 Rerank基础向量检索是稠密检索通过语义相似度找到相关文本。但在一些场景下关键词精确匹配更加可靠比如检索型号、编号、专有名词。这时就可以使用混合检索。混合检索的思路是把向量检索和关键词检索如 BM25结合再进行归一化融合。很多 RAG 框架已经内置了这种能力例如LangChain 中的 EnsembleRetriever。Milvus 的 Hybrid Search。BGE-M3 本身支持同时生成稠密向量和稀疏向量。Rerank 则是另一层优化先粗召回一批候选文本再用重排模型对候选结果重新打分把最相关的文本排到最前面。7.2 显存与内存观察本地部署 RAG 时主要资源消耗来自两部分Embedding 模型推理BGE-M3 这类模型在 CPU 上也可以跑但批量处理时 GPU 加速更明显。LLM 推理7B 级别模型需要至少 6GB 到 8GB 显存14B 及以上需要更多。实际占用取决于模型量化版本、上下文长度和并发数。观察显存占用的常用命令# 查看 GPU 显存占用 nvidia-smi # 查看内存占用 free -h如果是 CPU 推理建议把模型量化为 4bit 或 8bit能明显降低内存需求速度也有改善。7.3 如何降低资源占用使用量化模型GGUF 格式的 4bit 量化模型资源占用更少。控制上下文长度Prompt 不要无限拼接检索结果。限制向量库返回条数默认 top_k 设置为 3 到 5不要一次性返回 20 条。批量处理时限制并发一次处理 1 到 2 个请求避免显存溢出。使用轻量 Embedding 模型检索场景不一定非用最大的模型。8. RAG 常见问题与排查方法下面这张表总结了 RAG 项目中最常见的几类问题。问题现象可能原因排查方式解决方案启动时报模型不存在Ollama 模型未拉取或模型名拼写错误执行ollama list查看模型列表用ollama pull 模型名拉取正确模型PDF 解析乱码PDF 是扫描件或字体编码异常查看加载后的文档内容改用 OCR 解析工具或先用图片转文字检索结果不相关切块过大或过小、Embedding 模型不适合打印切块结果人工检查相关性调整切块策略更换 Embedding 模型回答内容与资料无关LLM 忽略上下文或 Prompt 设计不清检查输入给 LLM 的 Prompt 内容强化 Prompt 约束添加“资料中未找到”处理接口调用超时LLM 推理太慢或请求排队观察服务日志和 GPU 占用减小模型规模、限制并发、开启流式输出批量任务中断单条任务异常导致进程退出查看日志定位失败项使用任务队列增加超时和失败重试显存不足模型太大或并发太高运行nvidia-smi查看显存使用小模型、量化版本或降低并发向量库数据文件损坏写入中断或版本不兼容检查数据库日志重新导入数据定期备份向量库目录9. RAG 项目最佳实践与合规建议9.1 先用最小数据集跑通链路第一次做 RAG不要直接上一整本几百页的 PDF。先准备 3 到 5 个文档切块后手动检查每块的内容质量再验证检索效果。这样能快速定位是文档解析的问题还是切块、检索的问题。9.2 记录每次实验的关键参数RAG 项目的效果和参数强相关建议每次实验都记录切块大小与 overlap。Embedding 模型名称。向量库类型。Rerank 是否开启。LLM 模型与温度参数。检索 top_k。测试问题集和人工打分结果。这样后续优化时才知道是哪个环节发生了变化。9.3 知识库更新策略知识库不是一次性建完就不管了。生产环境中要考虑增量更新给每个文本块记录来源文档和更新时间。文档更新时删除对应向量重新入库。定期清理无效文本块。版本化知识库方便回滚。9.4 合规使用建议这里再强调一遍涉及本地部署和知识库问答时务必遵守以下原则只处理已获得授权的文档。内网数据优先选择本地部署模型不传外部 API。人脸、声纹、身份证号等敏感信息不得进入测试系统。商用发布前对生成答案做内容审核。10. 总结与下一步RAG 技术栈的核心链路并不复杂文档切块、Embedding、向量检索、LLM 生成四个环节打通就能做出一个可用的知识库问答系统。最难的不是跑通 Demo而是让检索结果稳定可靠。建议下一步做这几件事用 Ollama 部署 BGE-M3 和一个小参数 LLM跑通本地 RAG。准备一组真实业务文档测试不同切块策略下的检索质量。封装 FastAPI 接口把单独的知识库能力接到现有系统中。逐步引入混合检索和 Rerank观察回答准确率的变化。批量任务加上日志、重试和监控再考虑生产部署。RAG 项目入门不难但做好需要不断调试。建议收藏这篇文章做项目时对着流程一步步推进。