1. 为什么要把大模型判断变成结构化决策大模型在文本生成上的表现已经不需要多说了但真正把它塞进业务系统里跑最让人头疼的往往不是“写得好不好”而是“判断得准不准、快不快、贵不贵”。我接触过不少团队一开始都想着直接调一个通用大模型接口把用户输入丢进去让它返回一个“是/否”或者“分类标签”结果上线之后发现延迟高得离谱成本也压不住更麻烦的是同一个输入两次调用可能给出不同答案下游逻辑直接乱套。Jev 这个思路的核心就是把大模型从“自由发挥的聊天机器人”变成“受约束的结构化决策器”。它不追求让模型写出一段漂亮的解释而是让模型在给定输入下快速输出一个确定性的结构化结果比如一个枚举值、一个布尔判断、一个优先级分数。这样做的好处非常直接推理路径短了token 消耗降了响应时间从秒级压到百毫秒级而且因为输出空间被严格限制结果的一致性也上来了。这个方向适合谁呢如果你正在做内容审核、工单分类、意图识别、风控规则前置判断、推荐系统里的粗排过滤或者任何需要“先让模型做个快速判断再走后续流程”的场景那这套思路就非常值得参考。它不要求你从头训练模型也不需要你精通分布式推理更多是在提示词设计、输出约束、缓存策略和降级方案上做文章。下面我会从整体设计、核心细节、实操落地和问题排查几个角度把 Jev 这套结构化决策的玩法拆开讲清楚。2. 整体设计与思路拆解2.1 从“生成式”到“判别式”的思维转变很多人用大模型的第一反应是“让它回答一个问题”这其实是生成式思维。生成式思维下模型会先理解上下文再组织语言最后逐 token 输出整个过程计算量大、延迟高而且输出长度不可控。Jev 的做法是把任务重新定义为判别式给定输入 X模型只需要在预定义的标签集合 Y 里选一个最合适的或者输出一个固定格式的 JSON。这个转变带来的第一个好处是输出长度急剧缩短。原来让模型写一段解释可能要 200 个 token现在只输出一个标签或者一个短 JSON可能只要 5 到 10 个 token。别小看这个差距在批量调用场景下token 成本能差出十几倍。第二个好处是推理路径变短模型不需要“思考”太多前向计算量减少延迟自然就下来了。第三个好处是结果可校验因为输出空间是有限的你可以用正则或者 JSON Schema 直接校验不合法就重试或者降级不会出现“模型自由发挥导致下游解析失败”的情况。我自己的经验是凡是能用判别式解决的问题尽量不要用生成式。比如判断一条评论是否包含广告你不需要模型解释“为什么这是广告”只需要它输出“是”或“否”。解释可以留给后续的人工审核或者另一个专门做解释的模型但在第一道过滤上速度和成本才是关键。2.2 结构化输出的约束手段要让模型稳定输出结构化结果光靠“请返回 JSON”这种提示词是不够的。Jev 在实际落地时通常会叠加几层约束。第一层是提示词层面的约束明确告诉模型输出格式、可选值范围、是否允许额外字段。第二层是解码层面的约束比如用 JSON Schema 或者语法引导的解码方式让模型在生成时只能从合法 token 里选。第三层是后处理校验拿到输出后先解析解析失败就触发重试或者走兜底逻辑。这三层里第一层最容易做但稳定性最差第二层稳定性最好但需要推理框架支持第三层是保底任何方案都应该有。我一般建议至少做到第一层加第三层如果推理框架支持语法约束再把第二层加上。这样即使模型偶尔“抽风”也不会把脏数据传到下游。还有一个细节是枚举值的命名。不要用中文或者带空格的字符串作为枚举值尽量用短横线或者下划线连接的英文小写比如need_review、auto_approve、reject。这样模型在生成时不容易拼错后处理解析也简单。如果业务上必须用中文标签那就在提示词里明确给出映射关系让模型输出英文枚举后处理再转成中文。2.3 缓存与降级策略的设计结构化决策的另一个优势是结果可缓存。因为输入空间虽然大但很多请求是重复的或者高度相似的。Jev 在实际部署时通常会加一层语义缓存把输入做归一化处理比如去掉多余空格、统一大小写、提取关键实体然后算一个哈希或者向量相似度如果命中缓存就直接返回上次的结果不再调用模型。缓存策略要小心两个坑。第一个坑是缓存过期时间设得太长导致业务规则变了但缓存还在返回旧结果。我的做法是给缓存加一个版本号每次提示词或者模型版本更新就换一个命名空间旧缓存自然失效。第二个坑是相似度阈值设得太松把不同意图的请求误判为同一个。这个需要根据业务数据调一般从 0.95 开始往下试观察误命中率。降级策略也很重要。如果模型调用超时或者返回格式不对系统不能直接挂掉。常见的降级路径有三条一是返回一个默认的安全值比如need_review让后续人工介入二是走规则引擎用关键词或者正则做粗判断三是直接跳过这个判断让下游逻辑自己处理。具体选哪条要看业务容忍度但一定要提前设计好不要等线上出问题了再临时加。3. 核心细节解析与实操要点3.1 提示词模板的设计要点Jev 的提示词模板通常包含四个部分角色定义、任务说明、输出格式、示例。角色定义要简短比如“你是一个内容分类器”不需要长篇大论。任务说明要明确输入是什么、要判断什么、判断标准是什么。输出格式要给出严格的 JSON Schema 或者枚举列表。示例部分给一到两个正例和反例帮助模型理解边界。我见过很多提示词写得像小作文把各种规则都塞进去结果模型反而抓不住重点。Jev 的做法是尽量精简只保留必要的判断依据。比如判断一条评论是否违规你不需要把整个社区规范贴进去只需要列出三到五条最核心的违规类型让模型做选择题。规则太多反而会稀释注意力导致判断准确率下降。还有一个技巧是把判断标准写成“如果……则输出……”的形式而不是“请判断是否……”。前者更接近程序的逻辑模型执行起来更稳定。比如不要写“请判断这条评论是否包含广告”而是写“如果评论中包含联系方式、促销链接或者重复推销话术输出ad否则输出not_ad”。这样模型的任务就变成了模式匹配而不是开放式推理。3.2 输出格式的强约束方法输出格式的约束强度直接决定了后处理的复杂度。最弱的是自然语言输出比如“这条评论是广告”你需要用正则去提取关键词很容易出错。中等强度是 JSON 输出比如{label: ad}解析起来方便但模型可能多输出字段或者少输出引号。最强的是语法引导解码模型在生成时就被限制只能输出合法的 JSON token基本不会出错。如果你用的推理框架支持 JSON Schema 约束强烈建议开启。以常见的推理服务为例你可以在请求里传一个response_format参数指定 JSON Schema模型就会在解码时避开不合法的 token。这样即使提示词写得一般输出格式也能保证。如果不支持那就退而求其次在提示词里给出严格的 JSON 示例并在后处理里做校验和重试。重试策略也有讲究。不要无限重试一般最多重试两次。第一次重试可以稍微调整提示词比如加一句“请只输出 JSON不要输出其他内容”。第二次重试如果还失败就直接走降级。重试的时候最好换一个温度参数比如把 temperature 从 0 调到 0.1增加一点随机性有时候能跳出死循环。3.3 模型选型与参数调优Jev 并不绑定特定模型但选型时有几个原则。第一优先选支持结构化输出或者函数调用的模型这样约束成本最低。第二不要盲目追求大参数模型很多判别任务用小模型甚至蒸馏模型就能达到可接受的准确率而延迟和成本会好很多。第三要看模型的指令遵循能力有些模型虽然大但对格式指令不敏感输出经常跑偏。参数调优方面temperature 一般设 0 或者 0.1减少随机性。max_tokens 要设得刚好够输出结构化结果比如 50 到 100防止模型“话痨”。top_p 可以设 0.9 左右但如果是严格判别任务直接设 1 也行。frequency_penalty 和 presence_penalty 通常不需要调除非发现模型重复输出同一个标签。我自己的习惯是先用一个中等规模的模型跑一批测试数据看准确率和延迟然后再尝试更小的模型看准确率下降是否在可接受范围内。如果小模型准确率只差一两个百分点但延迟减半、成本降三分之二那肯定选小模型。判别任务对模型“知识广度”的要求其实不高更多是看它能不能稳定执行指令。4. 实操过程与核心环节实现4.1 环境准备与基础调用假设你已经有一个可以调用的模型服务不管是本地部署的还是云端的第一步是封装一个基础的调用函数。这个函数要处理超时、重试、日志记录。下面是一个 Python 示例用的是常见的 HTTP 调用方式import json import time import requests def call_model(prompt, schema, timeout3, max_retries2): url http://your-model-service/v1/chat/completions headers {Content-Type: application/json} payload { model: your-model-name, messages: [{role: user, content: prompt}], temperature: 0, max_tokens: 100, response_format: {type: json_schema, schema: schema} } for attempt in range(max_retries 1): try: resp requests.post(url, headersheaders, jsonpayload, timeouttimeout) resp.raise_for_status() data resp.json() content data[choices][0][message][content] return json.loads(content) except Exception as e: if attempt max_retries: raise time.sleep(0.2 * (attempt 1)) return None这个函数里几个关键点temperature设为 0max_tokens限制在 100response_format指定 JSON Schema。超时设 3 秒对于判别任务来说足够了。重试间隔用指数退避避免瞬间打爆服务。Schema 的定义要尽量简单比如{ type: object, properties: { label: {type: string, enum: [ad, not_ad, uncertain]} }, required: [label] }这样模型只能输出这三个标签之一后处理非常干净。4.2 提示词模板与批量测试有了基础调用函数之后下一步是设计提示词模板并做批量测试。我一般会准备一个测试集包含至少 200 条标注好的样本覆盖各种边界情况。然后写一个脚本批量跑统计准确率、延迟、失败率。提示词模板可以这样写你是一个内容分类器。请判断以下评论是否包含广告。 判断标准 - 如果包含联系方式、促销链接、重复推销话术输出 ad - 如果不包含上述内容输出 not_ad - 如果无法确定输出 uncertain 评论内容{text} 请只输出 JSON格式为 {label: ad} 或 {label: not_ad} 或 {label: uncertain}。测试的时候要记录每条样本的输入、输出、耗时、是否命中缓存。如果发现某些样本反复出错就把它们单独拎出来分析看是提示词没写清楚还是模型本身能力不够。有时候只需要在提示词里加一个反例准确率就能提升好几个百分点。批量测试的脚本可以这样写import pandas as pd def batch_test(test_file, prompt_template, schema): df pd.read_csv(test_file) results [] for _, row in df.iterrows(): prompt prompt_template.format(textrow[text]) start time.time() try: output call_model(prompt, schema) elapsed time.time() - start results.append({ text: row[text], expected: row[label], predicted: output[label], elapsed: elapsed, correct: output[label] row[label] }) except Exception as e: results.append({ text: row[text], expected: row[label], predicted: error, elapsed: time.time() - start, correct: False }) result_df pd.DataFrame(results) print(f准确率: {result_df[correct].mean():.2%}) print(f平均延迟: {result_df[elapsed].mean():.3f}s) print(f失败率: {(result_df[predicted] error).mean():.2%}) return result_df跑完测试之后重点看三类样本假阳性、假阴性、uncertain 比例。假阳性是模型把正常内容判成了广告假阴性是漏掉了广告uncertain 是模型拿不准。如果 uncertain 比例太高说明判断标准不够清晰需要细化提示词。如果假阳性或假阴性集中在某一类内容上就针对性地加规则或示例。4.3 缓存层与降级逻辑的接入测试通过之后就可以接入缓存和降级了。缓存层我一般用 Rediskey 是输入文本的哈希value 是结构化结果加时间戳。哈希之前先做归一化去掉首尾空格、连续空格合并、英文转小写。如果业务对大小写敏感那就保留原样但要在 key 里加一个版本前缀。import hashlib import redis import json r redis.Redis(hostlocalhost, port6379, db0) CACHE_VERSION v1 CACHE_TTL 3600 def normalize(text): return .join(text.strip().lower().split()) def get_cache_key(text): normalized normalize(text) return fjev:{CACHE_VERSION}:{hashlib.md5(normalized.encode()).hexdigest()} def get_cached(text): key get_cache_key(text) value r.get(key) if value: return json.loads(value) return None def set_cache(text, result): key get_cache_key(text) r.setex(key, CACHE_TTL, json.dumps(result))降级逻辑放在调用模型的外层。如果模型调用失败或者返回格式不对就走降级路径。降级路径可以是一个简单的规则引擎比如用关键词匹配判断是否包含“加微信”“点击链接”等命中就返回ad否则返回uncertain。这样即使模型服务挂了系统也能继续运行只是准确率会下降。def decide(text): cached get_cached(text) if cached: return cached try: result call_model(build_prompt(text), SCHEMA) set_cache(text, result) return result except Exception: return fallback_rule(text) def fallback_rule(text): keywords [加微信, 点击链接, 限时优惠, 扫码] for kw in keywords: if kw in text: return {label: ad} return {label: uncertain}这套组合拳下来线上服务的 P99 延迟基本能控制在 200 毫秒以内缓存命中率根据业务不同大概在 30% 到 60% 之间成本比直接调大模型写解释低了不止一个数量级。5. 常见问题与排查技巧实录5.1 模型输出格式不稳定的排查格式不稳定是最常见的问题表现是模型有时候输出纯 JSON有时候在 JSON 外面包一层 markdown 代码块有时候还带一句“好的以下是结果”。排查思路分三步先看提示词有没有明确说“只输出 JSON”如果没有就加上再看推理框架有没有开启语法约束没开启就开启最后看后处理有没有做容错解析比如用正则提取第一个{到最后一个}之间的内容。如果开了语法约束还是不稳定那可能是模型本身对格式指令不敏感。这时候可以换一个指令遵循能力更强的模型或者在提示词里加一个强制的开头比如“输出必须以 { 开头以 } 结尾”。我实测下来加这句之后格式错误率能降一半以上。还有一个偏方是把 temperature 设成负数有些推理框架支持效果相当于贪心解码输出最稳定的那个 token。不过不是所有框架都支持可以试试看。5.2 判断准确率不达标的调优路径准确率不达标的时候不要急着换模型先按这个顺序排查第一看测试集标注有没有问题有时候是标注本身有歧义第二看提示词里的判断标准是不是太模糊能不能拆成更具体的规则第三看示例够不够边界情况有没有覆盖第四看模型规模是不是太小换个中等规模的试试第五看是不是需要微调如果业务数据量大且标注质量高微调一个小模型往往比提示词工程更有效。我遇到过一个案例判断准确率卡在 85% 上不去后来发现是测试集里有一批样本的标注标准不一致重新标注之后准确率直接到了 93%。所以排查的时候一定要先怀疑数据再怀疑模型。5.3 延迟与成本的平衡技巧延迟和成本往往是一对矛盾。要降延迟可以用更小的模型、更短的提示词、更少的 max_tokens。要降成本可以用缓存、批量调用、按需调用。Jev 的实践里我一般会做这几件事把提示词压缩到 200 token 以内把 max_tokens 压到 50 以内开启语义缓存对非关键路径用异步调用。还有一个技巧是分级决策。先用一个极小的模型或者规则引擎做粗筛把明显能判断的样本处理掉剩下的疑难样本再交给大一点的模型。这样整体延迟和成本都能降下来准确率也不会差太多。粗筛的阈值可以调比如规则引擎能覆盖 60% 的样本那大模型只需要处理剩下的 40%。下面是一个常见问题速查表方便对照排查问题现象可能原因排查方法解决建议输出不是合法 JSON提示词不明确或未开语法约束检查提示词和推理参数加“只输出 JSON”并开启 schema 约束同一输入结果不一致temperature 太高或缓存未命中检查 temperature 和缓存日志设 temperature0加缓存延迟超过 1 秒模型太大或提示词太长看模型规模和 token 数换小模型压缩提示词准确率低于 80%标注问题或提示词模糊人工复核测试集重新标注细化判断标准缓存命中率低归一化不够或 TTL 太短看缓存 key 分布加强归一化延长 TTL降级逻辑不生效异常捕获范围不对看日志里的异常类型扩大 try 范围加兜底返回5.4 上线后的监控与迭代上线不是终点结构化决策系统需要持续监控和迭代。我一般会监控这几个指标调用量、缓存命中率、平均延迟、P99 延迟、格式错误率、降级触发率、准确率抽样。准确率抽样可以每天抽 100 条人工复核发现准确率下降就及时排查。迭代的时候不要一次性改太多东西。每次只改一个变量比如只调提示词或者只换模型然后观察指标变化。如果一次改多个出了问题很难定位。另外提示词和模型版本都要做版本管理每次变更记录在案方便回滚。还有一个经验是定期清理缓存。虽然缓存有 TTL但有些业务场景下输入分布会变化旧缓存可能不再适用。可以每周做一次全量缓存刷新或者在业务规则变更时主动清空相关缓存。6. 一些实操心得与扩展思路Jev 这套结构化决策的思路本质上是在大模型的能力和工程约束之间找平衡。它不追求模型“什么都能干”而是让模型在一个很窄的任务上做到又快又稳又便宜。我自己的体会是越是把任务定义得窄模型的表现越可控工程上越好优化。扩展方面这套思路可以和其他技术组合。比如和向量检索结合先用向量召回相似的历史决策如果相似度足够高就直接复用结果不用调模型。再比如和规则引擎结合规则引擎处理确定性高的样本模型处理模糊样本两者互补。还可以和主动学习结合把模型不确定的样本挑出来人工标注再拿去微调形成闭环。最后分享一个小技巧在提示词里加一句“如果你不确定输出 uncertain”比强行让模型二选一要安全得多。很多线上事故都是因为模型在拿不准的时候硬猜结果给出了错误判断。给模型一个“弃权”的选项虽然会增加一点人工复核量但能大幅降低误判风险。这个 uncertain 的比例可以监控如果太高就说明提示词或模型需要优化如果太低就说明模型可能过于自信需要检查一下。 
长河君 · 2026/10/15 21:55:49 · 阅读 1.2k 大模型结构化决策实战：Jev 如何实现毫秒级判别与成本优化
1. 为什么要把大模型判断变成结构化决策大模型在文本生成上的表现已经不需要多说了但真正把它塞进业务系统里跑最让人头疼的往往不是“写得好不好”而是“判断得准不准、快不快、贵不贵”。我接触过不少团队一开始都想着直接调一个通用大模型接口把用户输入丢进去让它返回一个“是/否”或者“分类标签”结果上线之后发现延迟高得离谱成本也压不住更麻烦的是同一个输入两次调用可能给出不同答案下游逻辑直接乱套。Jev 这个思路的核心就是把大模型从“自由发挥的聊天机器人”变成“受约束的结构化决策器”。它不追求让模型写出一段漂亮的解释而是让模型在给定输入下快速输出一个确定性的结构化结果比如一个枚举值、一个布尔判断、一个优先级分数。这样做的好处非常直接推理路径短了token 消耗降了响应时间从秒级压到百毫秒级而且因为输出空间被严格限制结果的一致性也上来了。这个方向适合谁呢如果你正在做内容审核、工单分类、意图识别、风控规则前置判断、推荐系统里的粗排过滤或者任何需要“先让模型做个快速判断再走后续流程”的场景那这套思路就非常值得参考。它不要求你从头训练模型也不需要你精通分布式推理更多是在提示词设计、输出约束、缓存策略和降级方案上做文章。下面我会从整体设计、核心细节、实操落地和问题排查几个角度把 Jev 这套结构化决策的玩法拆开讲清楚。2. 整体设计与思路拆解2.1 从“生成式”到“判别式”的思维转变很多人用大模型的第一反应是“让它回答一个问题”这其实是生成式思维。生成式思维下模型会先理解上下文再组织语言最后逐 token 输出整个过程计算量大、延迟高而且输出长度不可控。Jev 的做法是把任务重新定义为判别式给定输入 X模型只需要在预定义的标签集合 Y 里选一个最合适的或者输出一个固定格式的 JSON。这个转变带来的第一个好处是输出长度急剧缩短。原来让模型写一段解释可能要 200 个 token现在只输出一个标签或者一个短 JSON可能只要 5 到 10 个 token。别小看这个差距在批量调用场景下token 成本能差出十几倍。第二个好处是推理路径变短模型不需要“思考”太多前向计算量减少延迟自然就下来了。第三个好处是结果可校验因为输出空间是有限的你可以用正则或者 JSON Schema 直接校验不合法就重试或者降级不会出现“模型自由发挥导致下游解析失败”的情况。我自己的经验是凡是能用判别式解决的问题尽量不要用生成式。比如判断一条评论是否包含广告你不需要模型解释“为什么这是广告”只需要它输出“是”或“否”。解释可以留给后续的人工审核或者另一个专门做解释的模型但在第一道过滤上速度和成本才是关键。2.2 结构化输出的约束手段要让模型稳定输出结构化结果光靠“请返回 JSON”这种提示词是不够的。Jev 在实际落地时通常会叠加几层约束。第一层是提示词层面的约束明确告诉模型输出格式、可选值范围、是否允许额外字段。第二层是解码层面的约束比如用 JSON Schema 或者语法引导的解码方式让模型在生成时只能从合法 token 里选。第三层是后处理校验拿到输出后先解析解析失败就触发重试或者走兜底逻辑。这三层里第一层最容易做但稳定性最差第二层稳定性最好但需要推理框架支持第三层是保底任何方案都应该有。我一般建议至少做到第一层加第三层如果推理框架支持语法约束再把第二层加上。这样即使模型偶尔“抽风”也不会把脏数据传到下游。还有一个细节是枚举值的命名。不要用中文或者带空格的字符串作为枚举值尽量用短横线或者下划线连接的英文小写比如need_review、auto_approve、reject。这样模型在生成时不容易拼错后处理解析也简单。如果业务上必须用中文标签那就在提示词里明确给出映射关系让模型输出英文枚举后处理再转成中文。2.3 缓存与降级策略的设计结构化决策的另一个优势是结果可缓存。因为输入空间虽然大但很多请求是重复的或者高度相似的。Jev 在实际部署时通常会加一层语义缓存把输入做归一化处理比如去掉多余空格、统一大小写、提取关键实体然后算一个哈希或者向量相似度如果命中缓存就直接返回上次的结果不再调用模型。缓存策略要小心两个坑。第一个坑是缓存过期时间设得太长导致业务规则变了但缓存还在返回旧结果。我的做法是给缓存加一个版本号每次提示词或者模型版本更新就换一个命名空间旧缓存自然失效。第二个坑是相似度阈值设得太松把不同意图的请求误判为同一个。这个需要根据业务数据调一般从 0.95 开始往下试观察误命中率。降级策略也很重要。如果模型调用超时或者返回格式不对系统不能直接挂掉。常见的降级路径有三条一是返回一个默认的安全值比如need_review让后续人工介入二是走规则引擎用关键词或者正则做粗判断三是直接跳过这个判断让下游逻辑自己处理。具体选哪条要看业务容忍度但一定要提前设计好不要等线上出问题了再临时加。3. 核心细节解析与实操要点3.1 提示词模板的设计要点Jev 的提示词模板通常包含四个部分角色定义、任务说明、输出格式、示例。角色定义要简短比如“你是一个内容分类器”不需要长篇大论。任务说明要明确输入是什么、要判断什么、判断标准是什么。输出格式要给出严格的 JSON Schema 或者枚举列表。示例部分给一到两个正例和反例帮助模型理解边界。我见过很多提示词写得像小作文把各种规则都塞进去结果模型反而抓不住重点。Jev 的做法是尽量精简只保留必要的判断依据。比如判断一条评论是否违规你不需要把整个社区规范贴进去只需要列出三到五条最核心的违规类型让模型做选择题。规则太多反而会稀释注意力导致判断准确率下降。还有一个技巧是把判断标准写成“如果……则输出……”的形式而不是“请判断是否……”。前者更接近程序的逻辑模型执行起来更稳定。比如不要写“请判断这条评论是否包含广告”而是写“如果评论中包含联系方式、促销链接或者重复推销话术输出ad否则输出not_ad”。这样模型的任务就变成了模式匹配而不是开放式推理。3.2 输出格式的强约束方法输出格式的约束强度直接决定了后处理的复杂度。最弱的是自然语言输出比如“这条评论是广告”你需要用正则去提取关键词很容易出错。中等强度是 JSON 输出比如{label: ad}解析起来方便但模型可能多输出字段或者少输出引号。最强的是语法引导解码模型在生成时就被限制只能输出合法的 JSON token基本不会出错。如果你用的推理框架支持 JSON Schema 约束强烈建议开启。以常见的推理服务为例你可以在请求里传一个response_format参数指定 JSON Schema模型就会在解码时避开不合法的 token。这样即使提示词写得一般输出格式也能保证。如果不支持那就退而求其次在提示词里给出严格的 JSON 示例并在后处理里做校验和重试。重试策略也有讲究。不要无限重试一般最多重试两次。第一次重试可以稍微调整提示词比如加一句“请只输出 JSON不要输出其他内容”。第二次重试如果还失败就直接走降级。重试的时候最好换一个温度参数比如把 temperature 从 0 调到 0.1增加一点随机性有时候能跳出死循环。3.3 模型选型与参数调优Jev 并不绑定特定模型但选型时有几个原则。第一优先选支持结构化输出或者函数调用的模型这样约束成本最低。第二不要盲目追求大参数模型很多判别任务用小模型甚至蒸馏模型就能达到可接受的准确率而延迟和成本会好很多。第三要看模型的指令遵循能力有些模型虽然大但对格式指令不敏感输出经常跑偏。参数调优方面temperature 一般设 0 或者 0.1减少随机性。max_tokens 要设得刚好够输出结构化结果比如 50 到 100防止模型“话痨”。top_p 可以设 0.9 左右但如果是严格判别任务直接设 1 也行。frequency_penalty 和 presence_penalty 通常不需要调除非发现模型重复输出同一个标签。我自己的习惯是先用一个中等规模的模型跑一批测试数据看准确率和延迟然后再尝试更小的模型看准确率下降是否在可接受范围内。如果小模型准确率只差一两个百分点但延迟减半、成本降三分之二那肯定选小模型。判别任务对模型“知识广度”的要求其实不高更多是看它能不能稳定执行指令。4. 实操过程与核心环节实现4.1 环境准备与基础调用假设你已经有一个可以调用的模型服务不管是本地部署的还是云端的第一步是封装一个基础的调用函数。这个函数要处理超时、重试、日志记录。下面是一个 Python 示例用的是常见的 HTTP 调用方式import json import time import requests def call_model(prompt, schema, timeout3, max_retries2): url http://your-model-service/v1/chat/completions headers {Content-Type: application/json} payload { model: your-model-name, messages: [{role: user, content: prompt}], temperature: 0, max_tokens: 100, response_format: {type: json_schema, schema: schema} } for attempt in range(max_retries 1): try: resp requests.post(url, headersheaders, jsonpayload, timeouttimeout) resp.raise_for_status() data resp.json() content data[choices][0][message][content] return json.loads(content) except Exception as e: if attempt max_retries: raise time.sleep(0.2 * (attempt 1)) return None这个函数里几个关键点temperature设为 0max_tokens限制在 100response_format指定 JSON Schema。超时设 3 秒对于判别任务来说足够了。重试间隔用指数退避避免瞬间打爆服务。Schema 的定义要尽量简单比如{ type: object, properties: { label: {type: string, enum: [ad, not_ad, uncertain]} }, required: [label] }这样模型只能输出这三个标签之一后处理非常干净。4.2 提示词模板与批量测试有了基础调用函数之后下一步是设计提示词模板并做批量测试。我一般会准备一个测试集包含至少 200 条标注好的样本覆盖各种边界情况。然后写一个脚本批量跑统计准确率、延迟、失败率。提示词模板可以这样写你是一个内容分类器。请判断以下评论是否包含广告。 判断标准 - 如果包含联系方式、促销链接、重复推销话术输出 ad - 如果不包含上述内容输出 not_ad - 如果无法确定输出 uncertain 评论内容{text} 请只输出 JSON格式为 {label: ad} 或 {label: not_ad} 或 {label: uncertain}。测试的时候要记录每条样本的输入、输出、耗时、是否命中缓存。如果发现某些样本反复出错就把它们单独拎出来分析看是提示词没写清楚还是模型本身能力不够。有时候只需要在提示词里加一个反例准确率就能提升好几个百分点。批量测试的脚本可以这样写import pandas as pd def batch_test(test_file, prompt_template, schema): df pd.read_csv(test_file) results [] for _, row in df.iterrows(): prompt prompt_template.format(textrow[text]) start time.time() try: output call_model(prompt, schema) elapsed time.time() - start results.append({ text: row[text], expected: row[label], predicted: output[label], elapsed: elapsed, correct: output[label] row[label] }) except Exception as e: results.append({ text: row[text], expected: row[label], predicted: error, elapsed: time.time() - start, correct: False }) result_df pd.DataFrame(results) print(f准确率: {result_df[correct].mean():.2%}) print(f平均延迟: {result_df[elapsed].mean():.3f}s) print(f失败率: {(result_df[predicted] error).mean():.2%}) return result_df跑完测试之后重点看三类样本假阳性、假阴性、uncertain 比例。假阳性是模型把正常内容判成了广告假阴性是漏掉了广告uncertain 是模型拿不准。如果 uncertain 比例太高说明判断标准不够清晰需要细化提示词。如果假阳性或假阴性集中在某一类内容上就针对性地加规则或示例。4.3 缓存层与降级逻辑的接入测试通过之后就可以接入缓存和降级了。缓存层我一般用 Rediskey 是输入文本的哈希value 是结构化结果加时间戳。哈希之前先做归一化去掉首尾空格、连续空格合并、英文转小写。如果业务对大小写敏感那就保留原样但要在 key 里加一个版本前缀。import hashlib import redis import json r redis.Redis(hostlocalhost, port6379, db0) CACHE_VERSION v1 CACHE_TTL 3600 def normalize(text): return .join(text.strip().lower().split()) def get_cache_key(text): normalized normalize(text) return fjev:{CACHE_VERSION}:{hashlib.md5(normalized.encode()).hexdigest()} def get_cached(text): key get_cache_key(text) value r.get(key) if value: return json.loads(value) return None def set_cache(text, result): key get_cache_key(text) r.setex(key, CACHE_TTL, json.dumps(result))降级逻辑放在调用模型的外层。如果模型调用失败或者返回格式不对就走降级路径。降级路径可以是一个简单的规则引擎比如用关键词匹配判断是否包含“加微信”“点击链接”等命中就返回ad否则返回uncertain。这样即使模型服务挂了系统也能继续运行只是准确率会下降。def decide(text): cached get_cached(text) if cached: return cached try: result call_model(build_prompt(text), SCHEMA) set_cache(text, result) return result except Exception: return fallback_rule(text) def fallback_rule(text): keywords [加微信, 点击链接, 限时优惠, 扫码] for kw in keywords: if kw in text: return {label: ad} return {label: uncertain}这套组合拳下来线上服务的 P99 延迟基本能控制在 200 毫秒以内缓存命中率根据业务不同大概在 30% 到 60% 之间成本比直接调大模型写解释低了不止一个数量级。5. 常见问题与排查技巧实录5.1 模型输出格式不稳定的排查格式不稳定是最常见的问题表现是模型有时候输出纯 JSON有时候在 JSON 外面包一层 markdown 代码块有时候还带一句“好的以下是结果”。排查思路分三步先看提示词有没有明确说“只输出 JSON”如果没有就加上再看推理框架有没有开启语法约束没开启就开启最后看后处理有没有做容错解析比如用正则提取第一个{到最后一个}之间的内容。如果开了语法约束还是不稳定那可能是模型本身对格式指令不敏感。这时候可以换一个指令遵循能力更强的模型或者在提示词里加一个强制的开头比如“输出必须以 { 开头以 } 结尾”。我实测下来加这句之后格式错误率能降一半以上。还有一个偏方是把 temperature 设成负数有些推理框架支持效果相当于贪心解码输出最稳定的那个 token。不过不是所有框架都支持可以试试看。5.2 判断准确率不达标的调优路径准确率不达标的时候不要急着换模型先按这个顺序排查第一看测试集标注有没有问题有时候是标注本身有歧义第二看提示词里的判断标准是不是太模糊能不能拆成更具体的规则第三看示例够不够边界情况有没有覆盖第四看模型规模是不是太小换个中等规模的试试第五看是不是需要微调如果业务数据量大且标注质量高微调一个小模型往往比提示词工程更有效。我遇到过一个案例判断准确率卡在 85% 上不去后来发现是测试集里有一批样本的标注标准不一致重新标注之后准确率直接到了 93%。所以排查的时候一定要先怀疑数据再怀疑模型。5.3 延迟与成本的平衡技巧延迟和成本往往是一对矛盾。要降延迟可以用更小的模型、更短的提示词、更少的 max_tokens。要降成本可以用缓存、批量调用、按需调用。Jev 的实践里我一般会做这几件事把提示词压缩到 200 token 以内把 max_tokens 压到 50 以内开启语义缓存对非关键路径用异步调用。还有一个技巧是分级决策。先用一个极小的模型或者规则引擎做粗筛把明显能判断的样本处理掉剩下的疑难样本再交给大一点的模型。这样整体延迟和成本都能降下来准确率也不会差太多。粗筛的阈值可以调比如规则引擎能覆盖 60% 的样本那大模型只需要处理剩下的 40%。下面是一个常见问题速查表方便对照排查问题现象可能原因排查方法解决建议输出不是合法 JSON提示词不明确或未开语法约束检查提示词和推理参数加“只输出 JSON”并开启 schema 约束同一输入结果不一致temperature 太高或缓存未命中检查 temperature 和缓存日志设 temperature0加缓存延迟超过 1 秒模型太大或提示词太长看模型规模和 token 数换小模型压缩提示词准确率低于 80%标注问题或提示词模糊人工复核测试集重新标注细化判断标准缓存命中率低归一化不够或 TTL 太短看缓存 key 分布加强归一化延长 TTL降级逻辑不生效异常捕获范围不对看日志里的异常类型扩大 try 范围加兜底返回5.4 上线后的监控与迭代上线不是终点结构化决策系统需要持续监控和迭代。我一般会监控这几个指标调用量、缓存命中率、平均延迟、P99 延迟、格式错误率、降级触发率、准确率抽样。准确率抽样可以每天抽 100 条人工复核发现准确率下降就及时排查。迭代的时候不要一次性改太多东西。每次只改一个变量比如只调提示词或者只换模型然后观察指标变化。如果一次改多个出了问题很难定位。另外提示词和模型版本都要做版本管理每次变更记录在案方便回滚。还有一个经验是定期清理缓存。虽然缓存有 TTL但有些业务场景下输入分布会变化旧缓存可能不再适用。可以每周做一次全量缓存刷新或者在业务规则变更时主动清空相关缓存。6. 一些实操心得与扩展思路Jev 这套结构化决策的思路本质上是在大模型的能力和工程约束之间找平衡。它不追求模型“什么都能干”而是让模型在一个很窄的任务上做到又快又稳又便宜。我自己的体会是越是把任务定义得窄模型的表现越可控工程上越好优化。扩展方面这套思路可以和其他技术组合。比如和向量检索结合先用向量召回相似的历史决策如果相似度足够高就直接复用结果不用调模型。再比如和规则引擎结合规则引擎处理确定性高的样本模型处理模糊样本两者互补。还可以和主动学习结合把模型不确定的样本挑出来人工标注再拿去微调形成闭环。最后分享一个小技巧在提示词里加一句“如果你不确定输出 uncertain”比强行让模型二选一要安全得多。很多线上事故都是因为模型在拿不准的时候硬猜结果给出了错误判断。给模型一个“弃权”的选项虽然会增加一点人工复核量但能大幅降低误判风险。这个 uncertain 的比例可以监控如果太高就说明提示词或模型需要优化如果太低就说明模型可能过于自信需要检查一下。