上周跟一个做企业服务的架构师朋友聊天他提到一个特别典型的场景老板看完大模型项目的报价单脸色当场就变了。动辄几十万的GPU采购、训练集群、算法团队编制加上先跑三个月试试这种话术换谁都肉疼。但业务部门又天天催能不能用大模型把我们那几千份手册、合同、工单变成可以问答的知识库其实这类诉求用RAG检索增强生成做私有化落地恰恰是最不烧钱、最快见效的一条路。我本人就带着团队从零预算起步在一台24GB显存的机器上完成了整个POC最后平稳过渡到vLLM推理引擎支撑的服务。这篇就把这条路线拆开揉碎讲清楚包括选型逻辑、部署细节、检索链路的搭建还有那些不踩一遍绝对不知道的坑。这篇文章适合谁如果你是技术负责人、架构师或者正准备给内部做AI落地的工程师手里预算有限但需要先跑通一个效果可验证的POC那下面这些内容可以直接抄作业。1. 先想清楚RAG的POC到底要验证什么1.1 RAG机制的最简解读很多人第一次接触RAG容易被向量化语义相似度重排序这些词唬住。说破了一层窗户纸RAG就是先在自己的知识库里做搜索搜出最相关的几段文字然后把这几段文字和用户的问题拼在一起交给大模型让它根据给定资料回答。关键点在于模型本身的参数一点都不改。它的优势和价值在于一种工程手段——利用外部知识库给模型开卷考试。企业内部的知识每天都在变、合同每周都在签、产品文档下个季度就更新如果用微调的方式同步这些变化成本不堪设想而RAG只需要把新文档切成碎片、算成向量、丢进向量库就完事了。1.2 验证目标的排序效果、成本、安全我在做POC之前习惯先把验证目标按优先级排个序否则很容易被细节带偏。对于大多数企业场景顺序应该是这样的效果给定文档片段模型能不能答对拒绝率不知道就说不知道高不高引用是否真实成本在可接受的响应延迟下一台机器能支撑多少并发单位请求成本是多少安全数据全程不出内网模型权重从哪来日志会不会记录敏感内容。可运维性模型怎么更新向量库怎么重建服务挂了怎么拉起来。POC阶段最忌讳一上来就追求上线级的可靠性。你可以接受服务偶尔重启但不能接受答非所问你可以接受并发只有个位数但不能接受显存直接溢出。1.3 为什么RAG而不是微调这个问题基本每一个决策者都会问。我给一个判断标准如果你的核心诉求是让模型掌握某种特定格式和语气比如客服话术、特定行业文风微调可能值得做但如果诉求是让模型知道那些只有你们公司才有的知识RAG是绝对的首选。还有一个更实际的理由微调需要构造大量高质量的输入-输出训练对这本身就是一个需要标注团队、需要数据清洗流程的工程。而RAG的准备流程简单得多——文档切一切、向量化、入库。如果效果不好不需要重新训练调调参数就可以了。这个快和便宜是POC阶段最宝贵的特性。2. 从零起步的选型模型、引擎、向量库2.1 基座模型怎么选7B到14B就够用很多团队一上来就想跑70B的大模型但POC阶段完全没必要。以目前的量化方案和推理引擎7B~14B这个档位的模型在多数企业内部知识问答场景已经够用中文表现也很成熟。我的推荐表是这样的模型档位推荐选项显存要求量化后适用场景7B量级Qwen2.5-7B-InstructAWQ量化6~8GB大多数中文知识问答性价比最高14B量级Qwen2.5-14B-InstructAWQ量化12~16GB需要更强推理能力的场景比如多跳问答8B量级Llama 3.1 8B Instruct6~8GB英文场景为主32B暂不建议POC阶段尝试需要24GB以上多卡或大显存确定小模型效果不够时再升级我的真实感受是很多业务问题的难点根本不在模型聪明不聪明而在有没有把正确的资料送到模型嘴边。只要检索做得够好7B模型的表现已经能让业务方点头。2.2 推理引擎的抉择为什么锁死vLLMPOC阶段如果直接裸用transformers库加载模型做推理也可以跑通但你会很快撞到几堵墙并发一上来显存瞬间爆掉每个请求都要等前面的生成完吞吐量低到让人怀疑人生。vLLM凭借两个核心技术解决了这些问题PagedAttention通过类似操作系统中虚拟内存的分页机制把KV Cache切块管理显存利用率大幅提升Continuous Batching允许新请求在旧请求生成间隙插入并发处理效率高出一个数量级。再加上它与主流API协议兼容意味着你后续接业务系统时可以像调云服务一样调内网服务SDK换一下URL就行。我还遇到过一种情况有团队用了FastAPI裸调模型延迟看起来还行但一旦加上多路并发的压测直接崩掉。换上vLLM之后同样的单卡吞吐量翻了好几倍。所以我的建议是从一开始就不要走弯路POC第一课就是先把vLLM跑起来。2.3 嵌入模型和向量库尽量轻装上阵嵌入模型的选择容易被忽视但它决定了检索质量的天花板。我的建议是中文场景直接用BGE系列如bge-large-zh-v1.5效果稳定且有配套的查询指令前缀如果某些文档是英文为主可以考虑bge-base-en或BGE-M3多语言版本。嵌入维度通常1024单文档向量化的成本很低POC阶段完全不敏感。向量库的选择更简单不要一上来就上Elasticsearch、Milvus这些重组件。POC阶段用Chroma或FAISS就够。Chroma非常适合快速验证Python环境下十分钟就能搭起来支持持久化FAISS更轻量、检索速度更快适合纯向量检索场景。等POC跑通了再根据生产需求评估是否引入更重型的向量数据库不迟。2.4 成本阶梯从$0到私有化的四个阶段整个过程我总结成四个阶梯每一级都有明确的成本标志阶段硬件要求技术栈单次请求成本估算L0纯验证任何一台普通笔记本CPU用API也好用最小模型也好先验证流程可忽略L1本地小模型无显卡也行但要能跑7B量化vLLM CPU版或低量化模型几分钱级别L2单卡私有化一张24GB显卡如RTX 4090或等显存专业卡vLLM 7B/14B AWQ BGE Chroma/FAISS按电费折算成本极低L3多卡生产化多张加速卡 高可用架构vLLM集群 正式向量库 监控链路视并发绝大多数企业的POC不需要越过L2。等到业务方、决策者都认可效果之后再往L3走那时候采购预算也容易批得多。3. 一台24GB显卡机器上完整跑通POC3.1 环境准备Conda、CUDA、vLLM安装我习惯先装好CUDA驱动然后创建一个干净的环境。vLLM对Python版本有要求用Python 3.10是稳妥选择。基础安装命令如下conda create -n rag-poc python3.10 -y conda activate rag-poc # 安装vLLM会自动拉取匹配的torch版本 pip install vllm # 如果显卡较老需要单独确认CUDA兼容 nvidia-smi安装过程中最容易出问题的是torch版本与CUDA版本的匹配。强烈建议不要在机器上预先装一个特定的torch再让vLLM去适配它——让pip自己解析依赖成功率更高。第一次启动时会下载模型权重务必确认网络能访问模型仓库。3.2 拉起vLLM推理服务一条命令就能拉起完整的OpenAI兼容服务。我以Qwen2.5-7B-Instruct的AWQ量化版为例vllm serve Qwen/Qwen2.5-7B-Instruct-AWQ \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --quantization awq \ --port 8000参数解释一下--max-model-len 8192限制最大上下文长度这一步特别关键因为上下文长度的增大会直接推高显存占用--gpu-memory-utilization 0.85允许vLLM使用最多85%的显存留出一部分余量给嵌入模型和重排序模型。等一下这里有个我自己踩过的坑如果机器上还需要同时跑嵌入模型要给它留出显存。我吃过一次亏把所有显存都丢给vLLM结果向量化的时候直接CUDA OOM。后来把vLLM的显存利用率调到0.75嵌入模型用CPU推理问题才算解决。嵌入模型本身很轻量CPU推理速度足够支撑POC。启动完成后先验证一下服务是否正常curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Qwen/Qwen2.5-7B-Instruct-AWQ, messages: [{role: user, content: 你好请简单自我介绍}], temperature: 0.2 }看到正常返回就意味着推理引擎已经就位。接下来看指标/metrics端点暴露了Prometheus格式的性能数据重点看avg_generation_throughput这个数字就是每秒生成的token数。3.3 知识库的切分与向量化处理企业内部文档时我强烈推荐先有一个脏活累活的心理预期。文档解析是最容易忽略的环节PDF里的扫描件要先OCRWord表格要特殊处理PPT的文字要按页提取。POC阶段不用做得很完美但至少要保证文本提取不出现大段错乱。切分策略我建议先跑一个固定方案用LangChain的递归字符切分器chunk_size取512chunk_overlap取64。这里的思路是太小了语义被截断太大了检索精度下降512对大多数说明文和合同条款是起步点。后续根据效果再调。向量化和入库的示例代码用Chroma做持久化from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter # 1. 加载并切分文档 loader PyPDFLoader(example.pdf) docs loader.load() splitter RecursiveCharacterTextSplitter( chunk_size512, chunk_overlap64, separators[\n\n, \n, 。, , , ] ) chunks splitter.split_documents(docs) # 2. 初始化嵌入模型CPU够用 embeddings HuggingFaceEmbeddings( model_nameBAAI/bge-large-zh-v1.5, model_kwargs{device: cpu} ) # 3. 入库带持久化 vectordb Chroma.from_documents( chunks, embeddings, persist_directory./chroma_store ) vectordb.persist()几个细节我展开说说。separators这个参数列表看起来不起眼但中文场景下顺序特别重要先按段落双换行切再按句子级标点切这样能最大限度保留语义完整性如果直接把放在最前面切出来的碎片会非常碎。另外BGE系列模型在做语义检索时官方建议给查询语句加一个为这个句子生成表示以用于检索相关文章前缀这个前缀在HuggingFaceEmbeddings中可以通过query_instruction参数配置。别小看这个细节加上它检索命中率能提升好几个百分点。3.4 组装检索问答链路检索链路最朴素的形态就三步embedding化查询、向量检索Top-K、可选重排序。def retrieve(query: str, top_k: int 5): # 查询向量化 query_embedding embeddings.embed_query(query) # 向量检索 docs vectordb.similarity_search_by_vector(query_embedding, ktop_k) # 返回片段列表 return [doc.page_content for doc in docs]真实场景里单靠向量相似度的召回质量往往不够稳定。如果检索结果里有好几个相似但都不完全对路的片段模型的回答会被带偏。所以我在POC里加了一级重排序先用向量检索捞回Top-20再用交叉编码器精排最后取Top-5送进大模型。因为重排序的输入是查询和文档的拼接能捕捉到更深层的语义关系。POC阶段可以牺牲一些速度换取效果毕竟一两个并发的场景多花一两百毫秒完全在可接受范围内。最后一步是拼Prompt。这个环节的模板直接决定模型输出风格。我的推荐模板大概是这样的你是一个企业内部知识助手。请严格依据下面提供的【参考资料】回答用户问题。 如果参考资料中没有明确答案请直接回答根据现有资料无法确认并列出已有的相关线索。 不要在回答中提及参考资料之外的内容。 【参考资料】 1. {retrieved_chunk_1} 2. {retrieved_chunk_2} 3. {retrieved_chunk_3} 【用户问题】 {user_query}注意三个设计点第一要求严格依据参考资料这会显著降低幻觉第二允许模型说不知道而不是强行编造第三在Prompt里明确输出引用来源比如根据文档3业务方看到有出处的答案会更有信心。加一句请用简洁的中文回答也能避免模型长篇大论。3.5 效果评估用30个问题给POC打分效果好不好不能靠感觉。我建议POC一开始就准备一份测试集向业务方收集20~30个真实的、有标准答案的问题这些问题要覆盖不同难度——有的直接能在文档里找到有的需要跨多个章节汇总还有的故意刁钻一点文档里根本没有答案。人工打分用三个维度维度评分标准正确性答案是否与文档内容一致是否有事实错误忠实度是否严格基于参考资料还是自己发挥完整性关键信息是否都覆盖有没有漏点以我的经验POC的效果是否通过看两个阈值正确性平均分3.5/5以上明显幻觉次数不超过2次。前者证明有用后者证明可控。如果这两个指标不达标先从检索着手优化而不是换更大的模型——这句话值得重复三遍。4. 常见问题与排查技巧实录4.1 vLLM部署中的OOM与加载问题我踩过最经典的坑启动vLLM的时候--max-model-len设置得太高比如直接拉到32768结果模型加载时KV Cache直接被分配完报错提示显存不足。后来想明白这个参数不是越大越好它决定了模型最多能记住多长的对话历史而企业内部知识问答的上下文8k完全够用。把--max-model-len从32768降到8192之后显存占用肉眼可见地降了下来。另一个高频问题是模型加载慢。有时候vLLM启动后要等几分钟才能接受第一个请求这不是卡死了而是在做权重加载和图编译。压测的时候务必先发一个请求做预热否则第一个请求的延迟会特别难看。4.2 检索召回质量差的排查路径如果你发现模型答非所问先不要怀疑模型的能力。我的排查顺序是切分粒度把切分后的文本打印出来人工看一眼。如果发现语义被拦腰截断调大chunk_overlap或者改成按标题层级切分。嵌入模型换更强的嵌入模型对比。同样的检索bge-large-zh通常比bge-small-zh好一个档次。查询改写用户原始问题往往口语化比如那个扣款的流程是怎么走的直接用这种口语去检索效果一般。可以先让模型把问题改写成一个适合检索的书面表述再做向量查询。这一步在POC里就能实现显著的提升。重排序加了reranker之后最终结果的精确度有明显改观。如果向量召回的结果里混着很多看起来像但实际无关的片段reranker就是救命稻草。4.3 模型输出的幻觉与失控有段时间我发现模型在回答里喜欢自己补充建议您联系财务部门这类编造出来的信息。问题出在Prompt里的请用简洁的中文回答和请补充相关建议这种开放性指令给了模型发挥空间。我把Prompt限制得更紧加上只根据参考资料回答禁止补充额外信息输出立刻规矩很多。Temperature参数的设定也很微妙POC阶段我习惯设成0.2甚至0.1让模型尽可能保守。如果发现回答重复率极高再把温度往上调一点点。还要注意一点模型日志会记录用户提问和回答内容。如果知识库里有敏感信息部署生产环境时必须把日志脱敏或关闭请求内容回放这在POC阶段就要评估好。4.4 性能和成本的平衡点很多人会问单卡能撑多少并发。实测下来24GB显存跑7B AWQ模型--max-model-len8192时通过vLLM的Continuous Batching20路并发请求的端到端延迟能控制在2到3秒内吞吐量在每秒数百token的量级。这对POC甚至小团队内部使用已经完全够用。如果并发需求再往上走最经济的升级路径不是加显卡而是先做检索层的优化加一层缓存、把高频问题用静态问答兜底、给测试账号限流。等这些手段都用到头再考虑加第二张卡、上多实例负载均衡。关于什么时候该从POC转生产我的判断标准是业务方连续使用两周没有提出这答案不对级别的质疑显存和CPU的占用曲线稳定日常运维不需要研发手动重启。满足这三条就勇敢往生产架构上迁吧。我个人做完这个项目后最大的体会是RAG这类落地方案真正的难点从来不是技术多难而是资源越紧的时候越要把力气花在刀刃上。把检索做好、把Prompt写好、把评估做扎实这比买最贵的卡重要得多。第一次做POC先别想着一口气把架构铺满一台机器、一个开源模型、一个向量库足够证明价值了。如果最开始就把这摊子做大预算和复杂度很容易把项目拖垮。 
长河君 · 2026/10/20 11:46:54 · 阅读 1.2k RAG私有化落地指南：单卡24GB显存跑通企业知识库POC
上周跟一个做企业服务的架构师朋友聊天他提到一个特别典型的场景老板看完大模型项目的报价单脸色当场就变了。动辄几十万的GPU采购、训练集群、算法团队编制加上先跑三个月试试这种话术换谁都肉疼。但业务部门又天天催能不能用大模型把我们那几千份手册、合同、工单变成可以问答的知识库其实这类诉求用RAG检索增强生成做私有化落地恰恰是最不烧钱、最快见效的一条路。我本人就带着团队从零预算起步在一台24GB显存的机器上完成了整个POC最后平稳过渡到vLLM推理引擎支撑的服务。这篇就把这条路线拆开揉碎讲清楚包括选型逻辑、部署细节、检索链路的搭建还有那些不踩一遍绝对不知道的坑。这篇文章适合谁如果你是技术负责人、架构师或者正准备给内部做AI落地的工程师手里预算有限但需要先跑通一个效果可验证的POC那下面这些内容可以直接抄作业。1. 先想清楚RAG的POC到底要验证什么1.1 RAG机制的最简解读很多人第一次接触RAG容易被向量化语义相似度重排序这些词唬住。说破了一层窗户纸RAG就是先在自己的知识库里做搜索搜出最相关的几段文字然后把这几段文字和用户的问题拼在一起交给大模型让它根据给定资料回答。关键点在于模型本身的参数一点都不改。它的优势和价值在于一种工程手段——利用外部知识库给模型开卷考试。企业内部的知识每天都在变、合同每周都在签、产品文档下个季度就更新如果用微调的方式同步这些变化成本不堪设想而RAG只需要把新文档切成碎片、算成向量、丢进向量库就完事了。1.2 验证目标的排序效果、成本、安全我在做POC之前习惯先把验证目标按优先级排个序否则很容易被细节带偏。对于大多数企业场景顺序应该是这样的效果给定文档片段模型能不能答对拒绝率不知道就说不知道高不高引用是否真实成本在可接受的响应延迟下一台机器能支撑多少并发单位请求成本是多少安全数据全程不出内网模型权重从哪来日志会不会记录敏感内容。可运维性模型怎么更新向量库怎么重建服务挂了怎么拉起来。POC阶段最忌讳一上来就追求上线级的可靠性。你可以接受服务偶尔重启但不能接受答非所问你可以接受并发只有个位数但不能接受显存直接溢出。1.3 为什么RAG而不是微调这个问题基本每一个决策者都会问。我给一个判断标准如果你的核心诉求是让模型掌握某种特定格式和语气比如客服话术、特定行业文风微调可能值得做但如果诉求是让模型知道那些只有你们公司才有的知识RAG是绝对的首选。还有一个更实际的理由微调需要构造大量高质量的输入-输出训练对这本身就是一个需要标注团队、需要数据清洗流程的工程。而RAG的准备流程简单得多——文档切一切、向量化、入库。如果效果不好不需要重新训练调调参数就可以了。这个快和便宜是POC阶段最宝贵的特性。2. 从零起步的选型模型、引擎、向量库2.1 基座模型怎么选7B到14B就够用很多团队一上来就想跑70B的大模型但POC阶段完全没必要。以目前的量化方案和推理引擎7B~14B这个档位的模型在多数企业内部知识问答场景已经够用中文表现也很成熟。我的推荐表是这样的模型档位推荐选项显存要求量化后适用场景7B量级Qwen2.5-7B-InstructAWQ量化6~8GB大多数中文知识问答性价比最高14B量级Qwen2.5-14B-InstructAWQ量化12~16GB需要更强推理能力的场景比如多跳问答8B量级Llama 3.1 8B Instruct6~8GB英文场景为主32B暂不建议POC阶段尝试需要24GB以上多卡或大显存确定小模型效果不够时再升级我的真实感受是很多业务问题的难点根本不在模型聪明不聪明而在有没有把正确的资料送到模型嘴边。只要检索做得够好7B模型的表现已经能让业务方点头。2.2 推理引擎的抉择为什么锁死vLLMPOC阶段如果直接裸用transformers库加载模型做推理也可以跑通但你会很快撞到几堵墙并发一上来显存瞬间爆掉每个请求都要等前面的生成完吞吐量低到让人怀疑人生。vLLM凭借两个核心技术解决了这些问题PagedAttention通过类似操作系统中虚拟内存的分页机制把KV Cache切块管理显存利用率大幅提升Continuous Batching允许新请求在旧请求生成间隙插入并发处理效率高出一个数量级。再加上它与主流API协议兼容意味着你后续接业务系统时可以像调云服务一样调内网服务SDK换一下URL就行。我还遇到过一种情况有团队用了FastAPI裸调模型延迟看起来还行但一旦加上多路并发的压测直接崩掉。换上vLLM之后同样的单卡吞吐量翻了好几倍。所以我的建议是从一开始就不要走弯路POC第一课就是先把vLLM跑起来。2.3 嵌入模型和向量库尽量轻装上阵嵌入模型的选择容易被忽视但它决定了检索质量的天花板。我的建议是中文场景直接用BGE系列如bge-large-zh-v1.5效果稳定且有配套的查询指令前缀如果某些文档是英文为主可以考虑bge-base-en或BGE-M3多语言版本。嵌入维度通常1024单文档向量化的成本很低POC阶段完全不敏感。向量库的选择更简单不要一上来就上Elasticsearch、Milvus这些重组件。POC阶段用Chroma或FAISS就够。Chroma非常适合快速验证Python环境下十分钟就能搭起来支持持久化FAISS更轻量、检索速度更快适合纯向量检索场景。等POC跑通了再根据生产需求评估是否引入更重型的向量数据库不迟。2.4 成本阶梯从$0到私有化的四个阶段整个过程我总结成四个阶梯每一级都有明确的成本标志阶段硬件要求技术栈单次请求成本估算L0纯验证任何一台普通笔记本CPU用API也好用最小模型也好先验证流程可忽略L1本地小模型无显卡也行但要能跑7B量化vLLM CPU版或低量化模型几分钱级别L2单卡私有化一张24GB显卡如RTX 4090或等显存专业卡vLLM 7B/14B AWQ BGE Chroma/FAISS按电费折算成本极低L3多卡生产化多张加速卡 高可用架构vLLM集群 正式向量库 监控链路视并发绝大多数企业的POC不需要越过L2。等到业务方、决策者都认可效果之后再往L3走那时候采购预算也容易批得多。3. 一台24GB显卡机器上完整跑通POC3.1 环境准备Conda、CUDA、vLLM安装我习惯先装好CUDA驱动然后创建一个干净的环境。vLLM对Python版本有要求用Python 3.10是稳妥选择。基础安装命令如下conda create -n rag-poc python3.10 -y conda activate rag-poc # 安装vLLM会自动拉取匹配的torch版本 pip install vllm # 如果显卡较老需要单独确认CUDA兼容 nvidia-smi安装过程中最容易出问题的是torch版本与CUDA版本的匹配。强烈建议不要在机器上预先装一个特定的torch再让vLLM去适配它——让pip自己解析依赖成功率更高。第一次启动时会下载模型权重务必确认网络能访问模型仓库。3.2 拉起vLLM推理服务一条命令就能拉起完整的OpenAI兼容服务。我以Qwen2.5-7B-Instruct的AWQ量化版为例vllm serve Qwen/Qwen2.5-7B-Instruct-AWQ \ --max-model-len 8192 \ --gpu-memory-utilization 0.85 \ --quantization awq \ --port 8000参数解释一下--max-model-len 8192限制最大上下文长度这一步特别关键因为上下文长度的增大会直接推高显存占用--gpu-memory-utilization 0.85允许vLLM使用最多85%的显存留出一部分余量给嵌入模型和重排序模型。等一下这里有个我自己踩过的坑如果机器上还需要同时跑嵌入模型要给它留出显存。我吃过一次亏把所有显存都丢给vLLM结果向量化的时候直接CUDA OOM。后来把vLLM的显存利用率调到0.75嵌入模型用CPU推理问题才算解决。嵌入模型本身很轻量CPU推理速度足够支撑POC。启动完成后先验证一下服务是否正常curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Qwen/Qwen2.5-7B-Instruct-AWQ, messages: [{role: user, content: 你好请简单自我介绍}], temperature: 0.2 }看到正常返回就意味着推理引擎已经就位。接下来看指标/metrics端点暴露了Prometheus格式的性能数据重点看avg_generation_throughput这个数字就是每秒生成的token数。3.3 知识库的切分与向量化处理企业内部文档时我强烈推荐先有一个脏活累活的心理预期。文档解析是最容易忽略的环节PDF里的扫描件要先OCRWord表格要特殊处理PPT的文字要按页提取。POC阶段不用做得很完美但至少要保证文本提取不出现大段错乱。切分策略我建议先跑一个固定方案用LangChain的递归字符切分器chunk_size取512chunk_overlap取64。这里的思路是太小了语义被截断太大了检索精度下降512对大多数说明文和合同条款是起步点。后续根据效果再调。向量化和入库的示例代码用Chroma做持久化from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter # 1. 加载并切分文档 loader PyPDFLoader(example.pdf) docs loader.load() splitter RecursiveCharacterTextSplitter( chunk_size512, chunk_overlap64, separators[\n\n, \n, 。, , , ] ) chunks splitter.split_documents(docs) # 2. 初始化嵌入模型CPU够用 embeddings HuggingFaceEmbeddings( model_nameBAAI/bge-large-zh-v1.5, model_kwargs{device: cpu} ) # 3. 入库带持久化 vectordb Chroma.from_documents( chunks, embeddings, persist_directory./chroma_store ) vectordb.persist()几个细节我展开说说。separators这个参数列表看起来不起眼但中文场景下顺序特别重要先按段落双换行切再按句子级标点切这样能最大限度保留语义完整性如果直接把放在最前面切出来的碎片会非常碎。另外BGE系列模型在做语义检索时官方建议给查询语句加一个为这个句子生成表示以用于检索相关文章前缀这个前缀在HuggingFaceEmbeddings中可以通过query_instruction参数配置。别小看这个细节加上它检索命中率能提升好几个百分点。3.4 组装检索问答链路检索链路最朴素的形态就三步embedding化查询、向量检索Top-K、可选重排序。def retrieve(query: str, top_k: int 5): # 查询向量化 query_embedding embeddings.embed_query(query) # 向量检索 docs vectordb.similarity_search_by_vector(query_embedding, ktop_k) # 返回片段列表 return [doc.page_content for doc in docs]真实场景里单靠向量相似度的召回质量往往不够稳定。如果检索结果里有好几个相似但都不完全对路的片段模型的回答会被带偏。所以我在POC里加了一级重排序先用向量检索捞回Top-20再用交叉编码器精排最后取Top-5送进大模型。因为重排序的输入是查询和文档的拼接能捕捉到更深层的语义关系。POC阶段可以牺牲一些速度换取效果毕竟一两个并发的场景多花一两百毫秒完全在可接受范围内。最后一步是拼Prompt。这个环节的模板直接决定模型输出风格。我的推荐模板大概是这样的你是一个企业内部知识助手。请严格依据下面提供的【参考资料】回答用户问题。 如果参考资料中没有明确答案请直接回答根据现有资料无法确认并列出已有的相关线索。 不要在回答中提及参考资料之外的内容。 【参考资料】 1. {retrieved_chunk_1} 2. {retrieved_chunk_2} 3. {retrieved_chunk_3} 【用户问题】 {user_query}注意三个设计点第一要求严格依据参考资料这会显著降低幻觉第二允许模型说不知道而不是强行编造第三在Prompt里明确输出引用来源比如根据文档3业务方看到有出处的答案会更有信心。加一句请用简洁的中文回答也能避免模型长篇大论。3.5 效果评估用30个问题给POC打分效果好不好不能靠感觉。我建议POC一开始就准备一份测试集向业务方收集20~30个真实的、有标准答案的问题这些问题要覆盖不同难度——有的直接能在文档里找到有的需要跨多个章节汇总还有的故意刁钻一点文档里根本没有答案。人工打分用三个维度维度评分标准正确性答案是否与文档内容一致是否有事实错误忠实度是否严格基于参考资料还是自己发挥完整性关键信息是否都覆盖有没有漏点以我的经验POC的效果是否通过看两个阈值正确性平均分3.5/5以上明显幻觉次数不超过2次。前者证明有用后者证明可控。如果这两个指标不达标先从检索着手优化而不是换更大的模型——这句话值得重复三遍。4. 常见问题与排查技巧实录4.1 vLLM部署中的OOM与加载问题我踩过最经典的坑启动vLLM的时候--max-model-len设置得太高比如直接拉到32768结果模型加载时KV Cache直接被分配完报错提示显存不足。后来想明白这个参数不是越大越好它决定了模型最多能记住多长的对话历史而企业内部知识问答的上下文8k完全够用。把--max-model-len从32768降到8192之后显存占用肉眼可见地降了下来。另一个高频问题是模型加载慢。有时候vLLM启动后要等几分钟才能接受第一个请求这不是卡死了而是在做权重加载和图编译。压测的时候务必先发一个请求做预热否则第一个请求的延迟会特别难看。4.2 检索召回质量差的排查路径如果你发现模型答非所问先不要怀疑模型的能力。我的排查顺序是切分粒度把切分后的文本打印出来人工看一眼。如果发现语义被拦腰截断调大chunk_overlap或者改成按标题层级切分。嵌入模型换更强的嵌入模型对比。同样的检索bge-large-zh通常比bge-small-zh好一个档次。查询改写用户原始问题往往口语化比如那个扣款的流程是怎么走的直接用这种口语去检索效果一般。可以先让模型把问题改写成一个适合检索的书面表述再做向量查询。这一步在POC里就能实现显著的提升。重排序加了reranker之后最终结果的精确度有明显改观。如果向量召回的结果里混着很多看起来像但实际无关的片段reranker就是救命稻草。4.3 模型输出的幻觉与失控有段时间我发现模型在回答里喜欢自己补充建议您联系财务部门这类编造出来的信息。问题出在Prompt里的请用简洁的中文回答和请补充相关建议这种开放性指令给了模型发挥空间。我把Prompt限制得更紧加上只根据参考资料回答禁止补充额外信息输出立刻规矩很多。Temperature参数的设定也很微妙POC阶段我习惯设成0.2甚至0.1让模型尽可能保守。如果发现回答重复率极高再把温度往上调一点点。还要注意一点模型日志会记录用户提问和回答内容。如果知识库里有敏感信息部署生产环境时必须把日志脱敏或关闭请求内容回放这在POC阶段就要评估好。4.4 性能和成本的平衡点很多人会问单卡能撑多少并发。实测下来24GB显存跑7B AWQ模型--max-model-len8192时通过vLLM的Continuous Batching20路并发请求的端到端延迟能控制在2到3秒内吞吐量在每秒数百token的量级。这对POC甚至小团队内部使用已经完全够用。如果并发需求再往上走最经济的升级路径不是加显卡而是先做检索层的优化加一层缓存、把高频问题用静态问答兜底、给测试账号限流。等这些手段都用到头再考虑加第二张卡、上多实例负载均衡。关于什么时候该从POC转生产我的判断标准是业务方连续使用两周没有提出这答案不对级别的质疑显存和CPU的占用曲线稳定日常运维不需要研发手动重启。满足这三条就勇敢往生产架构上迁吧。我个人做完这个项目后最大的体会是RAG这类落地方案真正的难点从来不是技术多难而是资源越紧的时候越要把力气花在刀刃上。把检索做好、把Prompt写好、把评估做扎实这比买最贵的卡重要得多。第一次做POC先别想着一口气把架构铺满一台机器、一个开源模型、一个向量库足够证明价值了。如果最开始就把这摊子做大预算和复杂度很容易把项目拖垮。