# 一个温度参数引发的线上事故LLM工程化到底难在哪上个月Review内部RAG问答系统的代码发现团队把所有LLM调用的temperature统一写成了0.7——包括结构化提取、检索重排和最终答案生成。问当时为什么这么设答案是试了一下感觉效果比较自然。结果那个系统上线两周JSON解析失败率稳定在32%用户问我的订单为什么没发货模型一本正经地返回了{message: 我们非常抱歉为您带来不便}连退款金额都没提取出来。这不是模型不行。是我们根本没把LLM当工程系统对待。Packt最近出了一门课叫《AI LLM Engineering Mastery - GenAI, RAG Complete Guide》名字很长内容倒是不水——从采样参数的数学原理到RAG流水线再到LoRA微调基本覆盖了LLM应用从Demo到产品需要跨过的全部坑。但我今天不打算复述课程大纲我想结合自己在这个项目里的实际踩坑聊聊几个课本里不会写清楚、但线上一定会遇到的工程细节。## 一、temperature和top_p真不是创意开关先说那个JSON解析失败率32%的事故。temperature的本质是对logits做缩放T→0时分布逼近argmax输出近乎确定T越大低概率token越有机会被选中。top_p则是nucleus sampling截掉累计概率超过p的长尾token集合再重新归一化。两者的差别在于**temperature改变的是整个分布的陡峭程度top_p只裁剪尾部**。课程里把这两个参数分开讲但生产环境里它们经常被一起使用。OpenAI SDKopenai Python包**v1.30.0**允许两者同时启用官方文档的说法是先用top_p截断累积量再做temperature缩放。但这里有一个课堂上不会讲、我实践中踩到的坑**当temperature取值超过1.2时top_p的约束效果迅速衰减**。我用gpt-4o-mini做过一次温度扫描temperature从0到1.5每个档位跑50次结构化抽取发现0.8以下输出的JSON非法率低于3%1.0左右窜到11%而1.5时逼近40%——无论top_p怎么调。这不是理论推导是我在测试集上跑出来的分布。所以我的工程建议是**将采样参数视为函数级配置而不是全局变量**。python# openai v1.30.0Python 3.11from openai import OpenAIclient OpenAI()def generate_structured_response(prompt: str, temperature: float 0.2, top_p: float 0.9) - str:结构化任务低 temperature 保证一致性top_p 负责去尾response client.chat.completions.create(modelgpt-4o-mini,messages[{role: user, content: prompt}],temperaturetemperature, # 低温度减少随机性确保格式稳定top_ptop_p, # 截断长尾将低概率 token 剔除max_tokens1024,)return response.choices[0].message.contentdef generate_ad_copy(prompt: str) - str:创意任务高 temperature 采样阈值放宽扩大多样性response client.chat.completions.create(modelgpt-4o-mini,messages[{role: user, content: prompt}],temperature0.9,top_p0.95,)return response.choices[0].message.content检索回答、JSON生成、工具调用全部压到0.1-0.3文案、头脑风暴放开到0.7-1.0。如果你用OpenAI SDK建议同时开启logprobs参数对低置信度输出打标降级——我们目前的做法是对logprobs低于阈值的回答直接返回我暂时不确定已转人工好过让模型硬编一个错误答案。## 二、Few-Shots示例选不好效果不如Zero-Shot课程里把Prompt技术拆成Zero-Shot、Few-Shots、CoT、Role-Playing、Open-Ended五类并强调组合使用。这个方向是对的但**组合的粒度远比组合本身更重要**。我们项目里有一个自然语言转SQL需求最初版本的Few-Shots示例全部来自内部管理后台的短查询比如user: 查看订单表前10行assistant: SELECT * FROM orders LIMIT 10;结果线上用户开始问查询本季度回款超过一万且状态是已发货的客户名单模型生成的SQL里出现了LIMIT 10。为什么不意外因为所有示例都限制了返回行数模型学到的是用户查询简单查询的分布而不是把中文转成SQL这个任务。后来我们把示例换成覆盖边界情况的组合——一条短查询、一条带子查询的中等难度查询、一条明确要求只要列名不要数据的元数据查询。同时把Role-Playing叠加进去python# langchain v0.2.12 | langchain-openai v0.1.8from langchain_openai import ChatOpenAIfrom langchain.prompts import ChatPromptTemplate, FewShotChatMessagePromptTemplateexamples [{input: 查看订单表前10行, output: SELECT * FROM orders LIMIT 10;},{input: 统计各省份销售额, output: SELECT province, SUM(sales) FROM orders GROUP BY province;},{input: 查询本季度回款超过一万的客户, output: SELECT customer FROM orders WHERE payment 10000 AND quarter current GROUP BY customer;},]few_shot_prompt FewShotChatMessagePromptTemplate(example_promptChatPromptTemplate.from_messages([(human, {input}),(ai, {output}),]),examplesexamples,)final_prompt ChatPromptTemplate.from_messages([(system, 将用户问题转换为 SQL只输出 SQL 语句不要任何解释。),few_shot_prompt,(human, {input}),])llm ChatOpenAI(modelgpt-4o, temperature0, top_p0.8)chain final_prompt | llmresult chain.invoke({input: 查询本季度回款超过一万的客户})print(result.content)替换后的效果立竿见影SQL正确率从71%提升到88%同一批200条测试用例覆盖了原有短查询和新增的复杂查询。核心经验是**Few-Shots里的示例决定了模型对任务边界的认知比示例多要的是覆盖边界情况**。这也算是我自己踩出来的反直觉发现——示例太干净反而有害。## 三、RAG的确定性掌握在文本切分手里课程花了很大篇幅讲RAG架构但我接下来想谈一个细节——**切分器Text Splitter直接决定了RAG的天花板**。我们做内部文档问答时第一版方案是固定512 token硬切结果有一类问题频繁翻车用户问逾期利率是多少系统答非所问。排查后发现文档里逾期利率和每月5日前还款被切到了两个不同的chunk里检索器根据向量相似度召回了前半段上下文里根本没有完整的条件描述。这种错误极其隐蔽因为它不是答错而是答不完整。改成递归字符切分后这个问题大幅缓解——RecursiveCharacterTextSplitterlangchain-text-splitters **v0.2.1**按分隔符优先级逐级降级切分而关键是把中文标点纳入分隔符体系pythonfrom langchain_text_splitters import RecursiveCharacterTextSplitterfrom langchain
