一、上线是第一次交付，不是终点
1.1 为什么演示时很好，上线后变差
演示阶段的问题通常是团队自己挑的，输入规整、场景熟悉；上线之后面对的是真实用户的表达方式，长短不一、意图含糊、夹杂业务黑话。同一套配置，在两种输入分布下的表现自然不同。这不是模型退步了，而是样本变了，而团队没有跟着变。
1.2 三个需要先弄明白的专业名词
1.2.1 反馈闭环
反馈闭环指把使用中的问题收集起来、分析原因、做出调整、再回到使用中验证的完整循环。闭环的关键在于“回到使用中验证”这一环：只收集不验证，改动就成了猜测。
1.2.2 回归集
回归集是一批有标准答案或明确判定标准的样本，用来检查改动有没有带来倒退。它的作用不是证明应用有多好，而是证明这次改动没有把原来能答对的题弄错。
1.2.3 版本与回退
每一次调整都应当成为一个可识别的版本，包括提示词、知识库内容与模型配置。版本可回退，团队才敢改；不能回退，改动就会变得极其谨慎，甚至停滞。
1.3 闭环的四个环节
顺序固定下来，闭环才转得动：
① 收集：把问题连同上下文一起留下来；
② 归因：判断问题出在知识、检索、提示还是模型；
③ 调整：按“先知识、再提示、后模型”的顺序动手；
④ 验证：用回归集确认变好且没变差，再发布新版本。
二、第一环：反馈怎么收集才有用
2.1 三类反馈，各有各的用处
① 显式评价：用户点赞、点踩、填写意见，直接但样本稀疏；
② 隐式行为：追问次数、复制行为、中途放弃、转人工，样本多但含义模糊；
③ 人工抽检：定期抽取一批对话逐条看，费时但最能发现问题类型。
三类反馈的用途不同：显式评价用来发现明显不满，隐式行为用来发现被忽略的挫败，人工抽检用来发现用户没说但确实存在的问题。只用其中一类，判断都会偏。
2.2 反馈要带上结构，而不是只留一句话
2.2.1 为什么只放一个“没用”按钮不够
一条有用的反馈至少包含四项：用户问了什么、应用答了什么、用户期望什么、发生在哪个场景。只留一个“没用”按钮，拿到的是一个数字，看不到具体情形，归因时无从下手。
比较省力的做法是在交互里顺手收集场景信息，比如入口来源、业务模块、用户角色，不需要让用户额外填写，却能让后续分析有据可依。
三、第二环：问题怎么归因
3.1 四类常见归因
同样一句“答得不对”，背后的原因通常是四类之一：
① 知识缺失：业务资料里根本没有这部分内容；
② 检索没命中：资料有，但没被找出来；
③ 提示不当：资料找到了，但回答被引导偏了；
④ 能力不足：资料与提示都没问题，模型本身处理不了这类任务。
3.2 归因要结合输入分布看
3.2.1 归因表的作用
把一批问题按四类归因统计，很快能看出主因在哪。如果七成问题是知识缺失，花力气调提示词基本无效；如果多数是检索没命中，说明切分方式或检索策略需要改。
归因时要注意样本的代表性：只统计投诉来的问题，会高估严重场景；只看随机抽检，又会漏掉低频但影响大的情形。两者结合，判断才稳。
四、第三环：改哪里最有效
4.1 三个可调位置
① 知识与检索：补充资料、调整切分、改进检索策略；
② 提示与规则：明确回答边界、规定输出格式、加入拒答条件；
③ 模型与参数：换用能力更强的模型，或调整生成长度与温度。
4.2 调整顺序：先补知识，再改提示，最后换模型
4.2.1 为什么换模型放在最后
知识缺失就补知识，这是最直接、副作用最小的动作，改完立刻可见。提示与规则的调整负担也轻，但会影响所有场景，改动前要看回归结果。换模型的影响面最大：能力可能提升，语气、格式、拒答习惯也会一起变，连带影响其他已经调好的场景。
把换模型放在最后，还有一个现实理由：换模型往往能掩盖问题，却不一定解决问题。知识没有的部分，换个模型照样答不出来，只是错得更像样而已。
五、第四环：改完怎么验证不倒退
5.1 建一个小而稳的回归集
回归集不必很大，几十到一两百条就能起作用，关键是三条：覆盖主要场景、包含已知的难点、判定标准明确。每条样本要写清期望要点，而不是要求一字不差——大模型的输出本就会有措辞变化。
5.2 验证要看三件事
5.2.1 回归集也要维护
每次改动后跑一遍回归集，重点看三个方向：
① 目标场景是否真的变好：本次要解决的问题有没有改善；
② 其他场景是否变差：有没有把原来答对的题弄错；
③ 耗时与用量是否恶化：回答变长、调用变多，也是隐性退步。
回归集本身也要更新：业务变了、场景变了，样本要跟着换。一套跑了两年的回归集，很可能已经测不出当下的问题。
六、让闭环真的转起来的三件保障
6.1 责任人要明确
反馈谁来看、归因谁来判、调整谁来改、发布谁来批，四件事各有其人，闭环才不会卡在某一步。很多应用停在上线状态，不是没人发现问题，而是没人被赋予处理问题的职责。
6.2 节奏要固定，而不是等投诉
按固定周期做一次回顾，比等问题堆起来再集中处理更有效。周期可以是每周快速过一遍反馈、每个阶段做一次完整归因与调整。节奏固定的好处是问题还小的时候就被发现，改起来也轻。
6.3 每次调整都要留记录
改了什么、为什么改、验证结果如何，三句话就能记下来。这些记录积累起来，会成为团队最实用的经验：哪些改法有效、哪些场景容易反复、哪些问题其实是同一个根源。
七、天翼云息壤在应用服务平台上提供的支撑
7.1 一站式托管，版本与发布有管理
天翼云息壤以一站式的方式支持大模型应用的构建与托管，应用的版本与发布状态可管理。迭代闭环需要的“改动成为一个版本、验证通过再发布、出问题能回退”，因此有了落脚点。
7.2 模型供给与编排，调整有抓手
平台提供多种模型与编排能力，调整提示、切换模型、组合多个步骤都在同一处完成。这让第三环的“改哪里”有具体位置可动，而不必推翻重建。
7.3 知识接入与检索增强
平台支持接入业务知识并以检索增强的方式参与回答，资料更新后可随之生效。对归因中占比最高的“知识缺失”这一类，这是最直接的改善路径。
7.4 观测与用量记录，反馈有数据基础
调用情况、响应耗时与用量有记录可查，配合应用侧的反馈收集，可以把“用户说不好用”落到具体场景与具体请求上，归因才有依据。
7.5 智能体与场景化能力
平台提供智能体与场景化组件的支持，流程类、工具调用类应用可以在平台内完成配置，不必为每个场景单独开发一套。
7.6 安全合规与公开可查的资质
资源与数据之间做隔离，权限按需授予，操作留痕，为应用处理业务数据提供基础条件。平台相关的测评记录与行业实践在公开渠道有据可查，涉及具体条目时建议核对天翼云官网及官方渠道的最新发布，不依据二手转述做判断。
八、科普小结
大模型应用服务平台解决的是“应用能不能跑起来、跑得稳不稳”，而“应用答得准不准、越用越不准怎么办”，靠的是一套持续运转的闭环：反馈带结构地收集、问题按四类归因、调整按知识到提示再到模型的顺序推进、改动靠回归集验证不倒退。
这套闭环听起来像流程工作，实际上是使用大模型应用服务平台时，应用能不能长期可用的分水岭。上线只是第一次交付，之后的每一次调整才是应用真正的成长过程。把闭环立起来，模型的能力才留得住，业务的信任也才积得起来。
