AI 应用术语大白话：温度、TopK、召回、Rerank……一张地图看懂参数、检索与 Agent
基于 Dify 1.16.x 与通用 AI 应用实践整理（2026-09）；术语为行业通行含义，Dify 特定项以 1.16.x 版本为准
📖 摘要：和客户聊 AI 应用方案，最尴尬的往往不是技术难，而是术语不通——客户问「TopK 调多少」「温度设几度」，你答得专业他听不懂，听懂了又怕你在忽悠。本文把 AI 应用里最常见的一批名词按六个层次排成一张地图：调模型的旋钮（温度、TopP、Max Tokens、惩罚、停止序列）、检索的三道闸（召回、TopK、相似度阈值、Rerank、混合检索、元数据过滤）、Agent 与记忆（系统提示词、上下文窗口、工具调用）、编排结构（工作流、节点、变量、DSL）、应用形态与平台（数据集、模型供应商、Token、索引方式），最后单列最容易混的几对（温度 vs TopP、TopK vs 阈值、召回 vs Rerank、向量检索 vs 全文检索）。给客户讲方案、给项目做验收、自己入门，都能按图索骥。
📌 本文要解决的核心痛点
- 客户问「这个 TopK 是啥、调多少合适」，你从「召回候选段落」讲起，他的眼神开始涣散
- 把「温度调低」当成万能药，不知道 TopP、频率惩罚是干什么的
- 以为 Rerank 就是「再排一次序」，不知道它和 TopK、阈值是三道不同的闸
- 「工作流」「对话流」「数据集」「Token」满天飞，说不清谁是谁、怎么串
场景：方案会上的术语鸿沟
给客户讲 AI 知识库方案，最常见的场面是这样的：讲到检索配置，客户指着屏幕问——「这个 TopK 是什么？调成 5 还是 20？」
如果你从「召回候选段落、取相似度最高的前 K 条」讲起，他会礼貌地点头，然后转头问旁边的人「他说的召回是啥」。术语不通不是小事：客户听不懂，就不敢拍板；不敢拍板，方案就停在「再想想」。
反过来，如果你能一句话讲明白——「TopK 就是最多捞多少段相关内容给 AI 看，像人查资料先翻出几页放桌上」——他立刻能参与决策，还会追问「那捞太多会不会把不相干的也翻出来」。你看，问到阈值和 Rerank 了，术语地图自己就展开了。
术语从来不是门槛，是地图。这篇把 AI 应用里最常碰到的名词按六个层次排好，每个词都配一句「大白话 + 什么时候用」——查表用，讲方案用，验收时跟技术对线也用得上。
一张地图看懂全文
六个层次从「最底层的模型行为」一路到「整个应用长什么样」。下面逐层拆开。
第一层：调模型的旋钮
这一层管的是同一个问题：模型输出有多随机、多长、多守规矩。
| 术语 | 大白话 | 什么时候动它 |
|---|---|---|
| 温度（Temperature） | 模型敢不敢跑偏的旋钮：越高越发散（写文案、想点子用 0.7-0.9），越低越保守（问答、诊断、客服用 0-0.3） | 要稳定答案就压到接近 0——我们交付的问答类应用直接把温度压到 0，配固定用例逐条验证，从没让它在「该答什么」上自由发挥 |
| TopP（核采样） | 另一种随机性开关：只从概率最高的那一撮词里挑，避免选到离谱的词 | 和温度二选一调。两个都往死里拉，模型会开始说胡话 |
| Max Tokens（最大生成长度） | 最多允许生成多长。约 1 个汉字 ≈ 1.5-2 个 token | 长报告调大；短问答调小，防失控也省钱 |
| 频率惩罚 / 存在惩罚 | 前者惩罚「车轱辘话来回说」，后者惩罚「翻来覆去聊旧话题、不提新内容」 | 生成类应用嫌啰嗦时调 |
| 停止序列（Stop） | 看到指定字符串就闭嘴停笔 | 结构化输出：遇到结束标记就停 |
顺带一个容易踩的：思考模式（推理）。不少新模型默认「先想后答」，复杂推理确实更准，但纯速答场景开着它，就是白白多等几十秒——我们实测过一类故障：AI「转圈两分钟」然后给空白回答，把思考模式关掉立刻恢复，一次问答从 54 秒缩到几秒（排查实录见一次空输出事故的排查）。该关就关，它不是越开越好的旋钮。
第二层：检索的三道闸（重点）
做知识库问答（RAG），这一层是命门。整条链路一句话：
文档先切成段（分段）→ 每段转成向量（Embedding）→ 用户提问时把问题也转向量 → 从库里捞最像的候选段（召回）→ 限量（TopK）→ 去噪（相似度阈值）→ 精排（Rerank）→ 交给模型组织答案
| 术语 | 大白话 | 在链条里的位置 |
|---|---|---|
| 分段（Chunking） | 入库前把长文档切成小块——切多大、怎么切，直接决定后面捞得准不准 | 建库地基 |
| Embedding（向量化） | 把文字变成一串数字坐标，意思相近的文字坐标也近 | 入库、查询都在用 |
| 召回（Retrieval） | 「捞候选段落」这个动作——先从库里按相似度捞一批 | 第一道闸 |
| TopK | 最多捞多少条（前 K 条）——防漏的数量上限 | 第一道闸的阀门 |
| 相似度阈值 | 不够像的不要——低于该分值的直接扔 | 第二道闸，去噪 |
| 混合检索 | 向量找「意思像的」+ 全文找「字面有的」双路并查合并 | 比单路召回全 |
| Rerank（重排） | 用一个更聪明的精排模型，把捞回来的候选重新排一遍，好答案提到最前 | 第三道闸，精排 |
| 元数据过滤 | 给段落打标签（产品线/版本/章节），查询先按标签圈范围再检索 | 确定性闸门 |
| 引用溯源 | 回答后附「答案出自哪一段原文」 | 信任保障 |
三个最容易混的参数关系一句话讲透：TopK 是数量上限，决定捞多少；阈值是质量底线，决定多像才算数；Rerank 是精排，把候选里的好答案提到最前面。三道闸各管一段，调参不是只拧一个。
举个真实案例说明「只拧一个没用」。我们给一个大文档知识库做检索调优时，初步结果里 75% 都是噪声——问 A 产品线的问题，B 产品线的相似章节也被捞上来。这时把 TopK 调小、阈值调高，只能减少数量，噪声比例纹丝不动，因为噪声不是「多」出来的，是「没被挡住」的。真正的解法是加元数据过滤：入库时给每段打「产品线」标签，查询时先按标签圈定范围再检索——一道规则闸门，噪声从 75% 直接压到 0。
这就是第二层的核心认知：检索质量是四道闸一起决定的——分段质量、召回数量、相似度底线、精排与过滤。客户说「回答不准」，别急着换模型，先看这四道闸哪道没守住。噪声怎么从 75% 压到 0 的完整排查过程，见检索噪声 75% 降到 0 的确定性闸门。
第三层：Agent 与记忆
如果知识库是「给模型递资料」，Agent 就是「让模型自己决定怎么干活」。
| 术语 | 大白话 | 关键点 |
|---|---|---|
| 系统提示词（System Prompt） | 给模型的岗位说明书：你是谁、什么语气、守什么规矩 | 最值钱的配置项，没有之一 |
| 上下文窗口 | 模型一次能「看得见」的总量，超了就被截断或遗忘 | 决定一次能塞多少资料和对话历史 |
| 记忆 / 会话记忆 | 多轮对话里记得前面聊过什么 | 可配开几轮、全量还是摘要 |
| 工具调用（Function Calling） | 模型「申请」调用外部能力——查库、调接口、跑代码。不是模型自己会，是它申请、系统执行 | Agent 能力的核心来源 |
| Agent 循环 | 想 → 调工具 → 看结果 → 再想，直到给出答案 | 自主性的来源，也是不可控性的来源 |
| 幻觉（Hallucination） | 一本正经地编——没依据也敢答 | RAG 存在的意义就是给它依据，把它按在事实上 |
一句话：Agent 负责「决定做什么」，工具负责「真的做到」，知识库负责「不许瞎说」。 三者配合，才是一个能交付的助手，而不是一个能聊天的玩具。
第四层：编排结构
单个模型、单个工具是零件，编排是把零件装成机器的方式。
| 术语 | 大白话 |
|---|---|
| 工作流（Workflow） | 把步骤画成流程图：先干什么、后干什么，每步一个节点 |
| 对话流（Chatflow） | 面向多轮对话的工作流——先聊、中间查库/调工具、再答 |
| 节点（Node） | 流程里的一个步骤：LLM 节点、知识检索节点、条件分支节点…… |
| 变量（Variable） | 节点之间传递的数据：用户问的、检索到的、中间算出的 |
| 迭代 / 循环 | 对一批东西逐个处理（比如把十个问题逐个查一遍） |
| 条件分支 | 按规则走不同路径：意图不同 → 走不同处理 |
| DSL | 工作流的「源代码」文件——导出、导入、版本管理靠它（类似网页的 HTML） |
编排层的设计哲学值得单说一句：能确定的部分用流程写死，不能确定的才交给模型。 我们实测过不少「听起来很 AI、实际很脆弱」的方案——把路由、判断、格式全交给模型自由发挥，结果就是同一件事上午答对、下午答错。反过来，把能枚举的路径画成分支、把格式用规则固定，模型只负责它擅长的理解与生成，应用稳定性立刻上了一个台阶。这一层做得越细，交付后半夜被叫醒的概率越低。
第五层：应用形态与平台
这一层回答的是「整个应用是什么、跑在什么上面」。
| 术语 | 大白话 | 备注 |
|---|---|---|
| 应用模式 | AI 应用按形态分几类：对话助手、工作流、Agent、文本生成 | 决定用户怎么跟它打交道 |
| 数据集（Dataset） | 平台里「知识库」的正式叫法——一个库 = 一批文档切片 + 向量索引 | Dify 术语 |
| 模型供应商（Provider） | 模型的来源方（DeepSeek、智谱、OpenAI 等） | 平台是插座，换模型不换应用 |
| Token | 模型计费与上下文容量的计量单位 | 钱按它算，容量也按它算 |
| 索引方式 | 建库可选「高质量（向量索引，准但费钱）」或「经济（关键词索引，快但糙）」 | Dify 术语，按预算与质量要求选 |
| 系统变量 | 平台自带的环境信息：当前时间、会话 ID、用户 ID | 定时任务里那个系统时间戳就是它 |
给客户算账时这一层最实用：成本大头通常在模型调用（Token）和高质量索引——「为什么这个知识库建库要花钱」的答案，多半在这一层的索引方式里。
第六层：容易混的几对
最后把最常被混着说、混着调的五对单独拎出来：
| 对比 | 一句话区别 |
|---|---|
| 温度 vs TopP | 温度=整体敢不敢发散；TopP=只在高概率词里挑。都影响随机性但机制不同，一般只动一个 |
| TopK vs 阈值 | TopK=最多捞 N 条（保数量、防漏）；阈值=低于 X 分不要（保质量、防噪）。一条管上限，一条管底线 |
| 召回 vs Rerank | 召回=便宜快速多捞（粗选）；Rerank=聪明但贵地精排（精选）。先粗后精，成本才可控 |
| 向量检索 vs 全文检索 | 向量找「意思像的」（能跨词面），全文找「字面有的」（精确术语不丢）——所以混合检索最好 |
| 知识库检索 vs 联网搜索 | 检索查你自己的文档，搜索查全网——可信度完全不同，客户最该分清的就是这个 |
讲方案时最容易出彩的其实是最后一对：客户问「你们这个 AI 会瞎说吗」——答案的一半就在这：回答只基于自己的知识库（可控），还是能去网上乱抓（不可控）。这直接决定你敢不敢对回答质量负责。
常见问题
给 AI 应用调参数，先动温度还是 TopP？
先动温度。温度是「整体随机性」，语义直观、效果可预期：问答类压到 0-0.3，创作类放到 0.7 以上。TopP 是补充手段，和温度机制不同，常规场景动一个就够——两个一起猛调容易把模型调「飘」。
知识库回答不准，先调 TopK、阈值还是 Rerank？
先别急着调参——先分清是「没捞到」（调 TopK 加大候选、检查分段质量）还是「捞到但捞错」（加元数据过滤、上 Rerank）。噪声是「多出来」的，调小 TopK 只会减少数量不会去噪；我们实测 75% 的检索噪声是靠元数据过滤一道规则闸门压到 0 的，不是靠调参。
知识库问答（RAG）和微调是什么关系？
两个不同的东西：RAG 是「检索现成文档给模型当依据」，适合文档量大、答案有标准口径的场景，改文档只改库不改模型；微调是「把特定能力训练进模型本身」，成本高、更新慢。绝大多数企业问答场景先做 RAG，不够再谈微调——拿检索能解决的，不值得花钱训练。
这篇怎么用
按读者给三条用法：
- 给客户讲方案：重点过第二层（三道闸）和第六层（易混对）——客户能听懂检索为什么不准、敢不敢对回答负责，方案就谈得下去；
- 做验收 / 跟技术对线：把第二层的四道闸当检查单——回答不准先问「分段质量、召回数量、相似度底线、过滤与精排」哪道没守，而不是笼统说「效果不好」；
- 自己入门：按地图六层过一遍，每层抓住一句话——旋钮管随机性、三道闸管检索质量、Agent 管自主、编排管确定、平台管成本。
边界说明：术语解释为行业通行含义（2026-09）；标注 Dify 特定项的（数据集、索引方式等）基于 Dify 1.16.x 版本，平台版本演进后以新版为准。文中实测案例（温度压 0、检索噪声 75%→0、思考模式空输出）均来自我们真实交付与实验记录，深度排查过程见门户对应文章。
