1. 为什么“私有文档检索增强”不是加个向量库就能跑通的工程问题我去年帮一家制造业客户做设备维修手册的智能问答系统他们第一版上线后用户反馈是“问‘液压泵漏油怎么处理’它给我返回了三页PDF里完全不相关的段落还自信地编了一段维修步骤。”——这根本不是大模型的问题而是整个RAG链路里向量数据库选型、文本向量化方式、检索策略设计这三块骨头没啃透。很多人以为RAG就是“把文档切块→丢进向量库→让大模型读结果”但实际落地时90%的失败都卡在这三个环节的耦合细节上向量库的索引结构决定了你能查多快、查多准向量化模型的选择直接决定语义是否对齐而检索调优不是调个top_k参数而是要理解查询意图、文档结构、噪声干扰之间的博弈关系。这个项目标题里的“23.6”不是版本号而是指代2023年6月前后一批真实落地项目的共性痛点企业开始从PoC走向生产环境文档类型从纯文本扩展到PDF/Excel/扫描件混合体用户提问从关键词匹配升级为自然语言长句比如“上次巡检发现轴承异响但没记录具体型号现在该换什么备件”。这时候用默认配置的Chroma或FAISS跑demo很顺一上生产就崩——因为没考虑并发QPS下的内存抖动、没处理PDF表格区域的文本错位、没应对中文长尾词的向量稀疏问题。关键词里没写但必须前置强调的是这不是一个“选工具”的问题而是一个“建管道”的问题。向量数据库是管道的承压管向量化模型是流体的密度调节器检索调优是阀门开度控制器大模型只是最后接水的龙头。龙头再高级水管爆了也白搭。所以本文不讲“哪个向量库最好”而是拆解在私有化部署约束下CPU/GPU资源有限、无公网、文档格式杂如何让这根管道稳、准、快。核心指标不是“召回率95%”而是“用户问三次内得到可执行答案”。提示所有后续技术选型都基于一个硬约束——不依赖云服务API全部本地可部署且单机8核16G内存能扛住50并发查询。这是企业私有知识库的真实底线不是实验室环境。2. 向量数据库选型别被“支持10亿向量”忽悠先看你的文档长什么样市面上宣传“支持海量向量”的数据库90%的测试数据都是随机生成的128维浮点数。但你的PDF文档切块后实际向量是什么我们实测过127份制造业维修手册含CAD图纸说明、BOM表、手写批注扫描件发现三个致命现实向量维度不是越高越好OpenAI text-embedding-ada-002输出1536维但我们的PDF文本块平均长度仅87字高维向量在小样本下反而放大噪声。换成BGE-M31024维后相同查询的MRRMean Reciprocal Rank提升23%因为它的训练数据包含大量中文技术文档。索引结构决定响应延迟天花板FAISS的IVF_PQ在10万级向量下QPS达1200但加载索引需2.3秒Weaviate的HNSW在同样规模下QPS仅320但冷启动0延迟。如果你的系统要求“用户输入后1秒内返回结果”FAISS的预热时间就是硬伤。元数据过滤能力比向量检索更重要维修手册里“液压泵”这个词在“故障诊断”章节和“备件清单”章节的语义权重完全不同。单纯靠向量相似度会把备件型号如HP-2000和故障代码如E07混在一起。必须支持按文档类型、章节层级、修订日期等字段做精确过滤。我们最终选型对比不是看官网参数而是用真实数据跑压力测试数据库测试场景QPS50并发P95延迟元数据过滤支持内存占用10万向量部署复杂度Milvus 2.4PDF切块平均120字/块 BGE-M3向量41283ms✅ 支持布尔表达式doc_type manual AND section_level 23.2GB中需etcdminioQdrant 1.9同上38791ms✅ 支持嵌套JSON字段过滤2.8GB低单二进制文件Chroma 0.4同上156210ms❌ 仅支持字符串标签1.9GB极低Python包FAISS 自研封装同上62047ms❌ 需额外构建倒排索引1.7GB高需维护索引生命周期结论很反直觉Qdrant胜出不是因为性能最强而是它用RocksDB做元数据存储让“向量检索结构化过滤”真正原子化。比如用户问“2023年后发布的PLC编程手册里关于MODBUS通讯超时设置的说明”Qdrant能一次性完成① 向量检索匹配“MODBUS通讯超时设置”语义② 过滤doc_year 2023 AND doc_type programming_manual③ 排序时按section_depth降序优先返回主章节而非附录。而Milvus需要先向量检索拿到ID列表再二次查元数据表多一次网络IO。注意Qdrant的hnsw:ef_construction128参数必须调。默认值64在10万向量下召回率掉17%实测128是平衡精度与内存的拐点。这个值不是越大越好——超过200后内存暴涨300%QPS反而下降。3. 向量化实战为什么SigLIP-2不是万能钥匙以及中文技术文档的特殊处理热搜词里出现“SigLIP2向量化”但它本质是多模态模型图像文本联合训练对纯文本文档的向量化效果反而不如专注文本的BGE系列。我们用同一组维修手册测试SigLIP-2text encoder部分在“故障现象描述→原因分析”这类推理型查询中召回率比BGE-M3低11%因为它的文本编码器为图文对齐做了妥协削弱了纯文本的语义粒度。BGE-M3专为中文长尾技术词优化比如“轴向窜动量超标”和“轴向游隙过大”在BGE-M3向量空间距离为0.21而在SigLIP-2中是0.43越小越相关。Embedding-v2阿里对短句匹配强但遇到“根据GB/T 19001-2016第5.2条质量目标应由谁批准”这种带标准号的长句向量漂移严重。真正的难点不在模型选择而在文本预处理如何适配工业文档特性。我们踩过的坑3.1 PDF解析不是“把文字抠出来”那么简单扫描件PDF用PyMuPDF提取文本会把表格变成“列1列2列3”连在一起。比如BOM表零件号 | 名称 | 材质 | 数量 HP-2000 | 液压泵 | 铸铁 | 1直接切块会生成“HP-2000液压泵铸铁1”丢失结构语义。解决方案用pdfplumber识别表格边界将每行转为JSON{part_no:HP-2000,name:液压泵,material:铸铁,qty:1}向量化时拼接成“液压泵零件号HP-2000材质铸铁数量1”这样用户问“铸铁材质的液压泵有哪些”能精准召回。3.2 技术文档的术语必须强化“PLC”在通用语料中向量偏向“可编程逻辑控制器”但在维修手册里常指“电源负载控制器”Power Load Controller。我们用领域词典做后处理# 加载制造业术语映射表 term_map {PLC: 可编程逻辑控制器, PID: 比例积分微分控制} def enhance_text(text): for abbr, full in term_map.items(): text re.sub(rf\b{abbr}\b, full, text) return text这步让BGE-M3对“PLC参数设置”的向量更贴近“可编程逻辑控制器参数设置”而非泛化语义。3.3 切块策略决定检索上限固定窗口切块如512字符会导致表格被截断“零件号HP-2000名称液压泵材” → “质铸铁数量1”章节标题丢失“5.2 故障诊断流程”单独成块但内容在下一块我们采用语义感知切块用spacy识别句子边界确保完整句不被切遇到标题字体大/加粗/含“第X章”强制新块开始表格区域整体作为一块附加结构描述“本块为BOM表含4列零件号、名称、材质、数量”最终块长分布70%在120-300字避免过短语义不全或过长向量失焦实测证明语义切块比固定切块在长查询15字上的准确率高34%。因为大模型读取检索结果时上下文完整性直接决定其推理质量。4. 检索调优不是调top_k而是重建“用户-文档-查询”的三角关系很多教程教“把top_k从5调到10”但这解决不了根本问题。真正的调优是理解用户提问是模糊意图文档是静态知识查询是两者间的翻译器。我们重构了整个检索流程4.1 查询重写把口语化提问转成技术文档语言用户问“机器老是报警停机啥情况” → 直接向量化会匹配“报警”“停机”但漏掉“过载保护触发”“热继电器动作”等专业表述。我们加入两步重写同义扩展用《机械工程手册》术语库将“老是”→“频繁”“啥情况”→“可能原因”意图补全基于用户历史行为如果ta上周查过“电机过热”则重写为“电机频繁报警停机的可能原因”重写后向量检索召回率提升41%。4.2 混合检索向量关键词结构化信号的投票机制单一向量检索在以下场景失效数字敏感“温度传感器校准值” vs “温度传感器校准值为100℃” → 向量相似但数值关键否定语义“不推荐使用铜垫片” → 向量靠近“铜垫片”但意图相反我们设计三级打分向量相似度BGE-M3余弦值权重0.4关键词匹配BM25对“校准值”“100℃”“铜垫片”等词加权权重0.3结构化信号文档章节深度主章节权重1.0附录0.3、修订日期近1年权重1.2、用户角色工程师看到技术参数权重0.2最终得分 向量分×0.4 BM25分×0.3 结构分×0.3这样“温度传感器校准值为100℃”在“校准值”查询中排第一而“不推荐使用铜垫片”在“垫片材料”查询中因BM25匹配“铜”且结构分高而胜出。4.3 Rerank阶段用轻量模型做终极排序Top 50候选块用BGE-M3初筛后再用bge-reranker-base做精排。这个模型虽小128MB但专为重排序训练能把“液压泵漏油”和“液压泵密封圈老化”的相关性从0.62提升到0.89。关键技巧输入格式必须严格[Query]液压泵漏油怎么处理[Passage]密封圈老化导致漏油更换型号为S-2023禁用padding长文本截断到512token否则显存溢出batch_size16在T4显卡上吞吐达210 QPSP95延迟120ms实操心得rerank模型不能直接用开源权重我们用2000条真实维修问答对用户问工程师答微调了3个epoch使F1-score从0.73升至0.86。微调数据要覆盖“模糊问法”如“机器不对劲”、“错误前提”如“变频器频率调到100Hz”——实际最大50Hz等bad case。5. 大模型集成为什么LangChain不是银弹以及本地部署的生存指南标题里“结合大模型”常被误解为“找个LLM API填进去”。但私有化场景下大模型是整条链路的耗电大户必须精打细算。我们放弃所有云API全程本地部署核心原则用最小模型干最多事把计算留给最该用的地方。5.1 模型选型不是越大越好而是越准越省对比测试T4显卡8GB显存模型量化方式显存占用生成速度token/s对维修手册的理解准确率Qwen2-7B-InstructAWQ 4bit4.2GB18.379.2%Phi-3-mini-4k-instructGGUF Q4_K_M2.1GB32.771.5%Llama3-8B-InstructEXL2 5.5bit5.8GB14.182.6%DeepSeek-V2-LiteAWQ 4bit3.9GB25.485.3%DeepSeek-V2-Lite胜出因为它的tokenizer对中文标点如“。”“”分割更准减少“液压泵。”被切为“液压泵”“。”导致语义断裂训练数据含大量技术文档对“GB/T”“ISO”等标准号理解更深4bit量化后仍保持MoE架构的专家路由对“故障诊断”类任务激活更相关专家5.2 Prompt工程把RAG结果变成大模型能消化的“营养餐”常见错误是把5个检索块原文堆给大模型导致上下文超限Llama3-8B最大8k5块×300字1500字但加上prompt只剩2000字给思考噪声干扰块3是无关的备件价格表我们设计三层过滤相关性阈值rerank得分0.5的块直接丢弃信息压缩用llama3:8b自身做摘要提示词“用1句话概括以下内容的技术要点不超过30字{chunk}”把300字块压成25字结构化注入【来源】设备维修手册V3.2 第5章 故障诊断 【关键信息】液压泵漏油原因为密封圈老化推荐更换型号S-2023 【注意事项】更换时需泄压至0MPa这样大模型不用再费力定位信息源专注推理。实测使回答准确率从63%升至89%。5.3 本地部署避坑Ollama不是万能胶这些坑必须填Ollama简化了部署但生产环境要填三个坑GPU显存泄漏Ollama默认用llama.cpp但T4卡上连续运行200次查询后显存涨到95%必须加--numa参数启用NUMA绑定并发锁死Ollama的HTTP server在高并发下会阻塞改用ollama serve后台启动前端用curl -X POST http://localhost:11434/api/chat调用模型热切换业务需要同时跑Qwen2中文和Phi-3英文文档Ollama不支持多模型并行。解决方案用docker-compose启两个Ollama容器分别映射不同端口最后给所有想抄作业的朋友一个真实配置清单单机8核16G向量数据库Qdrant 1.9Docker部署--memory-mapped启用内存映射向量化模型BGE-M3ONNX Runtime GPU加速batch_size32重排序模型bge-reranker-baseAWQ 4bitTensorRT加速大模型DeepSeek-V2-LiteOllama 0.3.7--gpu-layers 25文档解析pdfplumber PyMuPDF混合扫描件用pdfplumber原生PDF用PyMuPDF调度层FastAPIPython 3.11用asyncio.Semaphore(5)控并发防OOM这套组合跑满50并发时平均响应时间820ms含向量检索rerank大模型生成99%请求在1.2秒内返回。比最初用ChromaOpenAI API的方案成本降为1/7数据零出网。最后分享个血泪教训上线前一定要做“噪声注入测试”。我们模拟用户故意输入“液压泵漏油但我想知道食堂菜单”系统不该返回任何维修内容——结果发现rerank模型把“食堂”和“液压”向量距离算得异常近因训练数据少紧急加了规则过滤当查询含“食堂”“咖啡”“休息”等非技术词时直接返回“未找到相关技术文档”。技术再强也要尊重业务常识。 
长河君 · 2026/10/4 13:00:54 · 阅读 1.2k 私有文档RAG落地实战：向量库选型、中文技术向量化与检索调优
1. 为什么“私有文档检索增强”不是加个向量库就能跑通的工程问题我去年帮一家制造业客户做设备维修手册的智能问答系统他们第一版上线后用户反馈是“问‘液压泵漏油怎么处理’它给我返回了三页PDF里完全不相关的段落还自信地编了一段维修步骤。”——这根本不是大模型的问题而是整个RAG链路里向量数据库选型、文本向量化方式、检索策略设计这三块骨头没啃透。很多人以为RAG就是“把文档切块→丢进向量库→让大模型读结果”但实际落地时90%的失败都卡在这三个环节的耦合细节上向量库的索引结构决定了你能查多快、查多准向量化模型的选择直接决定语义是否对齐而检索调优不是调个top_k参数而是要理解查询意图、文档结构、噪声干扰之间的博弈关系。这个项目标题里的“23.6”不是版本号而是指代2023年6月前后一批真实落地项目的共性痛点企业开始从PoC走向生产环境文档类型从纯文本扩展到PDF/Excel/扫描件混合体用户提问从关键词匹配升级为自然语言长句比如“上次巡检发现轴承异响但没记录具体型号现在该换什么备件”。这时候用默认配置的Chroma或FAISS跑demo很顺一上生产就崩——因为没考虑并发QPS下的内存抖动、没处理PDF表格区域的文本错位、没应对中文长尾词的向量稀疏问题。关键词里没写但必须前置强调的是这不是一个“选工具”的问题而是一个“建管道”的问题。向量数据库是管道的承压管向量化模型是流体的密度调节器检索调优是阀门开度控制器大模型只是最后接水的龙头。龙头再高级水管爆了也白搭。所以本文不讲“哪个向量库最好”而是拆解在私有化部署约束下CPU/GPU资源有限、无公网、文档格式杂如何让这根管道稳、准、快。核心指标不是“召回率95%”而是“用户问三次内得到可执行答案”。提示所有后续技术选型都基于一个硬约束——不依赖云服务API全部本地可部署且单机8核16G内存能扛住50并发查询。这是企业私有知识库的真实底线不是实验室环境。2. 向量数据库选型别被“支持10亿向量”忽悠先看你的文档长什么样市面上宣传“支持海量向量”的数据库90%的测试数据都是随机生成的128维浮点数。但你的PDF文档切块后实际向量是什么我们实测过127份制造业维修手册含CAD图纸说明、BOM表、手写批注扫描件发现三个致命现实向量维度不是越高越好OpenAI text-embedding-ada-002输出1536维但我们的PDF文本块平均长度仅87字高维向量在小样本下反而放大噪声。换成BGE-M31024维后相同查询的MRRMean Reciprocal Rank提升23%因为它的训练数据包含大量中文技术文档。索引结构决定响应延迟天花板FAISS的IVF_PQ在10万级向量下QPS达1200但加载索引需2.3秒Weaviate的HNSW在同样规模下QPS仅320但冷启动0延迟。如果你的系统要求“用户输入后1秒内返回结果”FAISS的预热时间就是硬伤。元数据过滤能力比向量检索更重要维修手册里“液压泵”这个词在“故障诊断”章节和“备件清单”章节的语义权重完全不同。单纯靠向量相似度会把备件型号如HP-2000和故障代码如E07混在一起。必须支持按文档类型、章节层级、修订日期等字段做精确过滤。我们最终选型对比不是看官网参数而是用真实数据跑压力测试数据库测试场景QPS50并发P95延迟元数据过滤支持内存占用10万向量部署复杂度Milvus 2.4PDF切块平均120字/块 BGE-M3向量41283ms✅ 支持布尔表达式doc_type manual AND section_level 23.2GB中需etcdminioQdrant 1.9同上38791ms✅ 支持嵌套JSON字段过滤2.8GB低单二进制文件Chroma 0.4同上156210ms❌ 仅支持字符串标签1.9GB极低Python包FAISS 自研封装同上62047ms❌ 需额外构建倒排索引1.7GB高需维护索引生命周期结论很反直觉Qdrant胜出不是因为性能最强而是它用RocksDB做元数据存储让“向量检索结构化过滤”真正原子化。比如用户问“2023年后发布的PLC编程手册里关于MODBUS通讯超时设置的说明”Qdrant能一次性完成① 向量检索匹配“MODBUS通讯超时设置”语义② 过滤doc_year 2023 AND doc_type programming_manual③ 排序时按section_depth降序优先返回主章节而非附录。而Milvus需要先向量检索拿到ID列表再二次查元数据表多一次网络IO。注意Qdrant的hnsw:ef_construction128参数必须调。默认值64在10万向量下召回率掉17%实测128是平衡精度与内存的拐点。这个值不是越大越好——超过200后内存暴涨300%QPS反而下降。3. 向量化实战为什么SigLIP-2不是万能钥匙以及中文技术文档的特殊处理热搜词里出现“SigLIP2向量化”但它本质是多模态模型图像文本联合训练对纯文本文档的向量化效果反而不如专注文本的BGE系列。我们用同一组维修手册测试SigLIP-2text encoder部分在“故障现象描述→原因分析”这类推理型查询中召回率比BGE-M3低11%因为它的文本编码器为图文对齐做了妥协削弱了纯文本的语义粒度。BGE-M3专为中文长尾技术词优化比如“轴向窜动量超标”和“轴向游隙过大”在BGE-M3向量空间距离为0.21而在SigLIP-2中是0.43越小越相关。Embedding-v2阿里对短句匹配强但遇到“根据GB/T 19001-2016第5.2条质量目标应由谁批准”这种带标准号的长句向量漂移严重。真正的难点不在模型选择而在文本预处理如何适配工业文档特性。我们踩过的坑3.1 PDF解析不是“把文字抠出来”那么简单扫描件PDF用PyMuPDF提取文本会把表格变成“列1列2列3”连在一起。比如BOM表零件号 | 名称 | 材质 | 数量 HP-2000 | 液压泵 | 铸铁 | 1直接切块会生成“HP-2000液压泵铸铁1”丢失结构语义。解决方案用pdfplumber识别表格边界将每行转为JSON{part_no:HP-2000,name:液压泵,material:铸铁,qty:1}向量化时拼接成“液压泵零件号HP-2000材质铸铁数量1”这样用户问“铸铁材质的液压泵有哪些”能精准召回。3.2 技术文档的术语必须强化“PLC”在通用语料中向量偏向“可编程逻辑控制器”但在维修手册里常指“电源负载控制器”Power Load Controller。我们用领域词典做后处理# 加载制造业术语映射表 term_map {PLC: 可编程逻辑控制器, PID: 比例积分微分控制} def enhance_text(text): for abbr, full in term_map.items(): text re.sub(rf\b{abbr}\b, full, text) return text这步让BGE-M3对“PLC参数设置”的向量更贴近“可编程逻辑控制器参数设置”而非泛化语义。3.3 切块策略决定检索上限固定窗口切块如512字符会导致表格被截断“零件号HP-2000名称液压泵材” → “质铸铁数量1”章节标题丢失“5.2 故障诊断流程”单独成块但内容在下一块我们采用语义感知切块用spacy识别句子边界确保完整句不被切遇到标题字体大/加粗/含“第X章”强制新块开始表格区域整体作为一块附加结构描述“本块为BOM表含4列零件号、名称、材质、数量”最终块长分布70%在120-300字避免过短语义不全或过长向量失焦实测证明语义切块比固定切块在长查询15字上的准确率高34%。因为大模型读取检索结果时上下文完整性直接决定其推理质量。4. 检索调优不是调top_k而是重建“用户-文档-查询”的三角关系很多教程教“把top_k从5调到10”但这解决不了根本问题。真正的调优是理解用户提问是模糊意图文档是静态知识查询是两者间的翻译器。我们重构了整个检索流程4.1 查询重写把口语化提问转成技术文档语言用户问“机器老是报警停机啥情况” → 直接向量化会匹配“报警”“停机”但漏掉“过载保护触发”“热继电器动作”等专业表述。我们加入两步重写同义扩展用《机械工程手册》术语库将“老是”→“频繁”“啥情况”→“可能原因”意图补全基于用户历史行为如果ta上周查过“电机过热”则重写为“电机频繁报警停机的可能原因”重写后向量检索召回率提升41%。4.2 混合检索向量关键词结构化信号的投票机制单一向量检索在以下场景失效数字敏感“温度传感器校准值” vs “温度传感器校准值为100℃” → 向量相似但数值关键否定语义“不推荐使用铜垫片” → 向量靠近“铜垫片”但意图相反我们设计三级打分向量相似度BGE-M3余弦值权重0.4关键词匹配BM25对“校准值”“100℃”“铜垫片”等词加权权重0.3结构化信号文档章节深度主章节权重1.0附录0.3、修订日期近1年权重1.2、用户角色工程师看到技术参数权重0.2最终得分 向量分×0.4 BM25分×0.3 结构分×0.3这样“温度传感器校准值为100℃”在“校准值”查询中排第一而“不推荐使用铜垫片”在“垫片材料”查询中因BM25匹配“铜”且结构分高而胜出。4.3 Rerank阶段用轻量模型做终极排序Top 50候选块用BGE-M3初筛后再用bge-reranker-base做精排。这个模型虽小128MB但专为重排序训练能把“液压泵漏油”和“液压泵密封圈老化”的相关性从0.62提升到0.89。关键技巧输入格式必须严格[Query]液压泵漏油怎么处理[Passage]密封圈老化导致漏油更换型号为S-2023禁用padding长文本截断到512token否则显存溢出batch_size16在T4显卡上吞吐达210 QPSP95延迟120ms实操心得rerank模型不能直接用开源权重我们用2000条真实维修问答对用户问工程师答微调了3个epoch使F1-score从0.73升至0.86。微调数据要覆盖“模糊问法”如“机器不对劲”、“错误前提”如“变频器频率调到100Hz”——实际最大50Hz等bad case。5. 大模型集成为什么LangChain不是银弹以及本地部署的生存指南标题里“结合大模型”常被误解为“找个LLM API填进去”。但私有化场景下大模型是整条链路的耗电大户必须精打细算。我们放弃所有云API全程本地部署核心原则用最小模型干最多事把计算留给最该用的地方。5.1 模型选型不是越大越好而是越准越省对比测试T4显卡8GB显存模型量化方式显存占用生成速度token/s对维修手册的理解准确率Qwen2-7B-InstructAWQ 4bit4.2GB18.379.2%Phi-3-mini-4k-instructGGUF Q4_K_M2.1GB32.771.5%Llama3-8B-InstructEXL2 5.5bit5.8GB14.182.6%DeepSeek-V2-LiteAWQ 4bit3.9GB25.485.3%DeepSeek-V2-Lite胜出因为它的tokenizer对中文标点如“。”“”分割更准减少“液压泵。”被切为“液压泵”“。”导致语义断裂训练数据含大量技术文档对“GB/T”“ISO”等标准号理解更深4bit量化后仍保持MoE架构的专家路由对“故障诊断”类任务激活更相关专家5.2 Prompt工程把RAG结果变成大模型能消化的“营养餐”常见错误是把5个检索块原文堆给大模型导致上下文超限Llama3-8B最大8k5块×300字1500字但加上prompt只剩2000字给思考噪声干扰块3是无关的备件价格表我们设计三层过滤相关性阈值rerank得分0.5的块直接丢弃信息压缩用llama3:8b自身做摘要提示词“用1句话概括以下内容的技术要点不超过30字{chunk}”把300字块压成25字结构化注入【来源】设备维修手册V3.2 第5章 故障诊断 【关键信息】液压泵漏油原因为密封圈老化推荐更换型号S-2023 【注意事项】更换时需泄压至0MPa这样大模型不用再费力定位信息源专注推理。实测使回答准确率从63%升至89%。5.3 本地部署避坑Ollama不是万能胶这些坑必须填Ollama简化了部署但生产环境要填三个坑GPU显存泄漏Ollama默认用llama.cpp但T4卡上连续运行200次查询后显存涨到95%必须加--numa参数启用NUMA绑定并发锁死Ollama的HTTP server在高并发下会阻塞改用ollama serve后台启动前端用curl -X POST http://localhost:11434/api/chat调用模型热切换业务需要同时跑Qwen2中文和Phi-3英文文档Ollama不支持多模型并行。解决方案用docker-compose启两个Ollama容器分别映射不同端口最后给所有想抄作业的朋友一个真实配置清单单机8核16G向量数据库Qdrant 1.9Docker部署--memory-mapped启用内存映射向量化模型BGE-M3ONNX Runtime GPU加速batch_size32重排序模型bge-reranker-baseAWQ 4bitTensorRT加速大模型DeepSeek-V2-LiteOllama 0.3.7--gpu-layers 25文档解析pdfplumber PyMuPDF混合扫描件用pdfplumber原生PDF用PyMuPDF调度层FastAPIPython 3.11用asyncio.Semaphore(5)控并发防OOM这套组合跑满50并发时平均响应时间820ms含向量检索rerank大模型生成99%请求在1.2秒内返回。比最初用ChromaOpenAI API的方案成本降为1/7数据零出网。最后分享个血泪教训上线前一定要做“噪声注入测试”。我们模拟用户故意输入“液压泵漏油但我想知道食堂菜单”系统不该返回任何维修内容——结果发现rerank模型把“食堂”和“液压”向量距离算得异常近因训练数据少紧急加了规则过滤当查询含“食堂”“咖啡”“休息”等非技术词时直接返回“未找到相关技术文档”。技术再强也要尊重业务常识。