标签品质管理:数据存在哪、怎么取、什么逻辑

对照 ui-designs 最新代码(mocks/tagQuality.ts 628 行)· 2026-08-10

一句话:页面上每个数字都在 DB 里,但分两层存:原始记录逐条存,标签级指标是算出来后存的快照。
而且这个模块的设计比想象中成熟,团队代码里已经把状态拆成了两轴、把「原因→手段」的映射定死了。

3 张

这个功能主要读写的表

2 层

原始记录 + 聚合快照

2 轴

品质状态 × 对应状态

3 处

我的设计要对齐的地方

① 表结构与关系先看这个

注意 SESSION_EXT 是 1:1 扩展表,不改既存的 SESSIONS, 那张表被 161 个文件 import、47 张表关联,加字段影响面太大。本契约期结束后可整体摘除。

② 页面上的每个数,从哪来核心

页面显示	存在哪	怎么来的	说明
正确率 82%	`tags.live.seki`	SQL 聚合	ΣSCORE ÷ 有评分的条数。分子来自逐条判分
未回答率 5%	`tags.live.un`	SQL 聚合	answered=false 的比例。分母是全部,不是有评分的
错误率 1%	`tags.live.err`	SQL 聚合	系统异常,与回答质量无关
满意度 80%	`tags.live.sat` + `satRate`	SQL 聚合	只是参考,不参与达标判定。代码注释写明:母数只限点过评价的人,少数点击就能翻转合否
状态「達成済 / 基準未達」	`tags.state`	纯函数算出	见下面的判定式,存下来避免每次重算
「検収時 92% → 最近 91%」	`baseline` vs `live`	两个字段并存	验收时冻结的成绩 vs 线上实况,分开存才说得清「当初达标过」
公开开关	`groups.publish` AND `tags.publish`	两级 AND	大分类关了,小分类再开也没用
「対応中 · 担当森川 · 期限 06-18」	`tag_actions`	人填的	和品质状态是两套轴,见第 ④ 节

③ 判定逻辑:代码里写死的,直接抄不用自己发明

门槛     正确率 ≥ 90%    未回答率 ≤ 8%    错误率 ≤ 2%
最小样本  30 条已复核

evaluateState(m):
  复核数 == 0        → 未着手
  复核数 < 30        → データ不足
  三个门槛全过        → 達成済
  否则               → 基準未達          ← 注意不叫「改善中」了

満足度不参与判定 —— 母数只有点过评价的人，少数点击就能让合否翻转

还有两条容易漏的:

達成済会黏住,线上跌破门槛也不自动降级,只置 regression_flag 提示人
劣化用绝对阈值判,不是相对基线,91→89.9 和 91→60 目前不区分(这是个可以提的改进点)

④ 两轴状态团队 8/2 刚改的,重要

原来只有一轴,叫「改善中」。团队自己把它否了。
代码注释里的原话:「旧名是活动的名字,但实体只是 evaluateState 的 else 分支。也就是说它只是"复核了30条但没达标"这个测量结果,没有任何人在改善的保证,名字在假装干活。」

更要命的是没有出口:唯一的出路是"数据变多、数字上去"。如果类似问题不再来,样本不增长, 这个标签就永远卡在那里。看板被不动的卡片塞满,人就不看了。

拆开之后,「基準未達且未対応且样本也不增长」可以被识别为停滞, 然后落到「見送り」结案。这是给永远观察不完的卡片一个出口。

⑤ 原因 → 手段:这是 agent 的输出格式和你的活直接相关

原因	什么意思	该打的手	成本	影响范围
`nosrc`	根据本来就不存在	加知识	1	只影响这个问题及周边
`wrongsrc`	有知识但内容错了/旧了	修知识	2	含该论点的全部问题
`routing`	问题流去了别的分类	改标签分流	2	本标签 + 目标标签
`scope`	本来就不该答	让 AI 不答,返回引导语	3	本标签
`usage`	根据是对的,但用法不对	改提示词	4	全标签全问题

成本排序背后是一条硬道理(代码注释原文):
「ナレッジは加算的でローカル(足しても他は壊れない)/ プロンプトは乗算的でグローバル(1行変えると全タグに効く=全タグが壊れうる)」

所以同样是"提升精度",顺序是:先加知识,同类失败攒够几件、跨多个标签了,才动提示词。

⑥ 三档分层在这里怎么落别把统计交给 agent

步骤	用什么	为什么不能换
判一条对不对	单次模型调用	输入固定三样,输出一个分。一次评测跑几百次,要批量并发且结果稳定
算标签正确率	SQL	就是加减乘除。用 agent 算:慢、贵、而且不可复现,而研究计划书承诺的正是「同条件可复现」
分析为什么不达标	Agent	要翻检索记录、翻原文、翻同类案例才能定原因。这才是 agent 该干的

⑦ 我之前的设计,有三处要对齐重要

项	我写的(felo-mygpt)	团队代码里的(以此为准)
误答原因	4 类:missing_source / prompt_issue / hallucination / out_of_scope	5 类:nosrc / wrongsrc / routing / usage / scope 他们把「没有根据」和「有但错」分开了,还多了「分流错误」,更准
标签状态	单轴,4 个值	两轴:品质状态 × 对应状态我漏了「人的意志」这一轴,以及停滞检测
手段与去向	没有这个概念	MEANS + MEANS_DEST 选了手段还要能跳到干活的地方,否则「只是决定了,什么都没修」

结论:改我的,不改他们的。他们的定义写在 UI 代码里、已经跑起来了,而且想得比我细。我的 FailureCause 枚举要扩成 5 类,MHLWTag 要加对应状态那一轴。

附:两条可以提的改进点

问题	说明
劣化判定用绝对阈值	91%→89.9% 和 91%→60% 目前都只是「要再確認」,不分轻重。建议加相对跌幅,大跌立刻升级
验收基线什么时候写	状态转「達成済」时应该自动冻结一份 baseline,但代码里没看到这个写入动作 , 如果没有,「検収時 92%」这个显示就永远是空的

Generated as a visual answer · open in browser

标签品质管理:数据存在哪、怎么取、什么逻辑

① 表结构与关系 先看这个

② 页面上的每个数,从哪来 核心

③ 判定逻辑:代码里写死的,直接抄 不用自己发明

④ 两轴状态 团队 8/2 刚改的,重要

⑤ 原因 → 手段:这是 agent 的输出格式 和你的活直接相关

⑥ 三档分层在这里怎么落 别把统计交给 agent