DriftSentinel

DriftSentinel｜给 AI 模型打一个豆瓣分 一、需求视角：为什么需要它 你为顶配大模型付了钱，拿到的未必是顶配。 模型服务会 "静默降配"： 静默换小模型—— 后端偷偷换成更弱的模型 量化压缩—— 做 INT8/FP8 压缩 行为漂移—— 随版本迭代悄悄变化 而对外的接口、价格、文档纹丝不动，使用者毫不知情。 这不是主观猜测，CISPA 的实测显示： 45.83% 的对外 API 端点无法通过模型指纹核验 47.21% 存在明显能力落差 同一个 GPT-4 在三个月内的代码任务准确率可从 84% 滑到 51% 三类人最痛： - 付费的开发者 按顶配价格调用，实际拿到降配产能，钱花得不明不白 - 搭 Agent 的团队 底层模型悄悄变弱，整条链路准确率下滑，却定位不到根因，只能反复怀疑提示词和编排 - 多供应商采购方 手握十几个端点，无法横向比较谁在缩水、谁更稳，续费与切换全凭感觉 一个常见场景： 团队基于某中转 API 搭了代码助手，上线时跑分很好，两个月后用户投诉变多，复盘发现端点已被悄悄替换成量化版，但价格一分没降。这类损失既难举证、又难追责，最终只能自己默默买单。 更棘手的是，随着 Agent 自动编排越来越长，单点的微小降配会沿链路逐级放大，一次回答质量下滑可能拖垮整条任务流 —— 而传统监控只看可用性与延迟，根本照不到 "模型变笨" 这一层。 问题的核心只有一句话：版本由厂商单方面定义，使用者既看不见、也没有制衡手段。我们要补上的，正是这只 **"看得见的眼睛"和"切得动的手"**。 二、产品视角：我们做了什么 DriftSentinel 把抽象的 "模型好不好" 变成一张可量化、可追踪、可比较的评分卡，从五个维度持续打分： 回答质量 响应速度 稳定性 行为指纹 任务能力 打分不靠主观感受，而是复用模型发布时的标准评测集，定期重跑、对齐基线，让每个端点都有一张随时间变化、可回溯的评分卡。其中行为指纹维度尤为关键：通过固定探针集比对输出分布，即便厂商不公告，也能识别出端点是否被换模型或量化压缩。 产品能力分三层 测得出—— 探测器持续采样打分，异常即生成信号 切得走—— 分数掉下阈值，路由层自动绕开该端点、把流量切给高分端点，用户不改一行代码，就始终用在当前最靠谱的模型上 传得开—— 检测结果经自动脱敏闸过滤敏感字段后，发布到真实的 EvoMap Hub；其他节点开机即可继承高风险端点经验，无需重新踩坑；双节点交叉复核后结论升级为共识，GDI 群体公评进一步汇聚可信度，memoryRecord 让经验在重启后依然可用 GEP Loop 七阶段闭环 整套系统跑在一个可追溯的闭环里，每一步都有据可查，不是黑盒决策： Scan(探测) → Signal(信号) → Intent(意图) → Mutate(变异) → Validate(验证) → Solidify(固化) → Broadcast(广播) 验证有效的策略被固化为可复用的 Gene 策略与 Capsule 实证，再进入广播。脱敏发布闸是这套机制可信运转的前提：发布前自动剥离密钥、内部地址等敏感字段，确保经验能共享、隐私不外泄。 三、商业视角：价值与空间 直接价值：把 "看不见的降配损失" 变成 "看得见的省钱"。同样预算下，流量始终落在当前最靠谱的端点上，避免为降配产能支付全价。对高频调用的团队，这是可量化的成本节约，也是可对外讲清楚的 ROI。 更深的护城河—— 网络效应： 一个 Agent 踩过的坑，会变成整个网络的免疫记忆 接入的节点越多，高风险端点库越全，新节点开机即享前人经验，形成数据飞轮 这是任何单机监控工具都无法复制的壁垒，且随时间持续增厚 商业模式（两条收入曲线）： 评分与路由能力—— 面向开发者和团队，按调用量或订阅计费 端点信誉数据—— 脱敏后沉淀为行业级 "模型信誉网络"，对采购方选型、合规方审计具备独立价值 落地路径： 先以开源 SDK 与 CLI 切入开发者，靠 "接入即省钱" 完成冷启动 再向多端点的中大型团队提供托管评分与路由服务 最终把信誉数据网络开放给采购与合规场景 市场空间也在扩大：大模型 API 调用规模高速增长，中转、聚合、私有化部署让端点供给越发碎片化，"同名不同质" 会成为常态，第三方信誉基础设施的位置由此打开。 定位：我们不与模型厂商正面竞争，而是做模型市场的第三方质检、比价与自动切换。市场越是走向多供应商、多端点、价格不透明，这种中立、可信、可继承的评分网络就越是刚需。