这年头聊大语言模型的人比真正用它的人还多。我的日常工作就是帮团队评估和落地各种大语言模型从网页版聊天助手到本地部署的开源模型都碰过。这些年下来最让我头疼的不是模型不够强而是很多人高估了它的能力、低估了它的局限。这篇内容就当一份经验笔记整理一下大语言模型真正能干什么、死穴在哪、工程上怎么取长补短适合正在选型、接模型或者准备上生产的读者。1. 能力地图什么场景下大语言模型是合格的“打工人”在项目里我习惯把一个大语言模型当成一个转正前的新员工来考察它优势突出、资质惊人但纪律性和稳定性需要反复确认。先看正面清单再决定给它安排什么岗位。1.1 文本生成与理解从“接话”到“干活”的底层一跃要理解大语言模型强在哪得先看它的底子自回归语言建模简单说就是根据前文预测后文。这个目标曾经被批评“太简单”可偏偏是这样的简单目标在海量数据和大参数的双重叠加下催生了能力突变。Transformer自注意力机制能让模型在一句话里同时回头看十几个词在整篇文章里跨段落找线索。于是“接话”这种看起来基础的玩法升级成了摘要、改写、翻译、问答、情感判断、信息抽取等一堆实际任务。我在产品里用得最多的能力是理解类任务。比如用户反馈“我的券过期了但订单还在”旧规则系统需要维护一百多条关键词规则才敢对这句话归类语言模型只需要给它几个示例就能稳定分出“售后-优惠券-过期”。它能完成的判断已经接近“人读了能归类”的程度而背后其实是对语言分布的拟合——只要训练数据里类似表述足够多。1.2 代码、结构化输出和任务拆解我最常用的三个生产场景除了文本归类真正让我觉得大语言模型能进生产链路的是下面三类场景。第一类是代码生成。我维护日志解析和数据处理脚本时把样例日志塞给它让它生成解析代码通常第一版就能覆盖八成需求。第二类是结构化输出。大语言模型能把一段半结构化文本转换成JSON或CSV比如从聊天记录里抽取订单号、金额、客户意向这在过去要单独写抽取模块如今一条提示词就能办个开场。第三类是任务拆解。大语言模型不擅长一步完成很复杂的流程但擅长把大任务拆成小步骤再配合外部工具逐步执行。很多Agent框架走的就是这条路模型当“调度员”把步骤交给专门的模块去实现。但“能写代码”不等于“工程可靠”。代码生成对训练语料的覆盖率极其敏感接口很老或场景很小众时模型生成出来的往往是形似神不似的代码你得做好review和单测兜底。它给你节省的是“从空白页开始写”的启动成本而不是你不再需要审代码。1.3 别把“表现好”等同于“真的理解”一个很容易误导人的现象是模型在评测集上分数很高但在真实使用时处处抽风。原因在于评测集里的题目通常结构清晰、信息完整而真实用户的问题往往是残缺、模糊、带噪音的。模型在数据分布内的表现和分布外的表现差异非常大。适用场景越标准化成绩越好场景越奇葩崩塌得越快。所以我在团队里常说一句话“先给模型画一幅能力地图再决定让它做什么。”能做摘要、能做改写、能做语言分类但在多步推理和精确计算上一定要安排帮手。把这句话想清楚后面所有工程手段都会顺很多。2. 先天局限幻觉、算不准和数据倾斜我说大语言模型像“记忆力强但偶尔脑补的新员工”这句话不是玩笑。它的三大局限几乎都藏在它的训练机制里。2.1 幻觉它是如何做到一本正经地胡说八道的幻觉在学术上叫“事实性幻觉”模型生成了流畅但错误的内容。最常见的两类——编造事实和编造接口参数。我见过最离谱的一次是让模型写一个产品FAQ它把公司名字写对了把成立年份从1998年编成2008年语气还特别笃定。原因不难理解自回归训练只优化“下一个词的概率”。模型并不知道哪个说法是“真的”它只知道哪个说法在语料里更常见、跟当前上下文更顺。训练语料里出现很多“成立年份1998”这样的片段模型就会把这种模板套到其他实体上。幻觉从机制上就不可能完全消灭因为它对“真实”的理解本质只是对文字分布的记忆。好消息是虽然幻觉不能根治但在多数业务场景里可以被控制住。控制方法集中在两条路径第一条是让模型少承担“记忆工作”事实信息放到外部知识库里检索回来再给模型第二条是要求模型在不确定时直接说“不知道”而不是硬编。第二点靠提示词能部分实现但效果因模型而异得实测。2.2 数学与逻辑为什么它算不对三位数乘法我常说“模型不是计算器”这点值得展开。你用手算乘法时会逐位相乘并记住进位模型没有这样的程序性思维它是在概率空间里“猜结果长什么样”。遇到多位数乘法训练语料里样本少、模式多样正确答案的概率被稀释于是结果开始飘。逻辑任务同理。链式思考Chain-of-Thought为什么有效因为让模型生成中间步骤等于把它带到类似“逐位推进”的轨道上每一步的token概率都会根据前一步结果重新调整正确率明显提升。但它依然是一种“近似推理”步骤一多还是会累积错误。所以我的工程铁律是凡是需要100%正确率的计算一律不让模型直接给出数字而是让它生成计算代码交给真实计算环境执行。模型可以负责把“订单总额按10%折扣并加税”翻译成Python表达式但最终数字必须由解释器算出来。这是“能力边界”不是“模型bug”你只能换一种工作方式绕开它。2.3 数据倾斜训练语料的隐形成见比表面局限更难处理幻觉和算力问题至少还能靠外部工具缓解数据倾斜则是更难发现的坑。大模型的知识来自训练语料而真实世界的语料分布从来不均匀。热门领域术语、英文文本、主流文化里的常识它的表现远超冷门领域。举个实际例子同一套模型你让它写“办公园区停车位改造方案”可能头头是道但问它“一个四线城市新建物流园区的分拨节点怎么设计”它就只能拼凑出一堆通用物流知识甚至混入明显不适合当地规模的答案。这说明它的能力上限其实被训练数据的地域、语言、行业覆盖面锁死了。识别这种数据倾斜比一味追求更高参数量的模型更重要——有时候换一个领域微调模型比上一个更大的通用模型更管用。3. 争议区里的真实情况视觉模型、术语和本地部署能力边界附近的讨论往往最热闹也最容易让新人踩坑。视觉大语言模型到底“看见”了什么生成语言模型和大语言模型是不是一回事本地部署到底需要多大算力这些话题的答案直接决定你选型时会不会花冤枉钱。3.1 视觉大语言模型真看见了吗视觉大语言模型的主流结构是给语言模型接上视觉编码器图像先切成小块让视觉编码器转成向量再与文本序列拼在一起进入Transformer。从工程表现看它已经能看图回答问题、解读图表、做图文匹配这些能力放到两年前都还很新鲜。但“能回答图片问题”并不等同于“有视觉理解”。有研究团队做过对照实验给模型看和问题完全无关的图片甚至把图片模糊成马赛克模型还能给出相当靠谱的答案。这种“跳过了视觉、靠语言蒙答案”的现象本质上是因为模型在很多任务上依赖语料里的先验统计而不是真正分析图像内容。我实测中也发现把一张完全非典型的故障图发给它它常会往“最像”的常见故障上靠而不是基于像素证据推理。这里不是说视觉模型没用而是提醒你别对“视觉理解”这四个字抱太大期待。做图片质检、视觉问答类项目时图像部分尽量叠加独立规则或专用视觉模型兜底不要让大语言模型充当唯一的“眼睛”。3.2 生成语言模型和大语言模型是一个东西吗这个热词问题我隔三差五就被问一次。严格讲“生成语言模型”范围更大凡是把文本生成作为核心目标的模型都可算在内哪怕只有几MB参数只要按生成任务训练一学。而“大语言模型”突出的是规模百亿参数以上、海量语料预训练并因此涌现出指令跟随、少样本学习、多步推理等小模型不具备的能力。用类比来说生成语言模型像“会写字的工具”大语言模型像“经过大量通识训练的博学秘书”。现在能上新闻、能被接入业务系统的生成式语言模型基本全是大语言模型所以两个词混用也常见。但真要做方案时分清这一点很重要如果只需要做一句话分类这种轻量任务一个几亿参数的小模型可能又快又稳又便宜没必要扛着几百GB的大模型跑。3.3 本地部署大语言模型的算力账本“本地部署大语言模型”能持续成为热点说明不少人在问能不能把模型架到自己机器上摆脱按API付费。可行但要仔细算账。模型规模FP16权重8bit量化后典型部署成本7B约14GB约7GB单张24GB以下消费卡可量化跑14B约28GB约14GB需要24GB起的中高性能卡70B约140GB约70GB至少多卡或专业大显存环境上百B数百GB百GB以上基本告别单机消费级部署参数规模直接决定显存下限。以常见的70B模型为例FP16精度下权重占约140GB单张48GB显卡都放不下哪怕量化到8bit约70GB仍需要多卡协同推理。而7B到14B量级的模型量化后权重在4GB到16GB之间消费级GPU可以选择。算力约束下的资源配置我一般建议分三层普通问答、摘要、提取用7B/14B模型量化部署中等推理、复杂指令用32B或70B按需上卡只有最复杂或对延迟不敏感的任务才动用更大模型。这样能在可控算力池里把单位能力产出最大化。同时别忘做量化实测有些7B模型4bit量化后质量几乎不变有些直接变笨建议先在业务数据上跑一轮对比再定。补充一点现在连IDE和各类开发工具都在往“集成大语言模型”的方向卷有人问新版Visual Studio一类的环境怎么增强模型能力。我的体验是别把它当成一等公民把它当作一个挂了提示词、RAG和工具调用的插件来用能力边界和前面聊的完全一样。界面再花哨底层局限跑不掉。4. 工程实践怎么让一个会出错的模型稳定工作我见过不少团队模型选型时只看评测分数上线后靠运气。真正稳定的AI应用核心设计绝不是指望模型100%正确而是设计一套流程让错误变得可预期、可兜底、可回归。4.1 先做能力台账再谈模型选型我的做法是先拿真实业务数据建一个封闭评测集。不用大而全的公开榜单只需要五十到一百条真实输入标注好期望输出然后跑不同模型、不同版本记录四个维度格式正确率、内容正确率、指令跟随度、兜底触发率。格式正确率看它是不是总能按要求输出JSON或指定结构。内容正确率关注事实性错误的比例。指令跟随度看它是否严格遵循输出限制。兜底触发率看它在不确定时是否愿意说“不知道”。这份台账只要持续维护会比任何榜单都有价值。我遇到过“智商高但脾气大”的模型通用问题答得极好但就是把“纯JSON输出”当耳边风总喜欢在JSON外面包一层解释。这种事靠台账记录清楚上线前配上解析容错和few-shot修正能避开一大堆线上事故。4.2 提示词、RAG、工具调用三板斧而非三选一现在很多教程把提示词工程、RAG、工具调用分开讲我在实践中更多是把它们组合起来用。提示词是“怎么把任务说清楚”RAG是“怎么把事实数据塞进上下文”工具调用是“怎么让模型不硬算、不硬编”。一套我常用的结构是这样的系统提示词里明确角色、目标、输出格式、无法回答时怎么办在对话开头放相关知识片段或检索结果遇到需要精确计算的字段时直接给出“调用Python执行”的指令。三者配合下来模型负责写“汇报”代码负责算“数字”知识库负责当“证据”整体可靠性提升非常明显。提示词本身也要做版本管理。它不是一段写一次就完了的咒语每次模型升级后同样的提示词效果可能变化所以提示词也要纳入灰度发布体系。我现在习惯把每个生产用的提示词当成代码来维护每次改动都对应一次回归测试。4.3 上下文管理窗口很长不代表你能什么都往里丢前面说过长上下文存在“lost in the middle”的问题。我在实现时通常采用三步设计先对用户问题做意图识别再根据意图从知识库或历史记录里检索最相关的几段内容最后只把这些内容和最近几轮对话拼进上下文。在检索质量足够好的前提下把上下文控制在几千到一万token以内效果往往比盲目塞入十万token更稳定。上下文管理不只是“少放”还包括“放对位置”。关键约束放系统提示词里关键示例放用户消息前部不要把最重要的事实放在中段。这一条在实际调试里能救回很多一度看起来“模型变笨了”的case。4.4 灰度、兜底和回归没有绝对的准确率只有可接受的错误率最后是上线节奏。我的流程是新模型或新提示词先在5%流量里跑每日随机抽输出做bad case分析。bad case分成硬伤事实错、格式错和软伤语气差、不完整分别记录。如果硬伤比例超过团队能接受的阈值就回滚。对用户可见的场景我强制要求一个兜底层模型置信度低或检测到敏感话题时不直接回答而是转入预设模板或人工通道。不要把所有自由输出直接暴露给用户除非你能接受它在公开页面上胡言乱语。这套框架并不复杂但它恰恰是“大语言模型能力和局限”落到工程里的样子接受模型不完美然后通过系统和流程去弥补。按照我的经验真正值得投入精力的工作其实不在模型内部而在它的外围评测集、提示词版本、知识库、工具调用、兜底策略。这些事看起来没有“训练一个模型”那么高大上但决定了最终产品是稳还是崩。最后分享一条小技巧每次接入新模型时我先把旧版的bad case跑一遍专门看它有没有改掉老毛病。如果老毛病全改了但新出来一堆格式问题那也值得关注最怕的是老毛病没改新问题又来那种模型再刷榜我也不会上线。把“能力和局限”放进测试用例里是我这几年在大语言模型落地中觉得最有用的习惯。
大语言模型能力边界与工程落地：从幻觉到RAG的实践指南
这年头聊大语言模型的人比真正用它的人还多。我的日常工作就是帮团队评估和落地各种大语言模型从网页版聊天助手到本地部署的开源模型都碰过。这些年下来最让我头疼的不是模型不够强而是很多人高估了它的能力、低估了它的局限。这篇内容就当一份经验笔记整理一下大语言模型真正能干什么、死穴在哪、工程上怎么取长补短适合正在选型、接模型或者准备上生产的读者。1. 能力地图什么场景下大语言模型是合格的“打工人”在项目里我习惯把一个大语言模型当成一个转正前的新员工来考察它优势突出、资质惊人但纪律性和稳定性需要反复确认。先看正面清单再决定给它安排什么岗位。1.1 文本生成与理解从“接话”到“干活”的底层一跃要理解大语言模型强在哪得先看它的底子自回归语言建模简单说就是根据前文预测后文。这个目标曾经被批评“太简单”可偏偏是这样的简单目标在海量数据和大参数的双重叠加下催生了能力突变。Transformer自注意力机制能让模型在一句话里同时回头看十几个词在整篇文章里跨段落找线索。于是“接话”这种看起来基础的玩法升级成了摘要、改写、翻译、问答、情感判断、信息抽取等一堆实际任务。我在产品里用得最多的能力是理解类任务。比如用户反馈“我的券过期了但订单还在”旧规则系统需要维护一百多条关键词规则才敢对这句话归类语言模型只需要给它几个示例就能稳定分出“售后-优惠券-过期”。它能完成的判断已经接近“人读了能归类”的程度而背后其实是对语言分布的拟合——只要训练数据里类似表述足够多。1.2 代码、结构化输出和任务拆解我最常用的三个生产场景除了文本归类真正让我觉得大语言模型能进生产链路的是下面三类场景。第一类是代码生成。我维护日志解析和数据处理脚本时把样例日志塞给它让它生成解析代码通常第一版就能覆盖八成需求。第二类是结构化输出。大语言模型能把一段半结构化文本转换成JSON或CSV比如从聊天记录里抽取订单号、金额、客户意向这在过去要单独写抽取模块如今一条提示词就能办个开场。第三类是任务拆解。大语言模型不擅长一步完成很复杂的流程但擅长把大任务拆成小步骤再配合外部工具逐步执行。很多Agent框架走的就是这条路模型当“调度员”把步骤交给专门的模块去实现。但“能写代码”不等于“工程可靠”。代码生成对训练语料的覆盖率极其敏感接口很老或场景很小众时模型生成出来的往往是形似神不似的代码你得做好review和单测兜底。它给你节省的是“从空白页开始写”的启动成本而不是你不再需要审代码。1.3 别把“表现好”等同于“真的理解”一个很容易误导人的现象是模型在评测集上分数很高但在真实使用时处处抽风。原因在于评测集里的题目通常结构清晰、信息完整而真实用户的问题往往是残缺、模糊、带噪音的。模型在数据分布内的表现和分布外的表现差异非常大。适用场景越标准化成绩越好场景越奇葩崩塌得越快。所以我在团队里常说一句话“先给模型画一幅能力地图再决定让它做什么。”能做摘要、能做改写、能做语言分类但在多步推理和精确计算上一定要安排帮手。把这句话想清楚后面所有工程手段都会顺很多。2. 先天局限幻觉、算不准和数据倾斜我说大语言模型像“记忆力强但偶尔脑补的新员工”这句话不是玩笑。它的三大局限几乎都藏在它的训练机制里。2.1 幻觉它是如何做到一本正经地胡说八道的幻觉在学术上叫“事实性幻觉”模型生成了流畅但错误的内容。最常见的两类——编造事实和编造接口参数。我见过最离谱的一次是让模型写一个产品FAQ它把公司名字写对了把成立年份从1998年编成2008年语气还特别笃定。原因不难理解自回归训练只优化“下一个词的概率”。模型并不知道哪个说法是“真的”它只知道哪个说法在语料里更常见、跟当前上下文更顺。训练语料里出现很多“成立年份1998”这样的片段模型就会把这种模板套到其他实体上。幻觉从机制上就不可能完全消灭因为它对“真实”的理解本质只是对文字分布的记忆。好消息是虽然幻觉不能根治但在多数业务场景里可以被控制住。控制方法集中在两条路径第一条是让模型少承担“记忆工作”事实信息放到外部知识库里检索回来再给模型第二条是要求模型在不确定时直接说“不知道”而不是硬编。第二点靠提示词能部分实现但效果因模型而异得实测。2.2 数学与逻辑为什么它算不对三位数乘法我常说“模型不是计算器”这点值得展开。你用手算乘法时会逐位相乘并记住进位模型没有这样的程序性思维它是在概率空间里“猜结果长什么样”。遇到多位数乘法训练语料里样本少、模式多样正确答案的概率被稀释于是结果开始飘。逻辑任务同理。链式思考Chain-of-Thought为什么有效因为让模型生成中间步骤等于把它带到类似“逐位推进”的轨道上每一步的token概率都会根据前一步结果重新调整正确率明显提升。但它依然是一种“近似推理”步骤一多还是会累积错误。所以我的工程铁律是凡是需要100%正确率的计算一律不让模型直接给出数字而是让它生成计算代码交给真实计算环境执行。模型可以负责把“订单总额按10%折扣并加税”翻译成Python表达式但最终数字必须由解释器算出来。这是“能力边界”不是“模型bug”你只能换一种工作方式绕开它。2.3 数据倾斜训练语料的隐形成见比表面局限更难处理幻觉和算力问题至少还能靠外部工具缓解数据倾斜则是更难发现的坑。大模型的知识来自训练语料而真实世界的语料分布从来不均匀。热门领域术语、英文文本、主流文化里的常识它的表现远超冷门领域。举个实际例子同一套模型你让它写“办公园区停车位改造方案”可能头头是道但问它“一个四线城市新建物流园区的分拨节点怎么设计”它就只能拼凑出一堆通用物流知识甚至混入明显不适合当地规模的答案。这说明它的能力上限其实被训练数据的地域、语言、行业覆盖面锁死了。识别这种数据倾斜比一味追求更高参数量的模型更重要——有时候换一个领域微调模型比上一个更大的通用模型更管用。3. 争议区里的真实情况视觉模型、术语和本地部署能力边界附近的讨论往往最热闹也最容易让新人踩坑。视觉大语言模型到底“看见”了什么生成语言模型和大语言模型是不是一回事本地部署到底需要多大算力这些话题的答案直接决定你选型时会不会花冤枉钱。3.1 视觉大语言模型真看见了吗视觉大语言模型的主流结构是给语言模型接上视觉编码器图像先切成小块让视觉编码器转成向量再与文本序列拼在一起进入Transformer。从工程表现看它已经能看图回答问题、解读图表、做图文匹配这些能力放到两年前都还很新鲜。但“能回答图片问题”并不等同于“有视觉理解”。有研究团队做过对照实验给模型看和问题完全无关的图片甚至把图片模糊成马赛克模型还能给出相当靠谱的答案。这种“跳过了视觉、靠语言蒙答案”的现象本质上是因为模型在很多任务上依赖语料里的先验统计而不是真正分析图像内容。我实测中也发现把一张完全非典型的故障图发给它它常会往“最像”的常见故障上靠而不是基于像素证据推理。这里不是说视觉模型没用而是提醒你别对“视觉理解”这四个字抱太大期待。做图片质检、视觉问答类项目时图像部分尽量叠加独立规则或专用视觉模型兜底不要让大语言模型充当唯一的“眼睛”。3.2 生成语言模型和大语言模型是一个东西吗这个热词问题我隔三差五就被问一次。严格讲“生成语言模型”范围更大凡是把文本生成作为核心目标的模型都可算在内哪怕只有几MB参数只要按生成任务训练一学。而“大语言模型”突出的是规模百亿参数以上、海量语料预训练并因此涌现出指令跟随、少样本学习、多步推理等小模型不具备的能力。用类比来说生成语言模型像“会写字的工具”大语言模型像“经过大量通识训练的博学秘书”。现在能上新闻、能被接入业务系统的生成式语言模型基本全是大语言模型所以两个词混用也常见。但真要做方案时分清这一点很重要如果只需要做一句话分类这种轻量任务一个几亿参数的小模型可能又快又稳又便宜没必要扛着几百GB的大模型跑。3.3 本地部署大语言模型的算力账本“本地部署大语言模型”能持续成为热点说明不少人在问能不能把模型架到自己机器上摆脱按API付费。可行但要仔细算账。模型规模FP16权重8bit量化后典型部署成本7B约14GB约7GB单张24GB以下消费卡可量化跑14B约28GB约14GB需要24GB起的中高性能卡70B约140GB约70GB至少多卡或专业大显存环境上百B数百GB百GB以上基本告别单机消费级部署参数规模直接决定显存下限。以常见的70B模型为例FP16精度下权重占约140GB单张48GB显卡都放不下哪怕量化到8bit约70GB仍需要多卡协同推理。而7B到14B量级的模型量化后权重在4GB到16GB之间消费级GPU可以选择。算力约束下的资源配置我一般建议分三层普通问答、摘要、提取用7B/14B模型量化部署中等推理、复杂指令用32B或70B按需上卡只有最复杂或对延迟不敏感的任务才动用更大模型。这样能在可控算力池里把单位能力产出最大化。同时别忘做量化实测有些7B模型4bit量化后质量几乎不变有些直接变笨建议先在业务数据上跑一轮对比再定。补充一点现在连IDE和各类开发工具都在往“集成大语言模型”的方向卷有人问新版Visual Studio一类的环境怎么增强模型能力。我的体验是别把它当成一等公民把它当作一个挂了提示词、RAG和工具调用的插件来用能力边界和前面聊的完全一样。界面再花哨底层局限跑不掉。4. 工程实践怎么让一个会出错的模型稳定工作我见过不少团队模型选型时只看评测分数上线后靠运气。真正稳定的AI应用核心设计绝不是指望模型100%正确而是设计一套流程让错误变得可预期、可兜底、可回归。4.1 先做能力台账再谈模型选型我的做法是先拿真实业务数据建一个封闭评测集。不用大而全的公开榜单只需要五十到一百条真实输入标注好期望输出然后跑不同模型、不同版本记录四个维度格式正确率、内容正确率、指令跟随度、兜底触发率。格式正确率看它是不是总能按要求输出JSON或指定结构。内容正确率关注事实性错误的比例。指令跟随度看它是否严格遵循输出限制。兜底触发率看它在不确定时是否愿意说“不知道”。这份台账只要持续维护会比任何榜单都有价值。我遇到过“智商高但脾气大”的模型通用问题答得极好但就是把“纯JSON输出”当耳边风总喜欢在JSON外面包一层解释。这种事靠台账记录清楚上线前配上解析容错和few-shot修正能避开一大堆线上事故。4.2 提示词、RAG、工具调用三板斧而非三选一现在很多教程把提示词工程、RAG、工具调用分开讲我在实践中更多是把它们组合起来用。提示词是“怎么把任务说清楚”RAG是“怎么把事实数据塞进上下文”工具调用是“怎么让模型不硬算、不硬编”。一套我常用的结构是这样的系统提示词里明确角色、目标、输出格式、无法回答时怎么办在对话开头放相关知识片段或检索结果遇到需要精确计算的字段时直接给出“调用Python执行”的指令。三者配合下来模型负责写“汇报”代码负责算“数字”知识库负责当“证据”整体可靠性提升非常明显。提示词本身也要做版本管理。它不是一段写一次就完了的咒语每次模型升级后同样的提示词效果可能变化所以提示词也要纳入灰度发布体系。我现在习惯把每个生产用的提示词当成代码来维护每次改动都对应一次回归测试。4.3 上下文管理窗口很长不代表你能什么都往里丢前面说过长上下文存在“lost in the middle”的问题。我在实现时通常采用三步设计先对用户问题做意图识别再根据意图从知识库或历史记录里检索最相关的几段内容最后只把这些内容和最近几轮对话拼进上下文。在检索质量足够好的前提下把上下文控制在几千到一万token以内效果往往比盲目塞入十万token更稳定。上下文管理不只是“少放”还包括“放对位置”。关键约束放系统提示词里关键示例放用户消息前部不要把最重要的事实放在中段。这一条在实际调试里能救回很多一度看起来“模型变笨了”的case。4.4 灰度、兜底和回归没有绝对的准确率只有可接受的错误率最后是上线节奏。我的流程是新模型或新提示词先在5%流量里跑每日随机抽输出做bad case分析。bad case分成硬伤事实错、格式错和软伤语气差、不完整分别记录。如果硬伤比例超过团队能接受的阈值就回滚。对用户可见的场景我强制要求一个兜底层模型置信度低或检测到敏感话题时不直接回答而是转入预设模板或人工通道。不要把所有自由输出直接暴露给用户除非你能接受它在公开页面上胡言乱语。这套框架并不复杂但它恰恰是“大语言模型能力和局限”落到工程里的样子接受模型不完美然后通过系统和流程去弥补。按照我的经验真正值得投入精力的工作其实不在模型内部而在它的外围评测集、提示词版本、知识库、工具调用、兜底策略。这些事看起来没有“训练一个模型”那么高大上但决定了最终产品是稳还是崩。最后分享一条小技巧每次接入新模型时我先把旧版的bad case跑一遍专门看它有没有改掉老毛病。如果老毛病全改了但新出来一堆格式问题那也值得关注最怕的是老毛病没改新问题又来那种模型再刷榜我也不会上线。把“能力和局限”放进测试用例里是我这几年在大语言模型落地中觉得最有用的习惯。
