AI 参数调了一天还是胡言乱语？问题不在参数

上周我给一个创业团队做技术咨询，他们用大模型做合同审查，上线后准确率只有 60% 出头。负责人一脸痛苦地问我：“小哥，我们 temperature 调了、top_p 也调了、连 frequency_penalty 都试过了，怎么还是瞎编？”

我看了他们的 Prompt 和文档切片逻辑，沉默了很久。

然后说了一句让他们崩溃的话：“你们把一份 30 页的合同，一刀切成了 3 块，每块 10 页。模型看到的上下文都是断裂的条款，它能不瞎编吗？”

他们当场愣住。原来调了半天参数，问题根本不在参数上。

今天就把“AI 参数配置”这件事儿从头捋一遍，不是给你背参数值，是给你一套决策逻辑。看完之后，你不会再问“temperature 设多少合适”，而是会问自己“我这个场景到底需要模型干什么”。

一、先干一件事：把参数分成两类

很多人一说参数就想到 temperature、top_p，这是被算法教材带偏了。

实际工程里，影响 AI 输出质量的因素分两种：

第一类：模型推理参数（控制模型“怎么说话”）

• temperature（温度）
• top_p（核采样）
• max_tokens（最大输出长度）
• frequency_penalty（频率惩罚）
• presence_penalty（存在惩罚）

第二类：工程上下文参数（控制模型“看到什么”）

• 分块大小（chunk_size）
• 分块重叠（chunk_overlap）
• 召回数量（top_k）
• 相似度阈值（similarity_threshold）
• 最大输入 Token（max_input_tokens）
• System Prompt 结构

我做过的项目里，80% 的“参数问题”其实是第二类问题。 模型本身没毛病，是你喂给它的东西有毛病。但大部分人都在死磕第一类，调来调去像在给一辆没装方向盘的车调座椅角度。

二、模型推理参数：记住一个原则就够了

这个原则就一句话：参数是给模型“上枷锁”的，枷锁越松它越浪，越紧它越木。

2.1 temperature：不是创意开关，是“胡说八道概率”

temperature 控制输出 token 的概率分布。值越低，模型越倾向于选概率最高的那个词，输出越确定；值越高，低概率词也有机会被选中，输出越多样，但也越容易编造。

很多人有一个幻觉：temperature 调高了模型变“有创意”了。其实是把“随机采样”当成了“创造力”。真正的创造力来自模型的训练数据和推理能力，不是采样策略。

实战经验：

• 需要事实准确、逻辑严谨的（代码、合同、数学、数据提取）：0 ~ 0.2，别犹豫。
• 需要一定灵活性但不允许翻车的（翻译、摘要、客服）：0.3 ~ 0.5。
• 需要多样性和发挥的（头脑风暴、起标题、写诗）：0.7 ~ 1.0。

我自己的一个血泪教训：曾经让 AI 自动生成周报，temperature 设了 0.8，结果它给我编了几个我从没做过的“亮点工作”，差点被领导约谈。后来改成 0.1，老老实实基于我给的要点写，再也不翻车。

2.2 top_p：和 temperature 一个唱红脸一个唱白脸

top_p 是另一种控制随机性的方式。它只从累计概率达到 p 的那些 token 里采样。

我的习惯是：固定 top_p = 0.9 或 1.0，只调 temperature。 因为两者作用重叠，两个一起调很容易把自己调晕。

除非一种情况：你 temperature 已经设得很低了，输出还是不太稳定，这时候把 top_p 降到 0.8 再加一层约束。

2.3 max_tokens：别舍不得，但也别惯着

这个参数是硬限制，模型输出到这么多 token 就停。

两个坑：

• 设太小：JSON 被截断，代码只写了一半，你要的答案还没说完。
• 设太大：模型开始水字数，尤其对话场景，它会把一个问题翻来覆去地说。

我的做法：先根据场景估一个宽松的上限，然后观察几次实际输出长度，再收紧。给个参考：

• 简短问答/分类：128 ~ 256
• 代码生成：1024 ~ 2048
• 文章/报告：2048 ~ 4096

如果设了 max_tokens 还水字数，加 stop 词配合截断，别光靠 max_tokens 硬压。

2.4 penalty 两兄弟：治啰嗦的最后一招

• frequency_penalty：惩罚已经出现过的词再次出现，值越高用词越不重复。
• presence_penalty：惩罚已经聊过的话题再次出现，值越高越容易引入新内容。

90% 的场景不需要调它们。我只有在生成长文、发现模型总在车轱辘话的时候，才会把 frequency_penalty 加到 0.3 左右。调大了会有反效果——让它翻译“你好”，它给你输出“Hello、Hi、Hey”各一遍。

三、工程上下文参数：这才是“垃圾进垃圾出”的命门

前面说的模型参数，是“锅”。工程上下文参数，是“食材”。食材都馊了，锅再好也白搭。

3.1 分块大小（chunk_size）和重叠（chunk_overlap）

这两个参数决定了 RAG 系统的检索质量，重要性远高于 temperature。

分块太大：一个块里塞了四五个不同主题的内容，检索回来的内容不聚焦，模型一脸茫然。
分块太小：一个完整语义被切碎，检索到的块缺少上下文，模型断章取义。

我的经验值：

• 技术文档/API：256 ~ 512 token
• 百科/知识库：512 ~ 1024 token
• 合同/法规：512 ~ 1024 token（合同条款相对独立，可以稍大）
• 对话记录：256 ~ 512 token（一问一答尽量不拆开）

重叠怎么设：chunk_size 的 10%~20%。比如 512 token 的块，重叠 64~128 token。这几十个 token 的成本不要省，它保证了关键信息不会刚好被切断在两块之间。

我遇到过一个真实案例：用户问“Redis 缓存怎么配置”，文档里这段刚好被切成两块——块 1 结尾是“配置步骤如下：”，块 2 开头是“第一步，修改 redis.conf”。两块各自的相似度都不够高，都没被召回，最后模型回复“文档中未提及”。就因为省了那 50 个 token 的重叠，整段知识直接丢失。

3.2 召回数量（top_k）和相似度阈值

召回太多块，模型被噪音淹没；召回太少，信息不全。

我的通用配置：top_k = 3~5，similarity_threshold = 0.7。先过滤掉低于阈值的，再取 top_k。

如果你的文档质量高、分块合理，top_k = 3 往往比 5 效果更好。模型注意力是有限的，塞一堆相关信息不如给一两条最精准的。

3.3 System Prompt 不是越长越好

很多人写 System Prompt 像在写小说，恨不得把“你是一个善良、耐心、专业的助手”写三遍。

这些废话全都占 Token，还稀释了关键指令。System Prompt 应该像命令一样精准：角色 + 规则 + 输出格式。能省则省。

四、一套配置模板，覆盖 80% 场景

懒得调的兄弟直接抄：

事实问答 / 代码生成 / 数据提取：

temperature: 0.1
top_p: 1.0
max_tokens: 2048
frequency_penalty: 0
presence_penalty: 0

对话 / 客服 / 翻译：

temperature: 0.5
top_p: 0.9
max_tokens: 1024
frequency_penalty: 0.2
presence_penalty: 0

RAG 知识库（工程侧）：

chunk_size: 512 token
chunk_overlap: 64 token
top_k: 4
similarity_threshold: 0.7

这套参数我在五六个项目里用过，从合同审查到客服问答，基本不用大改。如果效果不好，先别调参数，先检查你的文档质量和分块逻辑。

五、调参的真正心法

最后说两句很多人不爱听的大实话。

第一，参数不是独立存在的，它们和 Prompt、数据质量、模型版本强耦合。 你换了个 Embedding 模型，分块大小可能得重调；你换了 GPT-5.4，temperature 的感受可能跟 GPT-4o 不一样。所以别指望背一个万能数值，要理解背后的逻辑。

第二，调参的本质是“约束管理”。你加的每一个约束（低温度、低 top_p、短 max_tokens、严格的分块），都在让模型更“听话”，但也更“死板”。你要找的，是业务能接受的“最松约束”。太紧，模型变成复读机；太松，模型变成编剧。

第三，别把参数当遮羞布。 Prompt 写得烂、文档切得渣，调什么参数都救不了。先把工程侧的坑填平，再来微调模型参数。顺序反了，就是南辕北辙。

记住一句话：调参不是为了驯服 AI，是为了让 AI 更好地理解你到底要什么。

共勉，少调参，多调脑子。