LLM 这东西刚接触的人容易走两个极端要么把它当成万能问答机器随便丢个问题就指望它给出能直接落地的方案要么被各种术语吓住觉得非得懂 Transformer 架构、会调参、有 GPU 集群才能用。我带了几个刚入行的同事之后发现真正卡住大多数人的不是模型本身而是“不知道在什么场景下该用哪种调用方式、参数怎么设、结果怎么验证”。这篇就围绕 LLM 的实际使用方法展开从最基础的对话调用到结构化输出、本地部署、精调、评测把每个环节里我踩过的坑和验证过的做法都摊开讲。不管你是刚拿到 API Key 的新手还是已经在项目里集成过 LLM 但效果不稳定的开发者都能从中找到可以直接抄的配置和思路。1. 先把 LLM 当成一个“概率补全引擎”来理解1.1 它到底在做什么从 token 预测说起很多人第一次用 LLM 时脑子里默认它像数据库查询——输入问题取出答案。实际完全不是。LLM 的本质是自回归的 token 预测器给它一段文本它计算下一个 token 在词表上的概率分布选一个出来拼回输入再预测下一个如此循环。你看到的“回答”是这一步步采样拼出来的结果。这个认知直接决定了使用方法。比如你问“中国的首都是哪里”它输出“北京”不是因为查了表而是因为在它的参数里“中国的首都”后面接“北京”的概率远高于其他词。理解了这一点你就能明白为什么同样的 prompt 多次调用结果可能不同——采样有随机性它可能“一本正经地胡说”——概率高不等于事实正确上下文里给的信息会强烈影响输出——因为那些 token 直接参与了后续概率计算。我一般会跟新人打个比方LLM 像一个读过海量文本、但记性不太精确的实习生。你给的任务描述越清楚、参考资料越具体它干得越靠谱你含糊其辞它就自由发挥。1.2 三个必须记住的参数temperature、top_p、max_tokens调用任何 LLM API绕不开这几个采样参数。它们不是玄学每个都有明确的物理含义。参数作用典型取值什么时候调temperature缩放 logits控制分布陡峭程度0~2常用 0~1要确定性输出调低要创意调高top_p核采样只从累积概率前 p 的 token 里选0.1~1和 temperature 二选一调别同时大改max_tokens限制输出长度按任务设防止无限输出烧钱temperature 的机制值得多说一句。模型输出的是每个 token 的原始分数logitstemperature 做的是logits / T。T 趋近 0 时分布变得极尖锐几乎总是选概率最高的那个 token输出就稳定、可复现T 变大分布被压平低概率 token 也有机会被选中输出就多样甚至跑偏。我的经验是做信息抽取、分类、代码生成这类任务temperature 设 0 到 0.3写文案、头脑风暴设 0.7 到 1.0。top_p 我通常保持默认很多 API 是 1只在需要精细控制多样性时才动而且不同时大幅调 temperature 和 top_p否则两个随机源叠加结果很难复现。注意temperature0 也不保证 100% 可复现。浮点运算顺序、并行计算、服务端批处理都可能导致微小差异。要严格复现得靠固定 seed如果 API 支持加缓存。1.3 上下文窗口不是越大越好现在动辄 128K、200K 上下文窗口很多人恨不得把整个知识库塞进去。我实测下来长上下文有两个隐形成本一是费用按 token 算塞得越多越贵二是“中间遗忘”现象——模型对上下文开头和结尾的信息利用得好中间大段内容容易被忽略。所以正确做法不是无脑堆上下文而是做检索增强RAG先用向量检索或关键词检索从知识库里捞出最相关的几段再拼进 prompt。这样既省 token又提高准确率。我做过对比同样一个问题把 50 页文档全塞进去 vs 检索出最相关的 3 段后者的回答准确率反而更高。2. 对话调用的工程化从能跑到稳定2.1 消息角色的分工system、user、assistant主流对话 API 用消息数组组织输入每条消息有 role。三个角色各司其职system设定全局行为比如“你是一个严谨的技术助手回答必须给出依据”。它优先级最高但也不是绝对服从。user用户输入。assistant模型的历史回复多轮对话时要把之前的回复也带上模型才知道上下文。新手常犯的错是把所有指令都塞进 user 消息。我建议把稳定的行为约束放 system把当次任务放 user。比如 system 写“输出必须是 JSON不要有多余文字”user 写具体要抽取的内容。这样多轮对话时行为约束不会丢。多轮对话还有个坑历史消息会不断累积token 越用越多。我的做法是保留最近 N 轮或者对早期对话做摘要压缩。摘要可以用 LLM 自己生成比如“把以下对话压缩成 100 字以内的要点”。2.2 结构化输出让 LLM 返回能直接解析的数据LLM 返回自然语言但程序需要结构化数据。最朴素的做法是在 prompt 里写“请返回 JSON”然后手动解析。问题是模型经常在 JSON 外面加解释文字或者字段名对不上解析直接崩。我踩过最惨的一次是线上服务因为模型多输出了一句“好的以下是结果”JSON 解析失败整个请求链路报错。后来我总结了几层防护优先用 API 原生的结构化输出能力。现在很多平台支持 JSON mode 或 function calling / tool use模型被约束只能输出合法 JSON这是最稳的。如果只能用 prompt 约束就在 system 里明确“只输出 JSON第一个字符是 {最后一个字符是 }不要任何解释”。解析时做容错用正则先提取第一个{到最后一个}之间的内容再解析解析失败就重试一次重试时把错误信息也带上让模型自己修。下面是一个带容错的解析示例import json import re def parse_llm_json(text): # 先尝试直接解析 try: return json.loads(text) except json.JSONDecodeError: pass # 提取花括号内容再试 match re.search(r\{.*\}, text, re.DOTALL) if match: try: return json.loads(match.group()) except json.JSONDecodeError: pass return None配合重试逻辑结构化输出的成功率能从 80% 出头提到 99% 以上。2.3 重试与超时别让一次失败拖垮整个请求LLM 调用是网络请求会超时、会限流、会返回 5xx。我见过不少项目直接裸调一次失败就抛异常给用户。正确做法是指数退避重试失败后等 1 秒、2 秒、4 秒再试最多试 3 到 5 次。但要注意不是所有错误都值得重试。限流429和服务器错误5xx可以重试参数错误400、鉴权失败401重试多少次都没用应该直接报错。另外如果请求已经产生了费用但响应超时重试可能导致重复计费这个要在业务层做幂等处理。超时时间也要设合理。生成类任务写长文可能几十秒抽取类任务几秒就够。我一般设 30 秒超时超过就放弃重试避免用户等太久。3. 本地部署与模型选择什么时候该自己跑3.1 云端 API 和本地部署的取舍不是所有场景都适合调云端 API。我整理了一个决策表维度云端 API本地部署成本按 token 付费量大贵一次性硬件投入长期便宜数据隐私数据出本地数据不出本地延迟受网络影响局域网内低延迟模型能力通常是最强模型受硬件限制多为中小模型运维无需运维要管显存、并发、升级我的判断标准很简单数据敏感、调用量大、对延迟敏感三者占一个就考虑本地部署。比如处理内部合同、医疗记录数据不能出内网那就本地跑。如果只是偶尔用用、要最强能力云端 API 更划算。3.2 GGUF 格式与量化让模型跑在消费级硬件上本地部署绕不开量化。原始模型动辄几十 GB消费级显卡装不下。量化就是把模型权重从 16 位浮点压到 8 位、4 位甚至更低牺牲一点精度换显存和速度。GGUF 是目前流行的格式配合 llama.cpp 这类推理引擎能在 CPU 和 GPU 混合环境下跑。量化等级常见的有 Q4_K_M、Q5_K_M、Q8_0 等。我的经验Q4_K_M性价比最高4 位量化里质量损失小7B 模型大概 4~5GB普通显卡能跑。Q5_K_M质量更好显存多花一点推荐。Q8_0接近原始精度但显存占用大除非硬件充裕否则没必要。选量化等级时先看显存再在能装下的等级里选最高的。别为了省一点显存选 Q2、Q3质量掉得厉害得不偿失。3.3 安卓端本地运行可行但有边界现在确实有能在安卓上跑 GGUF 模型的软件支持较老的安卓版本。但要说清楚边界手机端跑的是小参数模型1B~7B能力有限适合离线问答、简单文本处理别指望它做复杂推理。实际使用中内存是最大瓶颈。7B 模型 Q4 量化也要 4GB 以上内存加上系统占用8GB 内存的手机跑起来很吃力。我的建议是手机端优先选 1B~3B 的小模型响应快、内存压力小做本地化的简单任务足够。真要复杂任务还是走云端或桌面端。4. 精调与评测让模型贴合你的场景4.1 什么时候该精调什么时候不该很多人一上来就想精调觉得这样模型才“懂”自己的业务。我的观点是精调是最后手段不是第一选择。优先级应该是优化 prompt把指令写清楚、给例子few-shot能解决大部分问题。RAG知识类问题用检索增强比精调更灵活知识更新也方便。精调当任务有固定格式、固定风格且 prompt 怎么调都达不到要求时才考虑。精调的成本不只是训练还有数据准备、评测、后续维护。而且精调后的模型可能在其他任务上能力下降灾难性遗忘。所以先穷尽 prompt 和 RAG 的手段再上精调。4.2 用聊天记录精调数据清洗比训练更重要用聊天记录精调是个常见思路因为数据现成。但原始聊天记录直接拿来训练效果往往很差。问题在于噪声大闲聊、表情、错别字混在一起格式乱没有统一的消息角色标注质量参差有些对话本身就没营养。我的处理流程是先按对话轮次切分过滤掉太短、无意义的对话然后统一成 system/user/assistant 的格式再人工抽检一批把明显有问题的剔除。数据质量决定精调上限宁可数据少一点、干净一点也别用一堆垃圾数据硬训。训练时学习率要设小比如 1e-5 到 2e-5epoch 别太多1 到 3 轮否则容易过拟合。训完一定要在留出的验证集上测别只看训练 loss。4.3 LLM as Judge用模型评测模型模型输出好不好人工评太慢。现在流行用 LLM 当裁判LLM as Judge让一个强模型给另一个模型的输出打分。做法是给裁判模型一个评分标准比如“从准确性、完整性、格式规范三个维度各打 1~5 分”然后让它输出分数和理由。这方法好用但有几个坑位置偏见裁判可能偏向第一个出现的答案。解决办法是交换顺序评两次取平均。长度偏见长答案容易被认为更详细。要在评分标准里明确“简洁性也计入”。裁判模型能力用弱模型当裁判评不准。尽量用比被测模型更强的模型当裁判。我一般会把 LLM as Judge 和少量人工评测结合先用 LLM 批量打分筛出低分和分数异常的样本再人工复核。这样效率和质量兼顾。5. 智能体与容错构建可靠系统的关键5.1 智能体的自主容错控制LLM 智能体Agent能自主调用工具、多步推理但可靠性是最大挑战。一个环节出错后面全崩。自主容错控制的核心思路是让智能体自己检测异常并恢复。具体做法包括结果校验工具返回后让模型判断结果是否合理。比如查天气返回“-999 度”明显异常触发重试或换工具。步骤回滚多步任务中某步失败回到上一个稳定状态重新规划而不是从头再来。超时与预算控制给智能体设最大步数和最大 token 预算防止无限循环烧钱。我做过一个多步信息查询的智能体最初没设步数上限遇到一个查不到的信息就反复换关键词重试烧了不少 token。后来加了“同一子任务最多重试 2 次超了就报告失败并继续下一步”稳定性大幅提升。5.2 记忆与知识库投毒的风险智能体如果有长期记忆或外部知识库就存在被污染的风险。攻击者可能往知识库里注入恶意内容诱导智能体做出错误决策。这不是危言耸听是实际存在的安全议题。防护思路知识库写入做审核不是谁都能往记忆里写东西加权限和内容过滤。检索结果做可信度排序优先用高可信来源的内容。关键决策加人工确认涉及资金、权限变更等敏感操作智能体只能建议不能直接执行。这些措施会增加一些复杂度但对于要上生产的智能体系统是必须的。5.3 请求失败的常见原因排查“LLM request failed: provider rejected the request schema or tool payload” 这类报错很常见通常是请求格式不符合 API 规范。排查顺序检查消息格式role 是否是 API 支持的值content 是否是字符串或正确的多模态结构。检查工具定义function calling 的 schema 是否符合 JSON Schema 规范必填字段有没有漏。检查 token 数输入是否超过模型上下文上限。检查参数范围temperature、top_p 是否在合法区间。我遇到最多的是工具 schema 里参数类型写错比如该是 string 写成了 numberAPI 直接拒绝。把 schema 打印出来对照文档逐字段核对基本都能定位。6. 一些零散但实用的经验6.1 基于 LLM 的单元测试用 LLM 生成单元测试是个提效手段但别直接信它生成的测试。我的做法是让 LLM 生成测试用例然后人工审查边界条件是否覆盖、断言是否合理。LLM 容易生成“看起来对但没测到关键逻辑”的测试。把它当草稿生成器不是最终答案。6.2 空间 LLM 与多模态Spatial LLM 这类涉及空间理解的多模态模型使用方法上和纯文本 LLM 有区别输入要带图像或 3D 数据prompt 要描述空间关系。目前这类模型在专业领域机器人、自动驾驶用得多通用场景还不成熟。如果你的任务涉及空间推理先确认模型是否真的支持别拿纯文本模型硬套。6.3 关于内容安全的边界不管用什么 LLM输出内容都要过一遍安全过滤。尤其是面向用户的产品模型可能生成不当内容。我的做法是在输出后加一层规则过滤或分类模型把明显有问题的内容拦下来。这不是可选项是必选项。6.4 成本控制的几个习惯缓存相同或相似的请求结果缓存起来别重复调用。分级简单任务用小模型复杂任务才用大模型。监控记录每次调用的 token 数和费用设预算告警。压缩 prompt定期审查 prompt去掉冗余描述。我见过一个项目因为 prompt 里塞了大量重复的示例每月费用翻了好几倍。精简 prompt 之后效果没降费用降了一半多。6.5 模型选型的现实考量选模型不是越强越好要看任务需求、成本、延迟、数据合规。我的经验是先用最强模型跑通流程、确定效果上限再逐步替换成更便宜的小模型看效果能接受就换。这样既知道天花板在哪又能控制成本。别一上来就用小模型效果不好你都不知道是模型不行还是 prompt 不行。LLM 的使用方法说到底是一套工程实践核心是理解它的概率本质、用工程手段约束它的不确定性、用评测和监控保证效果稳定。上面这些是我在实际项目里反复验证过的做法你可以根据自己的场景调整参数和流程。真正上手跑几个任务比看十篇教程都管用。 LLM 工程化实战：从对话调用到精调评测的完整指南
LLM 这东西刚接触的人容易走两个极端要么把它当成万能问答机器随便丢个问题就指望它给出能直接落地的方案要么被各种术语吓住觉得非得懂 Transformer 架构、会调参、有 GPU 集群才能用。我带了几个刚入行的同事之后发现真正卡住大多数人的不是模型本身而是“不知道在什么场景下该用哪种调用方式、参数怎么设、结果怎么验证”。这篇就围绕 LLM 的实际使用方法展开从最基础的对话调用到结构化输出、本地部署、精调、评测把每个环节里我踩过的坑和验证过的做法都摊开讲。不管你是刚拿到 API Key 的新手还是已经在项目里集成过 LLM 但效果不稳定的开发者都能从中找到可以直接抄的配置和思路。1. 先把 LLM 当成一个“概率补全引擎”来理解1.1 它到底在做什么从 token 预测说起很多人第一次用 LLM 时脑子里默认它像数据库查询——输入问题取出答案。实际完全不是。LLM 的本质是自回归的 token 预测器给它一段文本它计算下一个 token 在词表上的概率分布选一个出来拼回输入再预测下一个如此循环。你看到的“回答”是这一步步采样拼出来的结果。这个认知直接决定了使用方法。比如你问“中国的首都是哪里”它输出“北京”不是因为查了表而是因为在它的参数里“中国的首都”后面接“北京”的概率远高于其他词。理解了这一点你就能明白为什么同样的 prompt 多次调用结果可能不同——采样有随机性它可能“一本正经地胡说”——概率高不等于事实正确上下文里给的信息会强烈影响输出——因为那些 token 直接参与了后续概率计算。我一般会跟新人打个比方LLM 像一个读过海量文本、但记性不太精确的实习生。你给的任务描述越清楚、参考资料越具体它干得越靠谱你含糊其辞它就自由发挥。1.2 三个必须记住的参数temperature、top_p、max_tokens调用任何 LLM API绕不开这几个采样参数。它们不是玄学每个都有明确的物理含义。参数作用典型取值什么时候调temperature缩放 logits控制分布陡峭程度0~2常用 0~1要确定性输出调低要创意调高top_p核采样只从累积概率前 p 的 token 里选0.1~1和 temperature 二选一调别同时大改max_tokens限制输出长度按任务设防止无限输出烧钱temperature 的机制值得多说一句。模型输出的是每个 token 的原始分数logitstemperature 做的是logits / T。T 趋近 0 时分布变得极尖锐几乎总是选概率最高的那个 token输出就稳定、可复现T 变大分布被压平低概率 token 也有机会被选中输出就多样甚至跑偏。我的经验是做信息抽取、分类、代码生成这类任务temperature 设 0 到 0.3写文案、头脑风暴设 0.7 到 1.0。top_p 我通常保持默认很多 API 是 1只在需要精细控制多样性时才动而且不同时大幅调 temperature 和 top_p否则两个随机源叠加结果很难复现。注意temperature0 也不保证 100% 可复现。浮点运算顺序、并行计算、服务端批处理都可能导致微小差异。要严格复现得靠固定 seed如果 API 支持加缓存。1.3 上下文窗口不是越大越好现在动辄 128K、200K 上下文窗口很多人恨不得把整个知识库塞进去。我实测下来长上下文有两个隐形成本一是费用按 token 算塞得越多越贵二是“中间遗忘”现象——模型对上下文开头和结尾的信息利用得好中间大段内容容易被忽略。所以正确做法不是无脑堆上下文而是做检索增强RAG先用向量检索或关键词检索从知识库里捞出最相关的几段再拼进 prompt。这样既省 token又提高准确率。我做过对比同样一个问题把 50 页文档全塞进去 vs 检索出最相关的 3 段后者的回答准确率反而更高。2. 对话调用的工程化从能跑到稳定2.1 消息角色的分工system、user、assistant主流对话 API 用消息数组组织输入每条消息有 role。三个角色各司其职system设定全局行为比如“你是一个严谨的技术助手回答必须给出依据”。它优先级最高但也不是绝对服从。user用户输入。assistant模型的历史回复多轮对话时要把之前的回复也带上模型才知道上下文。新手常犯的错是把所有指令都塞进 user 消息。我建议把稳定的行为约束放 system把当次任务放 user。比如 system 写“输出必须是 JSON不要有多余文字”user 写具体要抽取的内容。这样多轮对话时行为约束不会丢。多轮对话还有个坑历史消息会不断累积token 越用越多。我的做法是保留最近 N 轮或者对早期对话做摘要压缩。摘要可以用 LLM 自己生成比如“把以下对话压缩成 100 字以内的要点”。2.2 结构化输出让 LLM 返回能直接解析的数据LLM 返回自然语言但程序需要结构化数据。最朴素的做法是在 prompt 里写“请返回 JSON”然后手动解析。问题是模型经常在 JSON 外面加解释文字或者字段名对不上解析直接崩。我踩过最惨的一次是线上服务因为模型多输出了一句“好的以下是结果”JSON 解析失败整个请求链路报错。后来我总结了几层防护优先用 API 原生的结构化输出能力。现在很多平台支持 JSON mode 或 function calling / tool use模型被约束只能输出合法 JSON这是最稳的。如果只能用 prompt 约束就在 system 里明确“只输出 JSON第一个字符是 {最后一个字符是 }不要任何解释”。解析时做容错用正则先提取第一个{到最后一个}之间的内容再解析解析失败就重试一次重试时把错误信息也带上让模型自己修。下面是一个带容错的解析示例import json import re def parse_llm_json(text): # 先尝试直接解析 try: return json.loads(text) except json.JSONDecodeError: pass # 提取花括号内容再试 match re.search(r\{.*\}, text, re.DOTALL) if match: try: return json.loads(match.group()) except json.JSONDecodeError: pass return None配合重试逻辑结构化输出的成功率能从 80% 出头提到 99% 以上。2.3 重试与超时别让一次失败拖垮整个请求LLM 调用是网络请求会超时、会限流、会返回 5xx。我见过不少项目直接裸调一次失败就抛异常给用户。正确做法是指数退避重试失败后等 1 秒、2 秒、4 秒再试最多试 3 到 5 次。但要注意不是所有错误都值得重试。限流429和服务器错误5xx可以重试参数错误400、鉴权失败401重试多少次都没用应该直接报错。另外如果请求已经产生了费用但响应超时重试可能导致重复计费这个要在业务层做幂等处理。超时时间也要设合理。生成类任务写长文可能几十秒抽取类任务几秒就够。我一般设 30 秒超时超过就放弃重试避免用户等太久。3. 本地部署与模型选择什么时候该自己跑3.1 云端 API 和本地部署的取舍不是所有场景都适合调云端 API。我整理了一个决策表维度云端 API本地部署成本按 token 付费量大贵一次性硬件投入长期便宜数据隐私数据出本地数据不出本地延迟受网络影响局域网内低延迟模型能力通常是最强模型受硬件限制多为中小模型运维无需运维要管显存、并发、升级我的判断标准很简单数据敏感、调用量大、对延迟敏感三者占一个就考虑本地部署。比如处理内部合同、医疗记录数据不能出内网那就本地跑。如果只是偶尔用用、要最强能力云端 API 更划算。3.2 GGUF 格式与量化让模型跑在消费级硬件上本地部署绕不开量化。原始模型动辄几十 GB消费级显卡装不下。量化就是把模型权重从 16 位浮点压到 8 位、4 位甚至更低牺牲一点精度换显存和速度。GGUF 是目前流行的格式配合 llama.cpp 这类推理引擎能在 CPU 和 GPU 混合环境下跑。量化等级常见的有 Q4_K_M、Q5_K_M、Q8_0 等。我的经验Q4_K_M性价比最高4 位量化里质量损失小7B 模型大概 4~5GB普通显卡能跑。Q5_K_M质量更好显存多花一点推荐。Q8_0接近原始精度但显存占用大除非硬件充裕否则没必要。选量化等级时先看显存再在能装下的等级里选最高的。别为了省一点显存选 Q2、Q3质量掉得厉害得不偿失。3.3 安卓端本地运行可行但有边界现在确实有能在安卓上跑 GGUF 模型的软件支持较老的安卓版本。但要说清楚边界手机端跑的是小参数模型1B~7B能力有限适合离线问答、简单文本处理别指望它做复杂推理。实际使用中内存是最大瓶颈。7B 模型 Q4 量化也要 4GB 以上内存加上系统占用8GB 内存的手机跑起来很吃力。我的建议是手机端优先选 1B~3B 的小模型响应快、内存压力小做本地化的简单任务足够。真要复杂任务还是走云端或桌面端。4. 精调与评测让模型贴合你的场景4.1 什么时候该精调什么时候不该很多人一上来就想精调觉得这样模型才“懂”自己的业务。我的观点是精调是最后手段不是第一选择。优先级应该是优化 prompt把指令写清楚、给例子few-shot能解决大部分问题。RAG知识类问题用检索增强比精调更灵活知识更新也方便。精调当任务有固定格式、固定风格且 prompt 怎么调都达不到要求时才考虑。精调的成本不只是训练还有数据准备、评测、后续维护。而且精调后的模型可能在其他任务上能力下降灾难性遗忘。所以先穷尽 prompt 和 RAG 的手段再上精调。4.2 用聊天记录精调数据清洗比训练更重要用聊天记录精调是个常见思路因为数据现成。但原始聊天记录直接拿来训练效果往往很差。问题在于噪声大闲聊、表情、错别字混在一起格式乱没有统一的消息角色标注质量参差有些对话本身就没营养。我的处理流程是先按对话轮次切分过滤掉太短、无意义的对话然后统一成 system/user/assistant 的格式再人工抽检一批把明显有问题的剔除。数据质量决定精调上限宁可数据少一点、干净一点也别用一堆垃圾数据硬训。训练时学习率要设小比如 1e-5 到 2e-5epoch 别太多1 到 3 轮否则容易过拟合。训完一定要在留出的验证集上测别只看训练 loss。4.3 LLM as Judge用模型评测模型模型输出好不好人工评太慢。现在流行用 LLM 当裁判LLM as Judge让一个强模型给另一个模型的输出打分。做法是给裁判模型一个评分标准比如“从准确性、完整性、格式规范三个维度各打 1~5 分”然后让它输出分数和理由。这方法好用但有几个坑位置偏见裁判可能偏向第一个出现的答案。解决办法是交换顺序评两次取平均。长度偏见长答案容易被认为更详细。要在评分标准里明确“简洁性也计入”。裁判模型能力用弱模型当裁判评不准。尽量用比被测模型更强的模型当裁判。我一般会把 LLM as Judge 和少量人工评测结合先用 LLM 批量打分筛出低分和分数异常的样本再人工复核。这样效率和质量兼顾。5. 智能体与容错构建可靠系统的关键5.1 智能体的自主容错控制LLM 智能体Agent能自主调用工具、多步推理但可靠性是最大挑战。一个环节出错后面全崩。自主容错控制的核心思路是让智能体自己检测异常并恢复。具体做法包括结果校验工具返回后让模型判断结果是否合理。比如查天气返回“-999 度”明显异常触发重试或换工具。步骤回滚多步任务中某步失败回到上一个稳定状态重新规划而不是从头再来。超时与预算控制给智能体设最大步数和最大 token 预算防止无限循环烧钱。我做过一个多步信息查询的智能体最初没设步数上限遇到一个查不到的信息就反复换关键词重试烧了不少 token。后来加了“同一子任务最多重试 2 次超了就报告失败并继续下一步”稳定性大幅提升。5.2 记忆与知识库投毒的风险智能体如果有长期记忆或外部知识库就存在被污染的风险。攻击者可能往知识库里注入恶意内容诱导智能体做出错误决策。这不是危言耸听是实际存在的安全议题。防护思路知识库写入做审核不是谁都能往记忆里写东西加权限和内容过滤。检索结果做可信度排序优先用高可信来源的内容。关键决策加人工确认涉及资金、权限变更等敏感操作智能体只能建议不能直接执行。这些措施会增加一些复杂度但对于要上生产的智能体系统是必须的。5.3 请求失败的常见原因排查“LLM request failed: provider rejected the request schema or tool payload” 这类报错很常见通常是请求格式不符合 API 规范。排查顺序检查消息格式role 是否是 API 支持的值content 是否是字符串或正确的多模态结构。检查工具定义function calling 的 schema 是否符合 JSON Schema 规范必填字段有没有漏。检查 token 数输入是否超过模型上下文上限。检查参数范围temperature、top_p 是否在合法区间。我遇到最多的是工具 schema 里参数类型写错比如该是 string 写成了 numberAPI 直接拒绝。把 schema 打印出来对照文档逐字段核对基本都能定位。6. 一些零散但实用的经验6.1 基于 LLM 的单元测试用 LLM 生成单元测试是个提效手段但别直接信它生成的测试。我的做法是让 LLM 生成测试用例然后人工审查边界条件是否覆盖、断言是否合理。LLM 容易生成“看起来对但没测到关键逻辑”的测试。把它当草稿生成器不是最终答案。6.2 空间 LLM 与多模态Spatial LLM 这类涉及空间理解的多模态模型使用方法上和纯文本 LLM 有区别输入要带图像或 3D 数据prompt 要描述空间关系。目前这类模型在专业领域机器人、自动驾驶用得多通用场景还不成熟。如果你的任务涉及空间推理先确认模型是否真的支持别拿纯文本模型硬套。6.3 关于内容安全的边界不管用什么 LLM输出内容都要过一遍安全过滤。尤其是面向用户的产品模型可能生成不当内容。我的做法是在输出后加一层规则过滤或分类模型把明显有问题的内容拦下来。这不是可选项是必选项。6.4 成本控制的几个习惯缓存相同或相似的请求结果缓存起来别重复调用。分级简单任务用小模型复杂任务才用大模型。监控记录每次调用的 token 数和费用设预算告警。压缩 prompt定期审查 prompt去掉冗余描述。我见过一个项目因为 prompt 里塞了大量重复的示例每月费用翻了好几倍。精简 prompt 之后效果没降费用降了一半多。6.5 模型选型的现实考量选模型不是越强越好要看任务需求、成本、延迟、数据合规。我的经验是先用最强模型跑通流程、确定效果上限再逐步替换成更便宜的小模型看效果能接受就换。这样既知道天花板在哪又能控制成本。别一上来就用小模型效果不好你都不知道是模型不行还是 prompt 不行。LLM 的使用方法说到底是一套工程实践核心是理解它的概率本质、用工程手段约束它的不确定性、用评测和监控保证效果稳定。上面这些是我在实际项目里反复验证过的做法你可以根据自己的场景调整参数和流程。真正上手跑几个任务比看十篇教程都管用。