尧图网站建设 
简介这份PDF文档面向具备一定编程与机器学习基础的技术开发人员聚焦DeepSeek私有化部署场景下的领域数据训练问题帮助读者将通用大模型调教为适配医疗、金融、法律等垂直业务的专用模型。文档共28页以PDF单文件形式打包压缩包约1.78MB内容完整、目录与图表显示正常可放心查阅。目前已有120人学习关注。内容从DeepSeek模型概述与主要特性切入依次覆盖本地文件准备中的数据收集、格式转换、标注与清洗预处理私有化部署的环境准备、模型下载、配置与服务启动验证领域数据处理中的筛选、增强、划分与格式化以及学习率、批次大小、训练轮数、正则化等参数调优方法并给出模型评估指标、交叉验证与优化迭代思路最后附常见问题解决方案及医疗、金融两个完整案例分析便于读者按章节系统学习并落地实践。1. 本地文件调教 DeepSeek私有化部署里最容易被低估的一环很多团队把 DeepSeek 私有化部署跑通之后第一反应是「模型上线了」结果一接业务就翻车问公司内部的报销标准它给你编一个问产品手册里的参数它答得头头是道但全是幻觉。问题往往不在模型本身而在喂进去的本地文件根本没被「调教」过。所谓本地文件调教指的是把企业自己的 PDF、Word、Excel、Markdown 这类私有语料经过清洗、切分、向量化、检索增强或微调变成模型能稳定调用的领域知识。它解决的是「通用大模型不懂你公司黑话」这件事适合已经完成 DeepSeek 本地部署、手里有一堆内部文档、想让知识库问答或私有化 Agent 真正可用的工程师。这一章先把这件事的边界讲清楚后面几章再落到具体怎么做、参数怎么设、坑在哪。2. 领域数据训练的三条路线RAG、微调、继续预训练怎么选在动手之前得先想清楚一件事你手里的本地文件到底该走哪条路喂给 DeepSeek。常见做法有三条——检索增强生成RAG、监督微调SFT、继续预训练CPT。选错了要么效果上不去要么成本翻十倍。这一章把三条路线的适用边界、成本结构和落地步骤拆开讲让你在动手前就能判断自己该走哪条。2.1 三条路线的适用边界与成本对比RAG 的本质是「不改模型改输入」。把本地文件切块、向量化存进向量库用户提问时先检索出相关片段拼进 prompt 再让 DeepSeek 回答。它的优势是数据更新快、可溯源、幻觉相对可控缺点是受限于检索质量跨文档推理能力弱。SFT 是拿「问题-答案」对去微调模型权重让模型学会你领域的回答风格和知识适合问答格式固定、有标注数据的场景。CPT 则是拿大量领域文本继续预训练让模型「泡」在你的语料里成本最高一般只有语料量到千万 token 级别、且领域和通用语料差异极大时才考虑。路线数据量门槛典型成本更新速度适合场景RAG几十篇起低主要是向量库和推理分钟级知识库问答、文档助手SFT几千条问答对中需要 GPU 微调天级固定格式客服、工单分类CPT千万 token 起高多卡长时间训练周级垂直行业大模型对绝大多数企业来说RAG 是性价比最高的起点。我一般会建议先用 RAG 跑通闭环等发现检索解决不了的问题再考虑 SFT 补刀。下面两节分别给出 RAG 和 SFT 的最小可复现步骤。2.2 用 RAG 把本地 PDF 接进 DeepSeek 的最小流程先装依赖。这里用langchain做文档加载和切分chromadb做向量库sentence-transformers做 embedding。DeepSeek 的推理走本地部署的 OpenAI 兼容接口。pip install langchain langchain-community chromadb sentence-transformers pypdf openai然后是核心脚本。注意切分参数和检索条数是两个最影响效果的地方。from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.vectorstores import Chroma from langchain_community.embeddings import HuggingFaceEmbeddings from openai import OpenAI # 1. 加载本地 PDF支持多文件 loader PyPDFLoader(./docs/员工手册.pdf) docs loader.load() # 2. 切分chunk_size 控制单块长度overlap 保证跨块语义不断 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , , ] ) chunks splitter.split_documents(docs) # 3. 向量化并入库embedding 模型选中文效果好的 embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) vectordb Chroma.from_documents(chunks, embeddings, persist_directory./chroma_db) # 4. 检索 拼 prompt 调 DeepSeek client OpenAI(base_urlhttp://localhost:8000/v1, api_keynot-needed) query 年假怎么计算 retrieved vectordb.similarity_search(query, k4) context \n\n.join([d.page_content for d in retrieved]) resp client.chat.completions.create( modeldeepseek, messages[ {role: system, content: 只根据以下资料回答资料没有就说不知道。\n context}, {role: user, content: query} ], temperature0.1 ) print(resp.choices[0].message.content)逻辑说明chunk_size500是中文文档的经验值太小会丢上下文太大检索精度下降chunk_overlap80保证句子被切断时语义还在。k4是检索条数文档密集时可以调到 6但要注意 prompt 长度。temperature0.1是为了压制幻觉知识库问答不需要创造性。system prompt 里那句「资料没有就说不知道」是后悔药能挡掉大部分编造。2.3 SFT 微调的数据准备与 LoRA 参数当你发现 RAG 检索不到、但模型其实「应该会」的问题就该上 SFT 了。数据格式一般是 JSONL每行一条{instruction: ..., input: ..., output: ...}。数据质量比数量重要几千条干净数据往往胜过几万条噪声。from datasets import load_dataset from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from peft import LoraConfig, get_peft_model from trl import SFTTrainer dataset load_dataset(json, data_filestrain.jsonl, splittrain) tokenizer AutoTokenizer.from_pretrained(./deepseek-base) model AutoModelForCausalLM.from_pretrained(./deepseek-base, device_mapauto) # LoRA 只训练低秩矩阵显存占用大幅下降 lora_config LoraConfig( r16, # 秩越大容量越强但越容易过拟合 lora_alpha32, # 缩放系数一般取 r 的 2 倍 target_modules[q_proj, v_proj], lora_dropout0.05, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) args TrainingArguments( output_dir./lora-out, per_device_train_batch_size2, gradient_accumulation_steps8, learning_rate2e-4, num_train_epochs3, logging_steps10, save_strategyepoch ) trainer SFTTrainer(modelmodel, argsargs, train_datasetdataset, tokenizertokenizer) trainer.train()参数说明r16是 LoRA 秩领域知识注入一般 8 到 32 够用lora_alpha取r的两倍是常见起点target_modules只挂 attention 的 q、v 投影显存紧张时可以只挂 q。learning_rate2e-4是 LoRA 的常用值比全量微调高一个量级。gradient_accumulation_steps8配合 batch_size2等效 batch 是 16显存不够就靠它凑。3. 本地文件预处理清洗、切分、去重的实操细节上一章讲了路线这一章专门啃本地文件本身。很多人 RAG 效果差根因不在检索而在文件根本没洗干净。PDF 里的页眉页脚、Word 里的修订痕迹、Excel 里的合并单元格都会变成噪声喂给模型。这一章把预处理拆成清洗、切分、去重三步每步给出可抄的代码和判断标准。3.1 PDF 与 Word 的清洗去掉页眉页脚和乱码PDF 提取出来最常见的噪声是重复页眉、页码、断行。清洗的核心思路是「按行统计频次高频短行大概率是页眉页脚」。import re from collections import Counter def clean_pdf_text(raw_text): lines raw_text.split(\n) # 统计出现次数出现超过 3 次且长度小于 20 的行判为页眉页脚 counter Counter([l.strip() for l in lines if l.strip()]) noise {l for l, c in counter.items() if c 3 and len(l) 20} cleaned [] for line in lines: s line.strip() if not s or s in noise: continue # 去掉纯页码 if re.fullmatch(r[-—\s]*\d[-—\s]*, s): continue cleaned.append(s) # 合并被 PDF 硬断开的行上一行不以句号结尾且下一行不以大写/数字开头 text for i, line in enumerate(cleaned): text line if i len(cleaned) - 1 and not re.search(r[。]$, line): continue text \n return text逻辑说明counter统计的是整篇文档的行频次页眉页脚天然高频。len(l) 20是为了避免把正文里的短句误删。断行合并那段是关键PDF 经常把一句话拆成两行不合并的话切分时会切断语义。Word 文档相对干净但要注意去掉批注和修订用python-docx读取时只取paragraph.text即可。3.2 切分策略按语义切还是按长度切切分是 RAG 里最玄学的环节。按固定长度切简单但会切断语义按语义切效果好但实现复杂。我的经验是结构化文档手册、规范按标题层级切非结构化文档聊天记录、会议纪要按长度加重叠切。def split_by_heading(text, max_len800): # 按 Markdown 标题或中文数字标题切分 pattern r(?^#{1,3}\s|^[一二三四五六七八九十]、) sections re.split(pattern, text, flagsre.MULTILINE) chunks [] for sec in sections: sec sec.strip() if not sec: continue if len(sec) max_len: chunks.append(sec) else: # 超长段落再按句号二次切分 sentences re.split(r(?[。]), sec) buf for s in sentences: if len(buf) len(s) max_len: chunks.append(buf) buf s else: buf s if buf: chunks.append(buf) return chunks参数说明max_len800是中文语义块的舒适区超过这个长度检索精度会掉。pattern里的^#{1,3}适配 Markdown^[一二三四五六七八九十]、适配中文编号标题。二次切分用(?[。])是零宽断言保留句号在句尾不会把标点切掉。3.3 去重MinHash 快速干掉重复段落企业文档里重复内容极多同一段话在多个文件里出现检索时会挤占名额。用 MinHash 做近似去重比精确匹配实用。from datasketch import MinHash, MinHashLSH def dedup(chunks, threshold0.8): lsh MinHashLSH(thresholdthreshold, num_perm128) kept [] for i, chunk in enumerate(chunks): m MinHash(num_perm128) for token in set(chunk): m.update(token.encode(utf8)) if not lsh.query(m): lsh.insert(str(i), m) kept.append(chunk) return kept逻辑说明num_perm128是哈希函数个数越大越准但越慢128 是常用平衡点。threshold0.8表示相似度超过 80% 判为重复。MinHash 对长文本效果好短句可能误判所以切分后再去重比整篇去重更稳。4. 检索质量调优embedding、重排与混合检索RAG 的上限由检索决定。模型再强检索回来的片段不相关回答就是错的。这一章讲三个提升检索质量的手段换 embedding 模型、加重排、混合检索。每个都给出可对比的配置让你知道什么时候该上哪个。4.1 embedding 模型选型中文场景别用英文模型embedding 模型决定了「语义相近」的判断准不准。中文场景下BAAI/bge系列和m3e系列是常见选择英文模型如all-MiniLM在中文上会明显掉点。from sentence_transformers import SentenceTransformer # 对比两个模型在同一 query 上的检索差异 models { bge-small-zh: BAAI/bge-small-zh-v1.5, m3e-base: moka-ai/m3e-base } for name, path in models.items(): model SentenceTransformer(path) q model.encode(报销流程是什么) d1 model.encode(员工费用报销需要提交发票) d2 model.encode(今天天气不错) import numpy as np sim1 np.dot(q, d1) / (np.linalg.norm(q) * np.linalg.norm(d1)) sim2 np.dot(q, d2) / (np.linalg.norm(q) * np.linalg.norm(d2)) print(f{name}: 相关{sim1:.3f}, 无关{sim2:.3f})参数说明bge-small-zh维度 512速度快适合百万级以下文档m3e-base维度 768效果略好但慢。选型时看「相关-无关」的差值差值越大区分度越好。一般差值在 0.2 以上算可用。4.2 加重排用 cross-encoder 把 top50 精排到 top5向量检索是「粗排」召回快但精度有限。加一层 cross-encoder 重排把检索回来的 top50 重新打分取 top5 喂给模型效果提升明显。from sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-base) def retrieve_with_rerank(query, vectordb, top_k50, final_k5): # 粗排召回 candidates vectordb.similarity_search(query, ktop_k) # 精排打分 pairs [(query, doc.page_content) for doc in candidates] scores reranker.predict(pairs) # 按分数排序取前 final_k ranked sorted(zip(candidates, scores), keylambda x: x[1], reverseTrue) return [doc for doc, _ in ranked[:final_k]]逻辑说明top_k50是粗排召回数太小重排没意义太大重排耗时。final_k5是最终喂给模型的片段数配合 prompt 长度调整。cross-encoder 比向量检索慢一个量级所以只用在精排阶段不要拿它做全库检索。4.3 混合检索BM25 补上向量检索的关键词短板向量检索对「专有名词、型号、编号」不敏感比如「XJ-2000 型号的额定功率」向量可能召回一堆泛泛的功率说明。BM25 是关键词检索正好补这个短板。混合检索就是把两路结果加权融合。from rank_bm25 import BM25Okapi import jieba # 构建 BM25 索引 corpus [c.page_content for c in chunks] tokenized [list(jieba.cut(doc)) for doc in corpus] bm25 BM25Okapi(tokenized) def hybrid_search(query, vectordb, alpha0.5, k5): # 向量路 vec_results vectordb.similarity_search_with_score(query, k20) # BM25 路 bm25_scores bm25.get_scores(list(jieba.cut(query))) bm25_top sorted(range(len(bm25_scores)), keylambda i: bm25_scores[i], reverseTrue)[:20] # 归一化后加权融合 score_map {} for doc, score in vec_results: score_map[doc.page_content] score_map.get(doc.page_content, 0) alpha * (1 - score) for i in bm25_top: score_map[corpus[i]] score_map.get(corpus[i], 0) (1 - alpha) * bm25_scores[i] ranked sorted(score_map.items(), keylambda x: x[1], reverseTrue) return [text for text, _ in ranked[:k]]参数说明alpha0.5是向量路权重专有名词多的场景调到 0.3 让 BM25 占主导。jieba.cut做中文分词BM25 依赖分词质量领域词典要提前加进去。两路各召回 20 条再融合比单路召回 5 条稳得多。5. 避坑与排查本地文件调教 DeepSeek 的五个血泪教训这一章不讲新东西专门讲我踩过的坑。每一条都是「现象 → 原因 → 解决」的结构你照着排查能省不少时间。5.1 检索到了但模型不用prompt 里 context 位置放错现象检索回来的片段明明包含答案模型却回答「资料中没有」。原因context 放在 system prompt 里且被长指令挤到后面模型注意力没落在上面。解决把 context 放在 user message 里且用明确分隔符包起来比如【资料开始】...【资料结束】并在 system 里强调「优先使用资料中的内容」。5.2 中文 PDF 提取全是乱码编码和字体映射问题现象PyPDFLoader提取出来的中文是\uXXXX或方块。原因PDF 内嵌字体没有 ToUnicode 映射提取工具拿不到字符编码。解决换pdfplumber或pymupdf试两者对字体映射的处理不同都不行就用 OCR 兜底paddleocr对中文 PDF 识别率不错。5.3 微调后模型变傻灾难性遗忘现象SFT 之后领域问题答得好了但通用对话能力明显下降。原因学习率太高或训练轮数太多模型把通用能力覆盖了。解决降learning_rate到 1e-4num_train_epochs降到 1 到 2LoRA 的r别超过 32并在训练数据里混入 10% 到 20% 的通用语料。5.4 向量库越查越慢没建索引现象文档量到十万级后检索从毫秒变成秒级。原因Chroma 默认暴力检索没建 ANN 索引。解决切换到支持 HNSW 索引的向量库或在 Chroma 里配置hnsw:space参数。数据量再大就上 Milvus 或 Qdrant。5.5 同一问题两次回答不一样temperature 和检索不稳定现象同一个问题两次回答内容差异大。原因temperature设太高或检索的 top_k 结果每次略有不同。解决知识库问答把temperature压到 0.1 以下检索结果做缓存相同 query 直接返回缓存片段。6. 进阶技巧用查询改写和自查询把召回率再提一档前面几章把基础流程跑通了这一章讲两个进阶技巧能让召回率再上一个台阶。第一个是查询改写用户问「年假」文档里写的是「带薪年休假」字面不匹配但语义相同向量检索可能漏掉。做法是先用 DeepSeek 把用户 query 改写成多个同义表达分别检索再合并。def rewrite_query(query, client): prompt f把下面的问题改写成3个语义相同但用词不同的查询每行一个不要编号\n{query} resp client.chat.completions.create( modeldeepseek, messages[{role: user, content: prompt}], temperature0.3 ) return [q.strip() for q in resp.choices[0].message.content.split(\n) if q.strip()] def multi_query_retrieve(query, vectordb, client, k5): queries [query] rewrite_query(query, client) all_docs {} for q in queries: for doc in vectordb.similarity_search(q, kk): all_docs[doc.page_content] all_docs.get(doc.page_content, 0) 1 # 出现次数多的片段优先 ranked sorted(all_docs.items(), keylambda x: x[1], reverseTrue) return [text for text, _ in ranked[:k]]逻辑说明temperature0.3让改写有变化但不发散。多路检索后按「被命中次数」排序命中越多说明越相关。这个技巧对同义词多的领域特别有效代价是多几次检索和一次改写调用。第二个技巧是自查询self-query让模型从用户问题里抽出过滤条件。比如「2023 年之后的报销政策」模型抽出year 2023检索时先按元数据过滤再向量检索精度提升明显。做法是在文档入库时给每个 chunk 打上year、department、doc_type等元数据检索时用 Chroma 的filter参数。# 入库时带元数据 vectordb Chroma.from_documents( chunks, embeddings, metadatas[{year: 2023, dept: 财务} for _ in chunks] ) # 检索时过滤 results vectordb.similarity_search( 报销政策, k5, filter{year: {$gt: 2022}} )元数据的抽取可以半自动文件名带年份的直接解析正文里的日期用正则抽。这一步前期投入大但文档量上去之后收益非常明显。我自己的习惯是每接一批新文档先跑一遍预处理脚本看清洗后的文本再抽 20 个真实问题测召回率低于 80% 就不往下走回头调切分和 embedding。这个习惯帮我省了很多「上线后才发现检索不行」的返工。希望帮到你。本文还有配套的精品资源点击获取 DeepSeek私有化部署：本地文件调教与RAG、SFT实战指南
简介这份PDF文档面向具备一定编程与机器学习基础的技术开发人员聚焦DeepSeek私有化部署场景下的领域数据训练问题帮助读者将通用大模型调教为适配医疗、金融、法律等垂直业务的专用模型。文档共28页以PDF单文件形式打包压缩包约1.78MB内容完整、目录与图表显示正常可放心查阅。目前已有120人学习关注。内容从DeepSeek模型概述与主要特性切入依次覆盖本地文件准备中的数据收集、格式转换、标注与清洗预处理私有化部署的环境准备、模型下载、配置与服务启动验证领域数据处理中的筛选、增强、划分与格式化以及学习率、批次大小、训练轮数、正则化等参数调优方法并给出模型评估指标、交叉验证与优化迭代思路最后附常见问题解决方案及医疗、金融两个完整案例分析便于读者按章节系统学习并落地实践。1. 本地文件调教 DeepSeek私有化部署里最容易被低估的一环很多团队把 DeepSeek 私有化部署跑通之后第一反应是「模型上线了」结果一接业务就翻车问公司内部的报销标准它给你编一个问产品手册里的参数它答得头头是道但全是幻觉。问题往往不在模型本身而在喂进去的本地文件根本没被「调教」过。所谓本地文件调教指的是把企业自己的 PDF、Word、Excel、Markdown 这类私有语料经过清洗、切分、向量化、检索增强或微调变成模型能稳定调用的领域知识。它解决的是「通用大模型不懂你公司黑话」这件事适合已经完成 DeepSeek 本地部署、手里有一堆内部文档、想让知识库问答或私有化 Agent 真正可用的工程师。这一章先把这件事的边界讲清楚后面几章再落到具体怎么做、参数怎么设、坑在哪。2. 领域数据训练的三条路线RAG、微调、继续预训练怎么选在动手之前得先想清楚一件事你手里的本地文件到底该走哪条路喂给 DeepSeek。常见做法有三条——检索增强生成RAG、监督微调SFT、继续预训练CPT。选错了要么效果上不去要么成本翻十倍。这一章把三条路线的适用边界、成本结构和落地步骤拆开讲让你在动手前就能判断自己该走哪条。2.1 三条路线的适用边界与成本对比RAG 的本质是「不改模型改输入」。把本地文件切块、向量化存进向量库用户提问时先检索出相关片段拼进 prompt 再让 DeepSeek 回答。它的优势是数据更新快、可溯源、幻觉相对可控缺点是受限于检索质量跨文档推理能力弱。SFT 是拿「问题-答案」对去微调模型权重让模型学会你领域的回答风格和知识适合问答格式固定、有标注数据的场景。CPT 则是拿大量领域文本继续预训练让模型「泡」在你的语料里成本最高一般只有语料量到千万 token 级别、且领域和通用语料差异极大时才考虑。路线数据量门槛典型成本更新速度适合场景RAG几十篇起低主要是向量库和推理分钟级知识库问答、文档助手SFT几千条问答对中需要 GPU 微调天级固定格式客服、工单分类CPT千万 token 起高多卡长时间训练周级垂直行业大模型对绝大多数企业来说RAG 是性价比最高的起点。我一般会建议先用 RAG 跑通闭环等发现检索解决不了的问题再考虑 SFT 补刀。下面两节分别给出 RAG 和 SFT 的最小可复现步骤。2.2 用 RAG 把本地 PDF 接进 DeepSeek 的最小流程先装依赖。这里用langchain做文档加载和切分chromadb做向量库sentence-transformers做 embedding。DeepSeek 的推理走本地部署的 OpenAI 兼容接口。pip install langchain langchain-community chromadb sentence-transformers pypdf openai然后是核心脚本。注意切分参数和检索条数是两个最影响效果的地方。from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.vectorstores import Chroma from langchain_community.embeddings import HuggingFaceEmbeddings from openai import OpenAI # 1. 加载本地 PDF支持多文件 loader PyPDFLoader(./docs/员工手册.pdf) docs loader.load() # 2. 切分chunk_size 控制单块长度overlap 保证跨块语义不断 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , , ] ) chunks splitter.split_documents(docs) # 3. 向量化并入库embedding 模型选中文效果好的 embeddings HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) vectordb Chroma.from_documents(chunks, embeddings, persist_directory./chroma_db) # 4. 检索 拼 prompt 调 DeepSeek client OpenAI(base_urlhttp://localhost:8000/v1, api_keynot-needed) query 年假怎么计算 retrieved vectordb.similarity_search(query, k4) context \n\n.join([d.page_content for d in retrieved]) resp client.chat.completions.create( modeldeepseek, messages[ {role: system, content: 只根据以下资料回答资料没有就说不知道。\n context}, {role: user, content: query} ], temperature0.1 ) print(resp.choices[0].message.content)逻辑说明chunk_size500是中文文档的经验值太小会丢上下文太大检索精度下降chunk_overlap80保证句子被切断时语义还在。k4是检索条数文档密集时可以调到 6但要注意 prompt 长度。temperature0.1是为了压制幻觉知识库问答不需要创造性。system prompt 里那句「资料没有就说不知道」是后悔药能挡掉大部分编造。2.3 SFT 微调的数据准备与 LoRA 参数当你发现 RAG 检索不到、但模型其实「应该会」的问题就该上 SFT 了。数据格式一般是 JSONL每行一条{instruction: ..., input: ..., output: ...}。数据质量比数量重要几千条干净数据往往胜过几万条噪声。from datasets import load_dataset from transformers import AutoModelForCausalLM, AutoTokenizer, TrainingArguments from peft import LoraConfig, get_peft_model from trl import SFTTrainer dataset load_dataset(json, data_filestrain.jsonl, splittrain) tokenizer AutoTokenizer.from_pretrained(./deepseek-base) model AutoModelForCausalLM.from_pretrained(./deepseek-base, device_mapauto) # LoRA 只训练低秩矩阵显存占用大幅下降 lora_config LoraConfig( r16, # 秩越大容量越强但越容易过拟合 lora_alpha32, # 缩放系数一般取 r 的 2 倍 target_modules[q_proj, v_proj], lora_dropout0.05, task_typeCAUSAL_LM ) model get_peft_model(model, lora_config) args TrainingArguments( output_dir./lora-out, per_device_train_batch_size2, gradient_accumulation_steps8, learning_rate2e-4, num_train_epochs3, logging_steps10, save_strategyepoch ) trainer SFTTrainer(modelmodel, argsargs, train_datasetdataset, tokenizertokenizer) trainer.train()参数说明r16是 LoRA 秩领域知识注入一般 8 到 32 够用lora_alpha取r的两倍是常见起点target_modules只挂 attention 的 q、v 投影显存紧张时可以只挂 q。learning_rate2e-4是 LoRA 的常用值比全量微调高一个量级。gradient_accumulation_steps8配合 batch_size2等效 batch 是 16显存不够就靠它凑。3. 本地文件预处理清洗、切分、去重的实操细节上一章讲了路线这一章专门啃本地文件本身。很多人 RAG 效果差根因不在检索而在文件根本没洗干净。PDF 里的页眉页脚、Word 里的修订痕迹、Excel 里的合并单元格都会变成噪声喂给模型。这一章把预处理拆成清洗、切分、去重三步每步给出可抄的代码和判断标准。3.1 PDF 与 Word 的清洗去掉页眉页脚和乱码PDF 提取出来最常见的噪声是重复页眉、页码、断行。清洗的核心思路是「按行统计频次高频短行大概率是页眉页脚」。import re from collections import Counter def clean_pdf_text(raw_text): lines raw_text.split(\n) # 统计出现次数出现超过 3 次且长度小于 20 的行判为页眉页脚 counter Counter([l.strip() for l in lines if l.strip()]) noise {l for l, c in counter.items() if c 3 and len(l) 20} cleaned [] for line in lines: s line.strip() if not s or s in noise: continue # 去掉纯页码 if re.fullmatch(r[-—\s]*\d[-—\s]*, s): continue cleaned.append(s) # 合并被 PDF 硬断开的行上一行不以句号结尾且下一行不以大写/数字开头 text for i, line in enumerate(cleaned): text line if i len(cleaned) - 1 and not re.search(r[。]$, line): continue text \n return text逻辑说明counter统计的是整篇文档的行频次页眉页脚天然高频。len(l) 20是为了避免把正文里的短句误删。断行合并那段是关键PDF 经常把一句话拆成两行不合并的话切分时会切断语义。Word 文档相对干净但要注意去掉批注和修订用python-docx读取时只取paragraph.text即可。3.2 切分策略按语义切还是按长度切切分是 RAG 里最玄学的环节。按固定长度切简单但会切断语义按语义切效果好但实现复杂。我的经验是结构化文档手册、规范按标题层级切非结构化文档聊天记录、会议纪要按长度加重叠切。def split_by_heading(text, max_len800): # 按 Markdown 标题或中文数字标题切分 pattern r(?^#{1,3}\s|^[一二三四五六七八九十]、) sections re.split(pattern, text, flagsre.MULTILINE) chunks [] for sec in sections: sec sec.strip() if not sec: continue if len(sec) max_len: chunks.append(sec) else: # 超长段落再按句号二次切分 sentences re.split(r(?[。]), sec) buf for s in sentences: if len(buf) len(s) max_len: chunks.append(buf) buf s else: buf s if buf: chunks.append(buf) return chunks参数说明max_len800是中文语义块的舒适区超过这个长度检索精度会掉。pattern里的^#{1,3}适配 Markdown^[一二三四五六七八九十]、适配中文编号标题。二次切分用(?[。])是零宽断言保留句号在句尾不会把标点切掉。3.3 去重MinHash 快速干掉重复段落企业文档里重复内容极多同一段话在多个文件里出现检索时会挤占名额。用 MinHash 做近似去重比精确匹配实用。from datasketch import MinHash, MinHashLSH def dedup(chunks, threshold0.8): lsh MinHashLSH(thresholdthreshold, num_perm128) kept [] for i, chunk in enumerate(chunks): m MinHash(num_perm128) for token in set(chunk): m.update(token.encode(utf8)) if not lsh.query(m): lsh.insert(str(i), m) kept.append(chunk) return kept逻辑说明num_perm128是哈希函数个数越大越准但越慢128 是常用平衡点。threshold0.8表示相似度超过 80% 判为重复。MinHash 对长文本效果好短句可能误判所以切分后再去重比整篇去重更稳。4. 检索质量调优embedding、重排与混合检索RAG 的上限由检索决定。模型再强检索回来的片段不相关回答就是错的。这一章讲三个提升检索质量的手段换 embedding 模型、加重排、混合检索。每个都给出可对比的配置让你知道什么时候该上哪个。4.1 embedding 模型选型中文场景别用英文模型embedding 模型决定了「语义相近」的判断准不准。中文场景下BAAI/bge系列和m3e系列是常见选择英文模型如all-MiniLM在中文上会明显掉点。from sentence_transformers import SentenceTransformer # 对比两个模型在同一 query 上的检索差异 models { bge-small-zh: BAAI/bge-small-zh-v1.5, m3e-base: moka-ai/m3e-base } for name, path in models.items(): model SentenceTransformer(path) q model.encode(报销流程是什么) d1 model.encode(员工费用报销需要提交发票) d2 model.encode(今天天气不错) import numpy as np sim1 np.dot(q, d1) / (np.linalg.norm(q) * np.linalg.norm(d1)) sim2 np.dot(q, d2) / (np.linalg.norm(q) * np.linalg.norm(d2)) print(f{name}: 相关{sim1:.3f}, 无关{sim2:.3f})参数说明bge-small-zh维度 512速度快适合百万级以下文档m3e-base维度 768效果略好但慢。选型时看「相关-无关」的差值差值越大区分度越好。一般差值在 0.2 以上算可用。4.2 加重排用 cross-encoder 把 top50 精排到 top5向量检索是「粗排」召回快但精度有限。加一层 cross-encoder 重排把检索回来的 top50 重新打分取 top5 喂给模型效果提升明显。from sentence_transformers import CrossEncoder reranker CrossEncoder(BAAI/bge-reranker-base) def retrieve_with_rerank(query, vectordb, top_k50, final_k5): # 粗排召回 candidates vectordb.similarity_search(query, ktop_k) # 精排打分 pairs [(query, doc.page_content) for doc in candidates] scores reranker.predict(pairs) # 按分数排序取前 final_k ranked sorted(zip(candidates, scores), keylambda x: x[1], reverseTrue) return [doc for doc, _ in ranked[:final_k]]逻辑说明top_k50是粗排召回数太小重排没意义太大重排耗时。final_k5是最终喂给模型的片段数配合 prompt 长度调整。cross-encoder 比向量检索慢一个量级所以只用在精排阶段不要拿它做全库检索。4.3 混合检索BM25 补上向量检索的关键词短板向量检索对「专有名词、型号、编号」不敏感比如「XJ-2000 型号的额定功率」向量可能召回一堆泛泛的功率说明。BM25 是关键词检索正好补这个短板。混合检索就是把两路结果加权融合。from rank_bm25 import BM25Okapi import jieba # 构建 BM25 索引 corpus [c.page_content for c in chunks] tokenized [list(jieba.cut(doc)) for doc in corpus] bm25 BM25Okapi(tokenized) def hybrid_search(query, vectordb, alpha0.5, k5): # 向量路 vec_results vectordb.similarity_search_with_score(query, k20) # BM25 路 bm25_scores bm25.get_scores(list(jieba.cut(query))) bm25_top sorted(range(len(bm25_scores)), keylambda i: bm25_scores[i], reverseTrue)[:20] # 归一化后加权融合 score_map {} for doc, score in vec_results: score_map[doc.page_content] score_map.get(doc.page_content, 0) alpha * (1 - score) for i in bm25_top: score_map[corpus[i]] score_map.get(corpus[i], 0) (1 - alpha) * bm25_scores[i] ranked sorted(score_map.items(), keylambda x: x[1], reverseTrue) return [text for text, _ in ranked[:k]]参数说明alpha0.5是向量路权重专有名词多的场景调到 0.3 让 BM25 占主导。jieba.cut做中文分词BM25 依赖分词质量领域词典要提前加进去。两路各召回 20 条再融合比单路召回 5 条稳得多。5. 避坑与排查本地文件调教 DeepSeek 的五个血泪教训这一章不讲新东西专门讲我踩过的坑。每一条都是「现象 → 原因 → 解决」的结构你照着排查能省不少时间。5.1 检索到了但模型不用prompt 里 context 位置放错现象检索回来的片段明明包含答案模型却回答「资料中没有」。原因context 放在 system prompt 里且被长指令挤到后面模型注意力没落在上面。解决把 context 放在 user message 里且用明确分隔符包起来比如【资料开始】...【资料结束】并在 system 里强调「优先使用资料中的内容」。5.2 中文 PDF 提取全是乱码编码和字体映射问题现象PyPDFLoader提取出来的中文是\uXXXX或方块。原因PDF 内嵌字体没有 ToUnicode 映射提取工具拿不到字符编码。解决换pdfplumber或pymupdf试两者对字体映射的处理不同都不行就用 OCR 兜底paddleocr对中文 PDF 识别率不错。5.3 微调后模型变傻灾难性遗忘现象SFT 之后领域问题答得好了但通用对话能力明显下降。原因学习率太高或训练轮数太多模型把通用能力覆盖了。解决降learning_rate到 1e-4num_train_epochs降到 1 到 2LoRA 的r别超过 32并在训练数据里混入 10% 到 20% 的通用语料。5.4 向量库越查越慢没建索引现象文档量到十万级后检索从毫秒变成秒级。原因Chroma 默认暴力检索没建 ANN 索引。解决切换到支持 HNSW 索引的向量库或在 Chroma 里配置hnsw:space参数。数据量再大就上 Milvus 或 Qdrant。5.5 同一问题两次回答不一样temperature 和检索不稳定现象同一个问题两次回答内容差异大。原因temperature设太高或检索的 top_k 结果每次略有不同。解决知识库问答把temperature压到 0.1 以下检索结果做缓存相同 query 直接返回缓存片段。6. 进阶技巧用查询改写和自查询把召回率再提一档前面几章把基础流程跑通了这一章讲两个进阶技巧能让召回率再上一个台阶。第一个是查询改写用户问「年假」文档里写的是「带薪年休假」字面不匹配但语义相同向量检索可能漏掉。做法是先用 DeepSeek 把用户 query 改写成多个同义表达分别检索再合并。def rewrite_query(query, client): prompt f把下面的问题改写成3个语义相同但用词不同的查询每行一个不要编号\n{query} resp client.chat.completions.create( modeldeepseek, messages[{role: user, content: prompt}], temperature0.3 ) return [q.strip() for q in resp.choices[0].message.content.split(\n) if q.strip()] def multi_query_retrieve(query, vectordb, client, k5): queries [query] rewrite_query(query, client) all_docs {} for q in queries: for doc in vectordb.similarity_search(q, kk): all_docs[doc.page_content] all_docs.get(doc.page_content, 0) 1 # 出现次数多的片段优先 ranked sorted(all_docs.items(), keylambda x: x[1], reverseTrue) return [text for text, _ in ranked[:k]]逻辑说明temperature0.3让改写有变化但不发散。多路检索后按「被命中次数」排序命中越多说明越相关。这个技巧对同义词多的领域特别有效代价是多几次检索和一次改写调用。第二个技巧是自查询self-query让模型从用户问题里抽出过滤条件。比如「2023 年之后的报销政策」模型抽出year 2023检索时先按元数据过滤再向量检索精度提升明显。做法是在文档入库时给每个 chunk 打上year、department、doc_type等元数据检索时用 Chroma 的filter参数。# 入库时带元数据 vectordb Chroma.from_documents( chunks, embeddings, metadatas[{year: 2023, dept: 财务} for _ in chunks] ) # 检索时过滤 results vectordb.similarity_search( 报销政策, k5, filter{year: {$gt: 2022}} )元数据的抽取可以半自动文件名带年份的直接解析正文里的日期用正则抽。这一步前期投入大但文档量上去之后收益非常明显。我自己的习惯是每接一批新文档先跑一遍预处理脚本看清洗后的文本再抽 20 个真实问题测召回率低于 80% 就不往下走回头调切分和 embedding。这个习惯帮我省了很多「上线后才发现检索不行」的返工。希望帮到你。本文还有配套的精品资源点击获取