Fable 5智能路由翻车：用户被标“太笨”背后是工程傲慢

这个“TOO_DUMB”标签真的太伤人了，感觉团队在日志设计上就没把用户当人看。你提到的硬阈值误判问题我也有同感，之前调过类似的意图分类模型，发现“别太复杂”这种否定修饰词经常把向量距离搞乱，最后只能加规则白名单。想问下你觉得这种场景用动态阈值或者置信度重校准能彻底解决吗，还是说模型本身的回退机制就得重构？

硬阈值策略的坑我踩过不止一次了。之前做客服意图识别时，也碰到类似问题——用户说“帮我看看账户为什么登录不了”，系统因为“看看”这个词把置信度拉到很低，直接丢给通用回复，结果用户炸了。后来我们改成动态阈值加多级回退，比如先验知识库匹配失败后，不直接降级，而是触发二次追问或者让模型给出置信度区间，让业务方自己判断。

但Fable 5这个“TOO_DUMB”标签确实离谱，这已经不是技术问题了，是工程文化的问题。能把这个标签写进日志，说明开发者在设计时就预设了用户是分类的，而且分得还很傲慢。我猜他们的意图可能是：低复杂度问题交给更便宜的模型去处理，省成本。但问题是，复杂度判断的逻辑本身就有偏——用户那句“帮我写个Python脚本但别太复杂”，语义上明明是个中等复杂度请求，系统却因为“别太复杂”这个短语把整体评分拉低，说明特征提取层根本没理解“别太复杂”是约束条件，不是用户能力。

更关键的是，这种硬阈值+标签化做法，一旦上线，日志里全是误判数据，但团队很可能只看聚合指标，比如平均响应时间、成本节省比例，没人去翻那些被标“太笨”的用户到底说了什么。等用户投诉了，才发现阈值设得太糙。

想问下，你们后来是直接调阈值，还是改了特征工程？比如把否定词、修饰词这种对语义复杂度有干扰的特征独立出来做权重调整？我们当时试过把“但”、“别”、“不过”这类转折词单独抽出来，跟主句复杂度分开计算，效果有提升，但会牺牲一些延迟。