1. 为什么“超体”模型选型是整个系统的地基做过大模型应用的人都有一个共同体会模型选错了后面 Prompt 写得再花哨也是白搭。我把这套方案叫做「超体」模型意思是一个能承载多种任务形态的“超级载体”——它既要能扛住结构化抽取又要能稳定对话还得在成本和延迟之间找到平衡点。这一节先聊清楚选型的底层逻辑。1.1 先搞清楚你的任务到底属于哪一类很多人一上来就问“哪个大模型最好”这个问题本身就没有答案。正确的问法是我的任务属于哪一类这类任务对模型的核心要求是什么。我一般把大模型应用任务分成四类结构化抽取类从合同、招标文件、实施方案、发票等文档里抽出页码、章节、段落、金额、甲乙方等字段。这类任务对模型的指令遵循能力和格式稳定性要求极高对创意能力几乎没要求。知识问答类基于给定上下文回答问题典型场景是客服、文档助手。核心要求是忠实于上下文不能瞎编也就是防幻觉能力要强。生成创作类写文案、写方案、写代码。这类任务对模型的通用能力和创造力要求高对格式的容忍度反而大。Agent 编排类模型需要调用工具、做多步推理、维护状态。这类任务对模型的函数调用能力和长上下文稳定性要求最高。「超体」模型要同时覆盖前两类偶尔兼顾第三类所以选型时我的权重排序是指令遵循 防幻觉 长上下文 推理能力 生成质量 成本。这个排序和很多人直觉相反但实际落地过就知道格式跑偏和胡编乱造才是生产环境里最致命的。1.2 参数规模不是越大越好7B 到 72B 怎么选热词里频繁出现 qwen2.5-7b 微调、llamacpp 部署、ollama 部署私有大模型说明很多团队在往本地化和小参数方向走。我的经验是参数规模适合场景硬件门槛结构化输出稳定性7B 级别单一抽取任务、分类任务单卡 16G 可跑量化版需要强 Prompt 约束偶尔跑偏14B-32B多任务混合、中等复杂度抽取单卡 24G-48G较好配合 few-shot 很稳70B 及以上复杂推理、长文档理解多卡或量化部署好但成本和延迟高我实测下来纯结构化抽取任务14B 到 32B 是性价比甜点区。7B 在字段少、格式简单时够用但一旦文档结构复杂比如招标文件里嵌套表格加多级标题7B 的格式遵循就会开始飘。70B 当然更稳但如果你一天要处理几万份文档推理成本会让你重新思考人生。1.3 闭源 API 和本地部署的真实取舍免费大模型 API、codex 接入国内大模型、vllm 部署大模型这些热词背后是同一个纠结用云 API 还是本地部署。我的判断标准很直接数据敏感度合同、招标文件这类内容很多团队不允许出内网那就只能本地部署。调用量日均调用低于几千次云 API 更省心高于几万次本地部署的边际成本优势就出来了。迭代速度云 API 换模型就是改个参数本地部署换模型要重新拉权重、调显存、跑压测。我一般建议团队先用云 API 快速验证 Prompt 和流程等流程跑通、调用量上来、数据合规要求明确后再迁移到本地部署。这样避免一开始就陷进环境配置和显存优化的泥潭里。2. Prompt 工程的核心让模型“不得不”按格式输出选好模型只是第一步真正决定输出质量的是 Prompt 工程。热词里 prompt engineering 提示工程、大模型提示词工程与上下文工程反复出现说明这是大家最关心的环节。我的核心观点是好的 Prompt 不是“请求”模型输出好结果而是“设计”得让模型没有机会输出坏结果。2.1 结构化输出的三层约束法很多人写 Prompt 就是一句“请提取以下字段”然后祈祷模型听话。这种做法在生产环境里必挂。我用的是三层约束法第一层Schema 前置声明。在 Prompt 最开头就把输出结构定义清楚而不是放在最后。模型对开头内容的注意力权重更高这是有实测依据的。{ document_type: 招标文件, chapters: [ { chapter_no: 第一章, chapter_title: 招标公告, page_start: 1, page_end: 3, paragraphs: [ {para_no: 1, content: ..., page: 1} ] } ] }第二层字段级约束说明。每个字段单独说明类型、取值范围、缺失时的处理方式。比如page_start必须是整数找不到时填 -1 而不是留空这样后续解析不会崩。第三层输出格式硬约束。明确要求“只输出 JSON不要任何解释性文字不要 markdown 代码块标记”。这一条看起来简单但不写的话模型有相当概率给你加一句“好的以下是提取结果”。注意三层约束的顺序不能乱。Schema 在前字段说明在中格式硬约束在最后紧贴输出位置这样模型的注意力分布最合理。2.2 Few-shot 示例怎么放才有效Few-shot 是提升结构化输出稳定性最有效的手段但放几个、放哪里、放什么样的示例都有讲究。我的经验是2 到 3 个示例最佳。1 个示例模型学不到边界情况4 个以上会挤占上下文窗口且边际收益递减。示例要覆盖一个标准完整案例、一个字段缺失案例、一个格式边界案例比如表格嵌套。示例的放置位置我试过三种全放 System Prompt 里、全放 User 消息里、System 放格式说明 User 放示例。实测下来第三种最稳因为 System 定义规则、User 展示实例符合模型训练时的对话结构分布。还有一个细节示例里的字段值不要用真实数据用示例值A、示例值B这种占位符避免模型把示例内容当成待抽取内容混进结果里。这个坑我踩过模型把示例里的“甲方某某公司”直接复制到输出里了。2.3 防幻觉的四个实操手段防幻觉是热词里明确提到的需求。结构化抽取场景下的幻觉主要表现为编造不存在的章节、把页码填错、字段值张冠李戴。我常用的四个手段手段一原文锚定。要求模型每个抽取结果都附带原文出处片段比如evidence: 原文中对应的一句话。这样即使出错也能快速定位是模型编的还是原文本身有歧义。手段二负向指令。明确告诉模型“如果原文中没有对应信息填写 null禁止推测和编造”。正向指令说“要准确”负向指令说“不许编”后者效果明显更好。手段三分步抽取。不要让模型一次性抽完所有字段。先抽章节结构再抽每章段落最后抽关键字段。分步之后每步的上下文更聚焦幻觉率大幅下降。手段四后置校验。模型输出后用规则引擎做一轮校验页码是否连续、章节编号是否递增、必填字段是否为空。校验不通过的重新调用或标记人工复核。2.4 上下文工程长文档怎么喂给模型文档解析能输出实施方案、合同还有招标文件的结构化文本这类文档动辄几十上百页。直接全文塞进去模型要么超窗口要么注意力涣散。我的做法是分块加索引先把文档按章节切成块每块控制在 2000 到 4000 token块与块之间保留章节标题作为上下文锚点。抽取时先让模型看目录结构再逐块处理最后合并结果。这样既控制了单次输入长度又保证了章节间的逻辑连贯。对于超长文档我还会加一层摘要预处理先用模型生成每章的摘要抽取时把摘要和原文块一起给模型帮助它理解当前块在全文中的位置。这个技巧在处理招标文件时特别有用因为很多字段的含义依赖上下文。3. 从零搭建「超体」的完整实操流程前面讲了选型和 Prompt 设计的思路这一节把完整流程串起来。我按实际项目顺序走一遍包含环境配置、模型接入、Prompt 调试、输出解析和效果验证。3.1 环境配置与模型接入如果你走本地部署路线ollama 和 vllm 是两个主流选择。ollama 适合快速验证一条命令拉模型vllm 适合生产环境吞吐量高、支持并发。我一般开发阶段用 ollama压测和上线用 vllm。以 ollama 为例拉取并运行一个 14B 级别的模型ollama pull qwen2.5:14b ollama run qwen2.5:14b接入层我推荐用 OpenAI 兼容协议封装这样换模型时业务代码不用动。Python 侧的核心调用逻辑from openai import OpenAI client OpenAI(base_urlhttp://localhost:11434/v1, api_keyollama) def extract_structured(text, schema_prompt): response client.chat.completions.create( modelqwen2.5:14b, messages[ {role: system, content: schema_prompt}, {role: user, content: text} ], temperature0.1, response_format{type: json_object} ) return response.choices[0].message.content注意temperature设成 0.1 甚至 0结构化抽取任务不需要创造性越低越稳。response_format如果模型支持 JSON mode一定要开这是最省事的格式约束。3.2 Prompt 模板的工程化管理Prompt 不要硬编码在代码里要单独管理。我用的是 YAML 加版本号的方式version: v3 system: | 你是一个文档结构化抽取引擎。严格按照以下 JSON Schema 输出... Schema: {schema} 规则 1. 只输出 JSON禁止任何解释文字 2. 字段缺失填 null禁止推测 3. 页码必须是整数 few_shot: - input: 示例文档片段A output: {示例JSON A} - input: 示例文档片段B output: {示例JSON B}这样做的好处是Prompt 改动可追溯A/B 测试方便回滚只需切版本号。我见过太多团队 Prompt 改崩了找不回旧版本只能凭记忆重写。3.3 输出解析与容错处理模型输出 JSON 后解析环节必须做容错。常见问题和对策问题表现对策多余文字JSON 前后有解释正则提取第一个{到最后一个}尾逗号JSON 不合法用 json5 或先做字符串清洗字段类型错页码是字符串解析后做类型转换和校验嵌套缺失某层字段没有用默认值填充标记待复核编码问题中文乱码统一 UTF-8检查模型输出编码我一般会写一个safe_parse函数把上述清洗逻辑都包进去解析失败时返回结构化错误而不是抛异常这样上游可以决定重试还是降级。3.4 效果验证怎么判断 Prompt 改好了Prompt 调优不能靠感觉要有量化指标。我用的核心指标是字段级准确率和格式合规率字段级准确率 正确抽取的字段数 / 总字段数。人工标注 50 到 100 份文档做测试集每次改 Prompt 都跑一遍。格式合规率 一次解析成功的次数 / 总调用次数。这个指标反映的是工程稳定性比准确率更早暴露问题。我通常要求格式合规率 99% 以上才上线字段准确率根据业务容忍度定一般 95% 起步。低于这个值要么加 few-shot要么换更大模型要么把任务拆得更细。4. 踩坑实录与常见问题速查这一节是我实际项目里踩过的坑和对应的解法都是文档里不会写的。4.1 模型“自作聪明”补全字段最典型的幻觉是模型看到“第一章”就自动补出“第二章”“第三章”哪怕原文只有一章。解法是在 Prompt 里加一句“章节编号必须来自原文禁止按顺序推断”。另外后置校验里加一条章节编号必须能在原文中找到对应字符串找不到就标记异常。4.2 长文档后半部分抽取质量骤降这是注意力衰减的典型表现。文档超过 8000 token 后模型对后半部分的抽取准确率明显下降。解法就是前面说的分块加索引不要指望模型一次性处理超长文档。如果必须整篇处理把关键字段的抽取指令在 Prompt 开头和结尾各放一次利用首尾注意力优势。4.3 JSON mode 开了还是输出非 JSON有些模型的 JSON mode 只是“倾向”而非“强制”偶尔还是会输出带 markdown 代码块的内容。解法是双保险开 JSON mode 的同时在 Prompt 里明确“禁止使用 markdown 代码块标记”解析时再做一层正则清洗。我实测下来双保险之后格式合规率能到 99.5% 以上。4.4 换模型后 Prompt 全部失效不同模型对同一 Prompt 的响应差异很大尤其是指令遵循风格。换模型后必须重新跑测试集不能假设 Prompt 可移植。我的做法是 Prompt 模板里留一个model_hint字段针对不同模型微调措辞比如有的模型对“必须”敏感有的对“请”更配合。4.5 常见问题速查表现象可能原因快速排查输出为空上下文超限或 Prompt 冲突缩短输入检查 System 和 User 是否矛盾字段全 null模型没理解任务加 few-shot检查 Schema 是否清晰格式时好时坏temperature 过高降到 0.1 以下开 JSON mode中文乱码编码不一致统一 UTF-8检查模型输出编码延迟过高模型太大或并发不足换小模型上 vllm 提吞吐抽取结果重复分块重叠检查分块逻辑去重合并提示每次改 Prompt 或换模型都要跑一遍回归测试集。我见过太多“改了一个词线上崩一半”的案例回归测试是唯一的保险。5. 进阶方向从单模型到「超体」编排当单模型跑通后可以考虑把「超体」升级成多模型编排。比如用一个小模型做路由分类判断文档类型用中等模型做结构化抽取用大模型做兜底和复杂推理。这样在成本和效果之间取得更优平衡。另一个方向是结合微调。热词里 qwen2.5-7b 微调行业大模型、大模型微调实战出现频率很高。如果你的任务非常垂直、格式非常固定微调一个小模型往往比 Prompt 调大模型更划算。微调的核心是构造高质量的指令数据格式和线上 Prompt 保持一致这样推理时可以直接复用。我自己在实际项目里的体会是Prompt 工程解决 80% 的问题微调解决剩下 20% 的硬骨头而模型选型决定了你这 80% 好不好解决。三者不是替代关系是递进关系。先把 Prompt 打磨到极限再判断是否需要微调最后根据业务量决定部署形态。这个顺序不能反反了就是浪费时间和算力。