最近一段时间身边越来越多朋友开始做AI应用但聊起来的时候经常会卡在一堆术语上。温度、TopK、召回、Rerank、Agent每个词单独看都认识拼在一起就完全不知道在说什么。更难受的是这些术语往往藏在技术文档和论文里解释得又抽象又绕看完反而更糊涂。这篇文章我就用大白话把AI应用开发里最常用的几个术语一次性讲透。我会用一张“地图”把参数、检索、Agent串起来让你知道它们各自负责什么、怎么配合还会结合我实际跑过的项目把调参和排障的经验也一并交代清楚。不管你是刚入门想搞懂概念还是已经动手写代码但被参数折磨过这篇内容应该都能帮上忙。1. 一张地图看懂整条流水线1.1 从老板需求到技术方案先说个真实场景。假设老板让你做一个“企业知识库问答机器人”员工可以问“去年的报销流程是什么”机器人要能给出准确答案还要能顺着问“那差旅标准呢”。这个需求拆开来看其实涉及三个完全不同的环节。第一个环节是“听懂问题”这靠的是大模型本身的语义理解能力。第二个环节是“找到相关资料”因为企业知识库可能有好几万份文档你不可能把所有文档都塞给模型得先把相关的几段捞出来。第三个环节是“组织答案”模型拿到相关资料后结合对话历史生成一段通顺、准确的回答。这三个环节对应的技术栈正好就是标题里那组术语参数温度、TopK管的是模型怎么生成召回和Rerank管的是怎么从知识库里找资料Agent管的是怎么让模型学会使用工具、多轮推理。把这三个环节想清楚整条流水线的地图就出来了。1.2 术语不是孤立的它们是一条链我见过太多初学者挨个学术语温度背了个定义TopK背了个定义回头一用还是懵。问题不在理解单个词在于不知道它们在整个系统里处于什么位置。举个更直白的类比。把AI应用想象成一家餐厅。后厨的大厨是大模型负责做菜传菜员是检索模块负责把食材从仓库里搬出来菜单是Rerank决定哪个菜优先上。温度、TopK这些参数是大厨做菜时的手感——是保守一点什么菜都按标准菜谱来还是大胆一点今天多放点盐、换个摆盘方式。Agent在这里是什么角色Agent相当于餐厅的领班他不仅会做菜还会安排整个流程——先看顾客点了什么、缺什么食材就去仓库找、甚至能打电话给供应商下单。也就是说Agent是站在大模型之上的一个“调度层”它决定怎么把问题拆解成步骤、什么时候调用工具、什么时候直接回答问题。有了这张地图再回头看那些术语每个词该放在哪个格子里一下子就清楚了。1.3 为什么这个架构被大家广泛采用这套“模型生成 向量检索 智能体调度”的架构现在已经不是某个公司的独家方案而是AI应用的主流范式。原因也简单它刚好解决了大模型的两个先天问题。第一个问题是知识陈旧。大模型的训练数据有截止日期你问它“今年的报销额度”它只能给出一个过时的答案。但如果你先通过检索找到最新的制度文档再把文档内容塞给模型它就能基于最新材料回答。第二个问题是容易胡说八道也就是所谓的“幻觉”。当模型没有相关资料时它倾向于编一个看似合理的答案而检索到的真实内容能有效约束它减少自由发挥的空间。理解了这个架构逻辑后面再看温度怎么调、召回怎么建、Rerank怎么选、Agent怎么搭就都有了依据。2. 参数类术语温度、TopK、TopP到底在控制什么2.1 温度Temperature控制的不是冷热是“胆量”先聊温度这是被误解最深的参数之一。很多人以为温度是控制模型“创造力”的温度越高越有创意温度越低越保守。这个说法大方向对但不够准确容易误导人。我更喜欢用“胆量”这个词来解释。大模型生成每个词时心里其实有一张“候选词排行榜”每个候选词都有一个概率分表示它有多大概率是这个位置的正确选择。温度参数会调整这张排行榜的“松紧程度”。温度低相当于把排名靠前的词的优势放得更大模型基本只选第一名回答就显得稳定、刻板温度高相当于打乱排行榜的集中度让排名靠后的词也有机会被选中回答就更跳跃、更天马行空。那具体应该设多少这完全取决于你的场景。如果是知识问答、客服机器人、代码注释生成我一般把温度设在0.1到0.3之间目的是让答案尽量稳定。如果是文案创作、头脑风暴、故事生成温度可以调到0.7到0.9给模型一些发挥空间。我之前做过一个营销文案生成器温度从0.7调到0.9之后用户明显反馈“更有创意了”虽然偶尔也会出现逻辑不太通顺的句子但瑕不掩瑜。注意温度不是越高越好。超过1.0以后模型输出会开始变得语无伦次甚至出现词不达意的情况。我见过有人图新鲜把温度调到1.5生成出来的内容基本没法看全是病句。2.2 TopK和TopP给候选人“砍名单”接着看榜单模型。温度管的是榜单的“松紧”TopK管的是“谁能上榜单”。TopK的意思是只从概率最高的K个词里面选其他的全部排除。K设成1就是每次只选第一名K设成50就有50个候选词有机会被选中。TopP稍微绕一点但理解起来也不难。它的意思是“累积概率到P为止的词才上榜单”比如TopP设为0.9模型会把概率最高的词一个个加起来直到累积概率达到90%这些词才有资格被挑选。换句话说TopK是“硬性砍数量”TopP是“软性砍概率”。这两个参数在实际使用中往往是搭配温度一起调的。常见的组合是Temperature 0.7TopP 0.9TopK 40这是很多开源模型的默认配置适合一般性的对话和生成任务。如果要做严格的事实性问答我会把Temperature降到0.2TopP降到0.5TopK可以不管模型输出会明显收敛很多。有人问TopK和TopP选一个不就行了为什么还要同时用我的理解是它们管的事不完全一样。TopK可以防止那些概率特别低的“冷门词”突然跳出来把内容带偏TopP则是动态调整候选范围句子长的时候候选词多、短的时候候选词少效果更自然。两个配合着用比单独调一个更细腻。2.3 一个实验看懂三个参数的配合为了让你更直观地理解我拿同一个问题“给我推荐一个北京周末去哪玩的方案”做了三组实验都用同一个模型只改参数。第一组Temperature 0.1TopP 0.3。模型给出的回答是“推荐去颐和园可以欣赏皇家园林风光建议早上出发下午去圆明园”。句子通顺中规中矩几乎每次跑出来的结果都差不多。第二组Temperature 0.7TopP 0.9。模型给出的回答是“如果你喜欢户外可以去奥林匹克森林公园跑步骑行如果对艺术感兴趣798的展览很不错带娃的话中国科技馆有交互展项”。内容开始多样化三次跑出来会有细节差异但整体还靠谱。第三组Temperature 1.2TopP 0.95模型直接开始“放飞自我”给出了类似“不如去鼓楼大街找家胡同里的咖啡馆再配上一碗豆汁儿感受老北京真正的生活气息”这种很有画面感但不太像是客观推荐的回答。这个实验说明参数组合决定了模型输出的“性格”如果你要做的是稳定型应用低温度低TopP是首选如果追求创意和发散再考虑温度高一些。最好的做法是一开始就用默认值跑通再根据效果逐步调整别一开始就猛调。3. 检索类术语什么是召回什么是Rerank3.1 一次提问背后的检索流程现在聊检索这块。前面说的企业知识库问答核心是RAG检索增强生成流程大概是先把企业的所有文档切成很多小段每一段用模型转成一个向量可以理解成这段文本的“语义指纹”用户提问时把问题也转成向量然后在向量库里找和问题最相似的若干文本片段把这些片段连同问题一起发给大模型让它基于这些材料作答。这个过程里第一步找出候选片段专业说法叫“召回”也叫Recall。召回的目的是“宁可多捞不可错过”哪怕捞出来的片段里有些不太相关也不要紧后面还有办法过滤。所以召回阶段的核心指标是“查全率”也就是真正相关的内容有多少被捞出来了。紧接着的第二步把召回的候选片段按相关性重新排序就叫“Rerank”。如果说召回是海选海捞Rerank就是评委打分把最相关的材料排到最前面把不相关的往后压甚至直接淘汰。Rerank阶段的核心指标是“精确率”也就是排在前面的内容到底是不是真的相关。3.2 召回方式的选择关键词、向量、混合召回听着简单做起来有不少花样。最朴素的是“关键词召回”把用户问题拆成几个关键词直接在文档库里搜字面匹配。这个办法在专业名词、编号、人名场景下特别好用因为向量搜索有时候反而会把“报销流程2025版”这种精确短语搞丢。更常用的则是“向量召回”。刚才说过把文本转成向量然后用向量相似度来找相关的内容好处是它能理解语义比如用户问“出差住宿能报多少钱”即使文档里写的是“差旅住房补贴标准”也能被匹配上。坏处是对精确数字、稀有词不够敏感偶尔也会因为语义太接近而捞出一些没用的内容。实际项目里我倾向于用“混合召回”——既跑一遍关键词搜索也跑一遍向量搜索再把两边的结果合并去重一起进后面的Rerank环节。这样做的原因很简单两个召回方式各有盲区合并起来覆盖更全代价是多花一点算力和时间但换来的是答案质量的稳定提升。提示召回数量也不是越多越好一般我控制在20到50条。太多了后面的Rerank环节压力大而且无关内容会稀释注意力太少了可能漏掉关键信息。这个值跟你文档切分粒度、内容质量都有关系建议实测后确定。3.3 Rerank模型怎么选效果差多少接下来重点聊Rerank因为这是整个检索链路里“性价比最高”的一环。很多初学者搭完召回就直接把前3条丢给大模型结果回答质量忽高忽低其实就是少了Rerank这一步。召回阶段用的向量模型擅长“找相似”但不擅长“排序”。向量模型给出的相似度分数在实际使用中经常出现“看起来像但实际不相关”的情况。而Rerank模型专门为排序任务优化过它会把“问题候选文本”拼在一起用更精细的方式计算两者之间的相关性因此排序结果准确率明显更高。市面上常用的Rerank模型比如开源的BGE-Reranker系列、Cohere的Rerank API各家有各家的特点。选型时我一般看三个指标模型对中文的支持效果、单条数据的推理延迟、部署成本。实测下来BGE系列的中文效果不错社区生态也成熟如果只是内部工具用本地部署完全够如果想省事、并发热度高直接调API更合适。用一个真实案例来说明差距。我之前做过一个法律问答应用召回阶段用向量模型排在前面的结果经常包含“看似相关但讨论的是另一个案由”的段落。把Rerank加进去之后同样的测试集答案被标注为“满意”的比例从不到六成提升到八成出头。这不是某一个模型有多神而是Rerank真正把“相关”和“仅相似”区分开了这对下游大模型的生成质量影响非常大。3.4 图谱之外的相关概念Embedding模型聊召回的时侯总绕不开Embedding这个词。实际上它就是前面说的“向量”。把一段文本转成一串数字这串数字就被叫做Embedding。选择什么Embedding模型直接决定了向量召回的效果上限。Embedding模型的选择有几个要点。第一是看维度维度越高通常表示能力越强但存储和计算成本也越高常见的有384维、768维、1024维甚至更高按自己服务器的能力挑。第二是看对比榜单中文场景建议直接看中文语义向量榜单不要只看英文指标。第三是看是否支持领域微调法律、医疗这些专业领域拿通用的Embedding模型效果一般般如果团队有能力用领域数据微调一下会好很多。我自己吃过一个亏早期图省事直接用了某个英文Embedding模型跑中文文档召回效果惨不忍睹后来换成中文模型并做了领域适配才把问题压下去。所以如果你的应用以中文为主、领域有一定专业性一定要花时间选一个合适的中文Embedding模型这是检索效果的第一块基石。4. Agent让模型从“聊天”变“干活”4.1 Agent是什么——不是聊天机器人的升级版聊完参数和检索再来聊聊Agent这是最近一年最火也最容易让人误解的概念。Agent中文叫“智能体”可以理解成“会主动干活的AI助手”。普通聊天机器人是你说一句它答一句答完就结束Agent则能在你给一个目标之后自己拆解步骤、调用工具、检查结果直到把一件事办完。举个例子。你让一个普通聊天机器人“帮我查一下明天从北京到上海的高铁票选下午出发的再帮我订一家火车站附近的酒店”它大概率只能给你一段通用建议不会真的去查。但一个Agent任务它会把任务拆成几个子步骤先调用一个查票工具查车次再根据到达时间筛选下午的班次然后调用一个地图工具找酒店最后再综合所有信息给你一份完整方案。你发现没有Agent不是一个新模型而是一种“新的做事方式”。底层还是同一个大模型但额外加了工具调用、任务规划、记忆管理这些能力。这也是为什么很多人说“Agent 大模型 规划能力 工具使用 记忆”。4.2 Agent的核心能力拆解规划、工具、记忆要做一个能真正干活的Agent至少得具备三个核心能力。第一个是任务规划。也就是把一个大目标拆成多个小步骤的能力。你给它“帮我整理一份市场竞品分析报告”这个目标它能自己决定先搜竞品信息、再分析功能特点、最后按照固定模板输出报告。这里的关键是让模型学会“先做什么、后做什么、哪些可以并行”。目前主流做法有两种一种是让模型自己自由规划适合探索性强、步骤不固定的任务另一种是用事先定好的流程模板来约束模型比如“固定必须先查资料再写结论”适合确定性的业务场景。第二个是工具调用。模型本身只会读写文字但通过“函数调用”机制它可以决定去调用外部工具。比如调用搜索工具查实时数据、调用数据库工具查订单信息、调用计算工具做数据分析甚至调用Python环境执行代码。实现上就是在提示词里描述有哪些工具、每个工具接收什么参数模型判断需要时就会输出一个结构化的调用请求程序再去真正执行。第三个是记忆管理。Agent需要能记住之前说过什么、做过什么否则多轮任务根本做不下去。记忆分为短期记忆和长期记忆短期记忆就是对话上下文但大模型的上下文窗口有限所以需要做筛选和压缩长期记忆则把重要信息存到外部数据库里下次任务开始前再取出来。我做过一个项目管理Agent它会记住用户偏好的周报格式、常合作的同事名称这样每次生成周报就不用重新解释了。4.3 Agent与工作流的区别以及Harness和Skill很多人在学习Agent的过程中会碰到一对容易混淆的概念Agent和Workflow工作流。我用一个简单的区分方式工作流是一条高度稳定的流水线每个环节怎么走、走几步几乎是写死的Agent则更像一个灵活的调度员每一步都可以根据当前情况自主决策。举个招生咨询的例子。用工作流方式做就是用户提问→检索知识库→生成答案→返回四步固定一步不变。用Agent方式做可以是用户提问→Agent判断问题类型→如果是政策类问题就去查政策库如果是流程类问题就去查流程文档如果查不到就收集用户联系方式转人工。区别很明显Agent多了一个“判断”的环节它会根据问题不同走不同的路径灵活性更强。和Agent经常搭配提到的还有两个词Harness和Skill。Harness可以理解成“Agent运行时的框架”负责驱动模型做决策、管理对话状态、调度工具调用。开源社区里LangChain、LangGraph、AutoGen这些框架其实都包含一套Harness你不需要从零实现整个运行机制。Skill则是指某个具体的专项能力比如“生成周报”“查询天气”“计算优惠价”都是一个个SkillAgent通过组合不同Skill来完成复杂任务。把Harness当作手脚Skill当作工具箱Agent就能灵活干活了。4.4 搭建Agent时容易踩的三个坑Agent开发听上去很高级但实际操作中的坑也不少。第一个坑是“试图让Agent一次搞定所有事”。我见过有人想做一个全能Agent既能写周报又能管日程还能做数据分析结果到头来每个任务都做不好。稳妥的做法是先限定一个明确领域比如“只做报销流程助手”把所有工具、提示词、测试数据都围绕这个领域打磨跑顺了再扩。第二个坑是“对模型能力过度自信”。基础大模型决定Agent的上限能力不强的模型你给它再好的框架、再全的工具它也可能规划错乱或调用参数出错。如果你发现Agent频繁做出错误的工具调用先别急着调框架换个更聪明的基础模型往往立竿见影。第三个坑是“缺少兜底机制”。Agent总有判断失误的时候比如它找不到合适的工具就会自己编一个结果出来这是最危险的。一定要在Agent运行外面加一层校验调用工具前检查参数是否合法、工具返回后检查数据是否正常、最终输出前再做一个结果合理性判断。宁可让Agent老老实实说“这个我不会”也不要让它胡编乱造。5. 常见问题与排查技巧实录5.1 生成质量差先别急着加高级模块实际开发中最容易犯的错是一发现问题就想着上复杂方案。有一次朋友跟我求助说他的问答系统回答老是偏离主题打算上一套Rerank再换个更大的模型。我让他先把问题链路的最后一环打印出来看看到底是模型没理解问题、检索结果不相关还是生成时发挥过度。结果发现他用的温度是默认的0.9回答怎么可能稳定。排查生成质量问题我推荐按“先参数、后检索、再模型”的顺序来。第一步检查温度、TopP是否适合场景大多数事实问答场景温度不该超过0.3。第二步检查检索结果把模型收到的上下文打印出来肉眼看看是不是相关不相关就优化召回和Rerank。第三步才考虑换更大的模型或者说调整提示词。按照这个顺序大部分问题用前两步就能解决根本不需要伤筋动骨地换架构。5.2 召回效果差从这三个角度找原因召回效果差也是个高频问题症状都差不多答案没依据、模型说“找不到相关信息”、或者回答的内容跟问题对不上。我排查的时候一般从三个角度下手。第一看数据切分是否合理。有些人在做知识库时把一整篇几千字的文档直接当成一个向量存起来检索的时候确实能召回但召回的内容太宽泛没法支撑具体问题的答案。解决办法是合理切分比如按段落、按章节、按语义完整度来切控制在200到500字左右让每个切块都聚焦一个主题。第二看Embedding模型是否匹配。不同Embedding模型擅长的语义空间不一样如果文档里有大量专业术语而模型没见过这些术语召回效果肯定崩。这种情况优先换领域适配的模型或者用领域数据做微调。第三看问题改写是否缺失。用户提问通常是口语化的但文档表达是书面化的中间存在语义鸿沟。比如用户问“出差打车能报销吗”文档里写的是“交通费用的报销标准”。这时候可以在召回之前加一个“问题改写”环节让大模型把口语问题转成几个更正式的检索词能明显改善召回效果。5.3 Rerank环节常见问题与调优思路加了Rerank也不等于万事大吉我见过几种典型的问题。第一种Rerank之后结果反而变差。这种情况通常是Rerank模型和召回阶段用的向量模型“不是一个世界的人”两边对相关性的理解不一致导致Rerank把原本排前面的好结果打乱了。解决办法是换一个和向量模型匹配的Rerank模型或者调整召回数量让Rerank有足够的上下文信息。第二种Rerank耗时长影响整体响应速度。有些Rerank模型在CPU上跑非常慢尤其对上几百条召回结果时延迟能到几秒。我的经验是召回数量控制在50条以内必要时对Rerank模型做量化压缩或者干脆用并行推理能显著降低延迟。如果你的场景对实时性要求极高甚至可以跳过Rerank用更高质量的召回代替。第三种Rerank的分数不会“自动有用”。很多人把Rerank分数直接拿来当最终答案质量指标这是不对的。Rerank模型打出的分数只是“相对排序依据”并不是绝对的置信度。我更建议拿Rerank排完序的结果做“阈值过滤”——只有分数高于某个阈值才进入生成环节低于阈值就不返回结果宁可答不上来也不给错误答案。5.4 Agent开发常见问题速查表Agent开发遇到的问题更多更杂我整理了一张速查表方便你排查时对照。常见问题可能原因排查思路Agent频繁调用错误工具工具描述不够清晰、模型能力不足检查工具描述里是否写清了输入输出格式必要时更换更聪明的基础模型Agent陷入死循环任务规划逻辑缺少终止条件给Agent加上最大迭代步数比如最多执行5轮超过就强制停止Agent记不住之前说过的话记忆管理不到位检查是否有短期记忆汇总、长期记忆持久化必要时引入向量库存储历史Agent输出格式不对提示词里格式示例不明确在提示词里给出一个完全正确的输出案例并明确要求严格按格式返回Agent在关键时刻胡说八道兜底校验缺失增加输出前校验环节对关键数据做合法性检查无法确认就提示“不确定”多工具组合时参数错乱工具之间上下文传递错误打印Agent的思考过程和工具调用链定位是哪一步的上下文丢失把这张表打印出来贴在工位上每次Agent表现不对就一个个排查比盲目改提示词有效得多。6. 实操总结与个人经验做了这么多AI应用项目我最深的体会是术语终究是工具真正重要的永远是搞清楚一条链路里每个环节的职责以及它们之间如何协作。参数类术语温度、TopK、TopP决定了大模型的输出“性格”不要用一种配置打天下不同任务应该用不同组合。检索类术语召回、Rerank、Embedding决定了模型能看到什么、依据什么作答在这里投入精力优化往往比换更大的模型还管用。而Agent类的概念不只是一堆新名词的堆砌它代表着一套全新的应用架构思路——把模型从一个“会说话的工具”升级成“能办事的助手”。最后再分享一个我自己的习惯每做一个新项目我会先花半天时间画出这条“地图”把每个环节用的技术、参数、模型都标注清楚再动手写代码。在实际运行中一旦结果不对对着地图找问题会非常快。很多看起来高深的问题拆到具体某个环节里其实都很简单。希望这张地图对你也有用。