★ FEATURED ARTICLE 简介面向政务系统升级与政策智能问答落地这份PDF资料系统讲解如何基于DeepSeek在低资源约束下完成模型训练与部署适用对象包括政务信息化人员、AI算法工程师、技术决策者以及需要将大模型引入公共服务场景的开发者。文档共31页以单个PDF文件形式打包资源总大小约1.99MB排版清晰、目录完整查阅和打印都很方便。内容既有政务系统现状、政策问答重要性等背景分析也深入展开DeepSeek模型架构特点与性能优势以及低资源训练策略数据增强中的回译与同义词替换、迁移学习中的预训练微调与多任务学习、模型压缩中的剪枝与量化。后续章节进一步覆盖政策问答系统的总体架构、数据收集与标注、训练环境搭建与监控、问答功能实现、系统集成测试以及真实案例评估与改进建议。已有167人学习下载可作为理解从模型原理到系统落地完整链路、在有限算力下构建政策智能问答的实用参考。1. 政务问答不是套模板DeepSeek 低资源训练解决的是「敢不敢用」政务系统里做政策问答最大的阻力不是模型跑不动而是答错了没人担责。通用大模型放到办事窗口经常把“可以”说成“必须”把前置条件漏掉这种翻车一次就够项目组写复盘报告了。DeepSeek 低资源训练的思路是在不采购昂贵 GPU 的前提下用一个 1.5B 到 7B 规模的开源模型配合 QLoRA 微调和检索增强把回答范围锁在本地政策库内。这套方案解决的是三个具体问题政策多、更新快、答案要能追溯到条款。适合政务信息化项目里的算法工程师、数据负责人以及在等预算审批、又想先跑出可演示系统的团队。2. 先选型再喂数据DeepSeek 低资源训练的政策问答数据怎么造很多团队一上来就找算力其实政务问答项目的瓶颈是数据。数据决定了模型回答的上限没有干净、可溯源的问答对后面调参全是安慰自己。我一般先把环境分成两类一类是单卡 16G 显存RTX 4090 / A4000 级别另一类是纯 CPU 加 32G 内存的政务内网机器。对应地DeepSeek 选择 1.5B 或 7B 的蒸馏对话版不要一上来就拉 70B 的大模型那已经不是低资源了。这一章先解决两件事为什么用 DeepSeek LoRA以及怎么把政策原文变成模型能学的训练数据。数据格式和清洗脚本可以直接抄后面训练脚本依赖这里的输出。2.1 为什么是 DeepSeek LoRA单卡 16G 也能微调全量微调一个 7B 模型需要至少 56G 显存这在政务采购流程里几乎不可能。LoRA 的做法是冻结原模型权重只训练插入到注意力层的小型低秩矩阵可训练参数量通常只有原来的 0.5% 到 1%。QLoRA 再进一步把冻结的权重用 4bit 量化存储训练时反量化到半精度计算这样 7B 模型的峰值显存能压到 16G 左右。选 DeepSeek 而不是其他同规模模型有三点实际原因。第一DeepSeek 的中文政策文本理解更稳特别是长句、多重定语条款和「但书」这类政务文本里常见的转折结构换成同等规模通用模型很容易把限定条件丢掉。第二DeepSeek 蒸馏系列参数量从 1.5B 到 7B 覆盖得很好可以让硬件决定模型大小而不是反过来。第三它的 chat template 是 ChatML 格式和主流 RAG 工具拼接 prompt 时不用做额外适配后期接检索增强省事。这里有个选择陷阱需要说清楚如果你用的是 R1 推理蒸馏版模型默认会在回答前输出一段思考链办事窗口的人看到的是“我来分析一下这个政策”体验很差。做政策问答我一般选 instruct/chat 版或在微调时把 system prompt 固定为“只输出最终答案不输出推理过程”。这个细节会影响后面训练数据的构造。方案显存占用可训练参数占比适用场景全量微调50G100%有 A100 集群的部门LoRA20G 左右约 1%单卡 3090/4090QLoRA 4bit12-16G约 1%单卡 16G / 低资源常见做法2.2 政策问答训练集的三种格式alpaca、sharegpt 与明文对话训练数据格式直接决定微调能否生效。DeepSeek 社区里最常见的三种格式是 alpaca、sharegpt 和明文对话我列一下样例你看完就明白为什么政务场景要选 sharegpt。alpaca 格式长这样适合单轮问答{ instruction: 根据《XX市就业补贴政策》企业新招用应届高校毕业生可以申请什么补贴, input: , output: 根据《XX市就业补贴政策》第十二条可以申请一次性吸纳就业补贴。同一名毕业生只能由一家企业申报一次补贴标准为每人2000元。 }sharegpt 格式把指令和回答放成多轮对话DeepSeek 的 ChatML 模板能直接映射{ conversations: [ { from: human, value: 企业新招用应届高校毕业生有什么补贴 }, { from: gpt, value: 根据《XX市就业补贴政策》第十二条可以申请一次性吸纳就业补贴标准为每人2000元同一名毕业生只能申报一次。 }, { from: human, value: 需要准备哪些材料 }, { from: gpt, value: 需要企业营业执照副本、毕业生身份证复印件、劳动合同备案证明具体清单可参照政策附件。 } ] }明文对话则是直接在文本里写“用户……助理……”不依赖特殊 token。低资源训练里我优先推荐 sharegpt因为它训练时会把system、user、assistant角色分开模型能学到“什么时候该答、什么时候该拒答”的边界。政务数据里经常要识别“非政策范围内”的问题这种角色分离很有用。数据清洗时要注意三类问题。一是去掉所有“好的”“您好根据您的提问”这类寒暄前缀否则模型会把寒暄当成回答的开头。二是政策名称和条款号必须保留完整不能为了省 token 把“第X条”删掉这是政务问答溯源的关键。三是每条回答里至少要包含一个可检索的政策依据短语比如“根据《……》第X条”后面做 RAG 验证时用得上。清洗脚本不复杂就是正则替换加规则过滤但这一步偷懒后面训练出来的模型会学会“编”。我通常会把清洗后的数据集按政策文件分桶同一个政策下的问答对放一个文件避免训练时把不同政策的条款混在一起。2.3 从政策原文半自动生成问答对一个能跑的标注脚本人工写问答对太慢政务政策文件动辄几十页全量人工标注一个项目要两人干三周。常见做法是先用本地部署的 DeepSeek 对政策原文做半自动标注生成候选问答对再做人工抽检。这里用 Ollama 的本地接口避免敏感政策文本传到外部 API。import json import re from openai import OpenAI client OpenAI(base_urlhttp://localhost:11434/v1, api_keyollama) def load_policy_text(path): # 假设 policy.txt 是去掉页眉页脚和表格图片后的纯文本 with open(path, encodingutf-8) as f: return f.read() def split_policy(text, chunk_size600): # 按句号分句再按 600 字左右拼块尽量让每个块是完整条款 sentences re.split(r(?[。]), text) chunks [] buf for sent in sentences: buf sent if len(buf) chunk_size: chunks.append(buf.strip()) buf if buf.strip(): chunks.append(buf.strip()) return chunks def build_qa_pair(chunk): prompt f你是一名政务问答标注员。请阅读下面的政策原文生成 2 个市民最可能问的问题和对应答案。 要求只依据原文不能编造答案必须包含政策名称或条款号问题口语化。 原文 {chunk} 输出 JSON 数组格式为 [{{question: ..., answer: ...}}] resp client.chat.completions.create( modeldeepseek-r1:7b, # 替换成你本地 Ollama 拉取的标签 messages[{role: user, content: prompt}], temperature0.2, max_tokens512, ) content resp.choices[0].message.content content content.strip() # 模型偶尔会输出 json 包裹代码块剥掉 if content.startswith(): content re.sub(r^(json)?, , content).strip() content content.rstrip().strip() return json.loads(content) text load_policy_text(employment_policy.txt) chunks split_policy(text) all_qa [] for chunk in chunks[:200]: try: qa_list build_qa_pair(chunk) all_qa.extend(qa_list) except json.JSONDecodeError as e: print(f解析失败跳过当前片段{e}) with open(policy_qa.jsonl, w, encodingutf-8) as f: for i, qa in enumerate(all_qa): f.write(json.dumps({ id: i 1, instruction: qa[question], output: qa[answer], source: employment_policy.txt }, ensure_asciiFalse) \n)这段脚本的逻辑是先把政策原文切成 600 字左右的小块再让本地模型按块生成问题答案对。temperature0.2很关键政务问答要的是低随机性不是创意写作温度高会让模型发挥出原文没有的条款。max_tokens512是上限答案超长说明模型在自由发挥宁可截断也不要让它写一篇小作文。脚本跑完会得到 policy_qa.jsonl每条带source字段记录来源文件后面做 RAG 评估时要拿这个字段溯源。第一次跑不要贪多先拿一个政策文件的前 50 个块试跑人工看 10 条数据质量再决定全量批处理。很多团队一上来跑几千条生成数据模型训练完一问才发现标注本身是错的那就是给垃圾数据打工。3. 动手微调 DeepSeek一套 16GB 显存可跑的 QLoRA 训练流程数据就绪之后进入正式训练。这里给你的是一套可以直接在 16GB 显存上跑通的 QLoRA 流程模型以 DeepSeek-R1-Distill-Qwen-1.5B 为例。为什么选 1.5B 先跑通因为低资源训练第一个目标是验证数据格式和训练链路而不是直接追求效果。1.5B 用 QLoRA 跑 3 个 epoch单卡 16G 显存大约一小时内完成等你在小模型上把数据、模板、评估方式都调顺了再换成 7B 版本成功率和时间成本都可控。这个顺序是我自己的血泪经验直接上 7B超参不对跑三个小时才看到 loss 异常后悔药都没法吃。3.1 环境准备transformers、peft 与 bitsandbytes 的组合训练依赖的库比较固定常见做法是 transformers、peft、trl、bitsandbytes、datasets、accelerate 一起装。先装基础环境再拉模型。政务网机器如果连不了外网需要提前在能联网的机器上把依赖和模型文件都准备好这个在第 4 章排查看。pip install torch transformers peft trl bitsandbytes datasets acceleratetorch 的安装方式取决于你的 CUDA 版本建议从 PyTorch 官网选对应的安装命令这里不写死。装完检查一下 bitsandbytes 是否正常加载低资源训练里它负责 4bit 量化如果 import 失败后面的 LoRA 训练根本起不来。检查命令python -c import bitsandbytes as bnb; print(bnb.__version__)如果这一步报错不要急着重装先看报错信息里有没有CUDA_SETUP字样这个在第 4 章有专门排查。3.2 训练脚本与超参把 LoRA 接到 DeepSeek 的注意力层训练脚本的核心是把 DeepSeek 以 4bit 量化加载然后接入 LoRA再用 SFTTrainer 跑监督微调。完整脚本如下import torch from transformers import ( AutoModelForCausalLM, AutoTokenizer, TrainingArguments, BitsAndBytesConfig, ) from peft import LoraConfig, prepare_model_for_kbit_training, get_peft_model from trl import SFTTrainer from datasets import load_dataset model_id deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B bnb_config BitsAndBytesConfig( load_in_4bitTrue, bnb_4bit_quant_typenf4, bnb_4bit_compute_dtypetorch.float16, bnb_4bit_use_double_quantTrue, ) model AutoModelForCausalLM.from_pretrained( model_id, quantization_configbnb_config, device_mapauto, trust_remote_codeTrue, ) tokenizer AutoTokenizer.from_pretrained(model_id, trust_remote_codeTrue) tokenizer.pad_token tokenizer.eos_token model prepare_model_for_kbit_training(model) lora_config LoraConfig( r8, lora_alpha16, lora_dropout0.05, target_modules[ q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj, ], biasnone, task_typeCAUSAL_LM, ) model get_peft_model(model, lora_config) dataset load_dataset(json, data_filespolicy_qa.jsonl) def format_policy_example(example): text f### 指令\n{example[instruction]}\n### 回答\n{example[output]}|endoftext| return {text: text} dataset dataset.map(format_policy_example) train_args TrainingArguments( output_dir./deepseek-policy-qa, per_device_train_batch_size2, gradient_accumulation_steps8, num_train_epochs3, learning_rate2e-4, logging_steps20, save_strategysteps, save_steps200, bf16True if torch.cuda.is_bf16_supported() else False, optimpaged_adamw_8bit, gradient_checkpointingTrue, ) trainer SFTTrainer( modelmodel, train_datasetdataset[train], argstrain_args, max_seq_length2048, dataset_text_fieldtext, ) trainer.train() trainer.save_model(./deepseek-policy-qa-lora) tokenizer.save_pretrained(./deepseek-policy-qa-lora)代码逻辑分四步先按 4bit 精度加载模型并补上 pad token这一步不补的话训练时 batch 会报错然后把模型标记为 kbit 训练并挂 LoRA第三步把问答数据拼成一段带指令和回答标记的文本最后用 SFTTrainer 控制最大长度和训练参数跑监督微调。关键参数我给你拆开讲。r8表示低秩矩阵的秩政务问答数据量通常只有几千条秩太高容易过拟合。lora_alpha16控制 LoRA 权重缩放倍数和 r 保持两倍关系是社区里最常见的稳妥配置。gradient_accumulation_steps8配合per_device_train_batch_size2等效 batch size 是 16低资源环境下靠累积步进补足 batch显存占用稳定。optimpaged_adamw_8bit是 bitsandbytes 提供的分页优化器把优化器状态换到 CPU 内存这是 16G 显存能跑完 7B 微调的重要帮手。gradient_checkpointingTrue用计算换显存训练时间会变长但显存能省下 30% 左右。max_seq_length2048需要注意如果政策回答比较长超过 2048 会被截断回答末尾的条款号可能丢失。我一般先统计训练集中最长 sample 的 token 数再定这个参数不要盲目拉长因为序列越长梯度回传占的显存越大。3.3 合并权重导出 GGUF让 16G 内存电脑也能跑起来LoRA 微调完模型权重分成了底座和 LoRA 适配器两部分。后续要部署到 Ollama 这种低资源推理环境需要先把两部分合并再转成 GGUF 格式。合并命令python -m peft.cli.merge_lora \ --model_name_or_path deepseek-ai/DeepSeek-R1-Distill-Qwen-1.5B \ --adapter_name_or_path ./deepseek-policy-qa-lora \ --output_dir ./deepseek-policy-qa-merged合并后的目录就是完整的 Hugging Face 格式模型。接下来用 llama.cpp 的转换脚本把它转成 GGUF量化等级我建议 q8_0政务问答要保留数字细节q4_k_m 虽然省一半体积但条款号偶尔会出错。python llama.cpp/convert_hf_to_gguf.py ./deepseek-policy-qa-merged \ --outfile deepseek-policy-qa-7b-q8_0.gguf \ --outtype q8_0转换完成后写一个 Ollama Modelfile。这里最容易出错的是聊天模板必须和训练时保持一致。DeepSeek 的 chat template 是 ChatML 格式Modelfile 里要显式声明FROM ./deepseek-policy-qa-7b-q8_0.gguf TEMPLATE {{- if .System }}|im_start|system {{ .System }}|im_end| {{- end }}|im_start|user {{ .Prompt }}|im_end| |im_start|assistant 最后执行ollama create policy-qa -f Modelfile就得到一个能用ollama run policy-qa调用的本地模型。这套链路跑通后你的模型不再依赖外部 API数据不出政务内网这在验收时是一个很硬的加分项。4. 政务落地的 4 个避坑点微调、模板和内网部署的排查清单训练脚本能跑通只是第一步政务场景真正耗时间的是那些不报错、但结果不对的隐性坑。下面四条是我在政策问答项目里反复遇到的按「现象、原因、解决」写清楚你可以直接把它当排查清单用。4.1 现象一loss 降了政策问答却答非所问训练日志里 loss 从 1.8 降到 0.9非常漂亮但上线试问“失业保险金怎么领”模型回了一段“根据相关政策您需要根据自身情况准备材料”的套话既没有政策名称也没有条款号。这种情况出现时很多人会怀疑模型太小于是换更大的模型结果照旧。原因通常是训练数据里“正确的废话”太多了。半自动标注生成的问答对里模型可能把“根据相关政策”这种模糊表述当成了标准答案而人工抽检只看了前几条没发现。低资源微调下模型容量有限它优先记录高频句式如果你的数据里高频答案是空话它学的就是空话。解决方法是清洗回答的固定前缀并把所有回答统一改写为“根据《政策名》第X条具体规定是……”。我用正则把“根据相关政策”替换成原文里的具体政策名没有政策名的整条直接淘汰。另外训练数据里不要塞入原文整段复制模型会把长原文背下来却无法对应用户的问法我倾向于只保留问答对原文交给第 5 章的 RAG 处理。4.2 现象二chat template 没对齐生成一堆乱符号模型在 Ollama 里跑起来后回答开头出现|im_end||im_start|这类标记或者第一句正常、第二句开始重复模板符号。这个坑不带报错不仔细看很容易当成推理噪声。原因是训练时用的 ChatML 模板和 Ollama 推理时用的 Modelfile 模板不一致。训练时 tokenizer 会把|im_start|当成特殊 token 参与计算推理时如果 Ollama 没有按同样模板包装 prompt模型就不知道怎么开始和结束回答会把特殊 token 当作普通文本生成出来。解决方法是导出前先检查 tokenizer 的chat_template字段。在合并权重后的目录里执行from transformers import AutoTokenizer tk AutoTokenizer.from_pretrained(./deepseek-policy-qa-merged) print(tk.chat_template)打印出来的模板就是训练时实际使用的把它原样填到 Ollama Modelfile 的 TEMPLATE 里不要凭记忆手写。另外一个稳妥做法是训练数据直接用明文格式不依赖特殊 token但这样回答稳定性会略差我不建议第一次就省这一步模板对齐是低资源训练里最值得花时间的活。4.3 现象三离线内网装不上 bitsandbytes政务内网机器装了离线 pip 源后安装 bitsandbytes 经常报编译错误或者 import 时提示找不到 CUDA 的.so文件。现象是训练脚本在load_in_4bitTrue处直接崩掉报错信息里有CUDA_SETUP字样。原因是 bitsandbytes 的包在安装时会根据当前机器的 CUDA 版本和 GCC 版本选择二进制内网机器的 GCC 版本较老或者 PyTorch 版本不匹配导致动态加载失败。这不是你代码的问题。解决方法是提前在外网机器上装好然后用pip download bitsandbytes -d /tmp/bnb把 wheel 包和依赖一起下载拷贝进内网后pip install --no-index --find-links/tmp/bnb bitsandbytes。如果内网机器连外网都没有那就换方案放弃 4bit用 FP16 半精度加 gradient checkpointing 训练显存占用大约 22G仍算低资源范畴。还有一个更轻的选择是直接在 llama.cpp 上做 LoRA 微调它不需要 bitsandbytes但功能支持有限适合纯 CPU 验证不建议作为正式训练链路。4.4 现象四政策更新后模型还在答旧政策政务政策每年都会调整补贴标准、申请材料、办理时限都可能变。微调模型第一次上线效果不错但新政策发布后一问新标准模型还是按旧政策的口径在答。这个问题最危险因为它不报错业务方如果没发现会直接把旧政策发布给市民。原因是微调把知识固化进了权重。低资源训练的数据量小模型会把高频出现的数字和条款背得很牢新政策发布后你的训练数据还没更新模型自然答旧。这不是靠增加训练数据能彻底解决的政策更新频率比模型迭代快得多。解决方法是不要在模型权重里存“政策时效性知识”把具体数字、条款号、材料清单全部交给 RAG。微调模型只负责两件事识别用户问题的意图以及按照“根据《政策名》第X条”的格式组织回答。当检索库里没有相关内容时模型要能说出“当前政策库暂无相关规定”。这样政策更新后你只需要更新检索库的文档不需要重新训练模型RAG 就成了低资源训练方案的后悔药。5. 检索兜底用 RAG 让 DeepSeek 政策问答每一句都有出处微调解决了“会说话”但没解决“说得对”。政策问答的正确答案是随文件更新变化的重训模型成本高、周期长。这里把 RAG 接进来先把政策原文切块、向量化用户提问时先检索相关片段再把片段拼进 prompt 让模型基于原文回答。这是政务问答落地里最常见的工程结构微调加 RAG一个负责格式一个负责事实。5.1 微调解决不了政策时效性RAG 是政务问答的「后悔药」微调模型的本质是把训练集里的知识压缩进权重一旦政策更新你只有两条路继续微调或者换思路。政务场景里政策文件每月都可能调整每次更新都重训时间和卡费都不现实。RAG 的思路是文档更新后只改向量库不改模型。一个政策文本被替换重新切片、重新索引回答立刻跟着变。这个机制让我在验收时敢跟业务方说以后政策更新你提供新文件我们一小时内完成检索库同步。这就是后悔药的价值。5.2 最小 RAG 实现BGE 中文向量 FAISS 召回 DeepSeek 生成我常用的最小方案是 BGE 中文向量模型加 FAISS生成端用本地部署的 DeepSeek。BGE 系列对政务长文本的中文语义匹配效果稳定FAISS 轻量、内网部署没有额外依赖。代码分两步先建索引再拼接 prompt。from sentence_transformers import SentenceTransformer import faiss import numpy as np embedder SentenceTransformer(BAAI/bge-small-zh-v1.5) # chunks 是上一章按 600 字切好的政策片段列表 chunks [...] # 实际从 policy_chunks.json 读取 embeddings embedder.encode(chunks, normalize_embeddingsTrue) embeddings np.asarray(embeddings, dtypefloat32) index faiss.IndexFlatIP(embeddings.shape[1]) index.add(embeddings) def retrieve_policy(question, top_k3): q_emb embedder.encode([question], normalize_embeddingsTrue) q_emb np.asarray(q_emb, dtypefloat32) scores, indices index.search(q_emb, top_k) return [chunks[i] for i in indices[0]]这个脚本的要点是normalize_embeddingsTrue加IndexFlatIP做的是向量内积等价于余弦相似度。切片越长召回越准还是越差政务文本里一个条款常跨多个自然段600 字切块能保留完整语义但不能把一个政策下的多个并列条款拆到不同块否则检索可能只召回一半。召回之后把原文片段塞进 DeepSeek 的 prompt并显式要求模型“只依据原文回答”from openai import OpenAI client OpenAI(base_urlhttp://localhost:11434/v1, api_keyollama) question 企业新招用应届高校毕业生有什么补贴 context \n.join(retrieve_policy(question)) prompt f请根据以下政策原文回答用户问题。如果原文中没有依据直接回答“当前政策库暂无相关规定”。 政策原文 {context} 用户问题{question} 回答 resp client.chat.completions.create( modelpolicy-qa, messages[{role: user, content: prompt}], temperature0.1, ) print(resp.choices[0].message.content)注意这里的temperature0.1比标注脚本里的 0.2 更低。生成阶段任何随机性都可能导致条款号被改写政务问答必须压低温度。模型用的是policy-qa也就是第 3 章创建的那个 Ollama 模型不是通用 DeepSeek这样回答风格始终带着政务口径。5.3 政务内网部署时怎么选Ollama 还是 vLLM低资源部署有两个常见选项Ollama 和 vLLM。过来人的建议是先按硬件分。纯 CPU 机器、内存 16G 到 32G用 Ollama 跑 GGUF 量化版本这是最容易落地的路线。Ollama 自带 OpenAI 兼容接口第 2 章的标注脚本和第 5 章的生成代码几乎不用改直接把 base_url 指到本机 11434 端口就行。如果内网机器有 GPU 且显存在 24G 以上同时业务方要求并发响应要达到几十路vLLM 部署 DeepSeek 更适合它的 continuous batching 能显著提高吞吐但显存规划和模型量化需要单独调优。要注意的是DeepSeek 的 MoE 大版本和蒸馏版在 vLLM 上的支持程度不一样。蒸馏版通常没问题MoE 版需要确认当前 vLLM 版本的兼容性。政务内网多数据不出域本地部署是硬前提外部 API 调用基本不用考虑。我见过团队花了很久调 OpenAI 接口参数最后发现内网机器根本没开外网权限这类方向性错误越早确认越好。6. 交付前这样验收拿二十条刁钻问题给业务方一个交代6.1 评测维度与通过标准模型能不能上线不是看 loss 曲线而是看业务方拿真实问题试出来的结果。我通常准备二十条以上刁钻问题按下面这个表逐项打分评测维度通过标准测试方式答案准确性随机 50 条问答中政策依据可追溯比例不低于 90%检查回答中是否有具体政策名和条款号拒答正确率库外问题正确拒答率不低于 70%故意问“义务教育收费标准”等不在当前库的问题引用一致性政策名称、条款号与原文一致率 100%用检索出的原文片段逐字比对响应时长单问响应不超过 5 秒低配 CPU 机器上压测这二十条问题里要刻意放几种场景同义改写、数字陷阱、跨政策引用。比如政策里写“小微企业”评测时问“小型企业”看模型能不能从召回结果里找到对应条款再把补贴金额前后年数字混在一起问看模型会不会被旧数字带偏最后问那种需要同时引用两份政策的问题看 RAG 的 top_k 够不够用。6.2 我把哪些验证动作留成了习惯我现在养成的习惯是每次更新政策库后先跑一遍回归再交给窗口使用。回归不是重新训练而是拿上一轮评测的二十条问题重新走一遍问答链路重点看新增政策有没有把旧的向量召回结果冲歪。另一个习惯是把每次人工订正的问答对沉到训练集里攒够一批后再做一轮低成本微调。这样模型越用越贴业务口径RAG 越用越准。这套方案也许不是技术上最前沿的但它是政务项目里预算、数据安全、政策时效性三者之间平衡得最好的一个落地方案。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
