北京
把日志流交给一个每百万输入token只要0.042美元的模型做过滤，听起来像是一笔稳赚的买卖。输出token还免费，价格低到让不少团队动了心思：要么用它触发值班告警，要么在把日志送进更大的模型之前，先让它把日常噪音丢掉。
但便宜不等于好用。有人拿TypeSafe Jev做了两轮实测，一轮是3000条合成的支付与结账日志，另一轮是Loghub数据集里的5000行。结果撞上了几个没预料到的问题：正常部署也能引发告警风暴，而预过滤管道花掉的钱，比把原始日志直接丢给GPT-5.6 Luna还多。
下面就是哪里出了错、什么修好了它，以及最终跑通的代码模式。
离散标签埋下的坑
第一版实现里，团队让Jev把每条进来的日志分进三个桶之一：page、ticket、ignore。这套设置跑出了零误报，却漏掉了一次数据库复制延迟。
测试数据里，一个副本落后了47分钟，而主库还在继续接受写入。应用把这件事记成了INFO级别。因为日志级别是INFO，Jev选了ticket，而不是page。
模型其实在概率分数里看见了危险。对这次47分钟的延迟，Jev给出的告警概率在0.24到0.31之间，而正常的12秒延迟只有0.11。是离散选择头把这个差异丢掉了，输出ticket。
团队试着改提示词来修。他们告诉Jev，如果客户数据面临风险，INFO级别不应阻止告警。这一改，告警风暴来了。离散选择头变得过度敏感，在3000行里生成了189次误报page，其中122次是完全正常的部署通知。
把概率阈值搬进应用代码
改提示词太钝，控制不住决策边界。与其调提示词，不如把决策逻辑挪进应用代码。
他们去掉了三路紧急度分类，只问Jev一个布尔问题：这条日志现在该不该呼叫工程师。然后不依赖true或false的答案，而是从响应对象里读出连续概率，在JavaScript里直接设阈值：
- 用createJevPager创建分页器，pageAbove设为0.50
- 构造日志对象，service为orders-db，severityText为INFO，body写明副本延迟47分钟且主库仍在接受写入
- 调用pager.decide拿到decision
- 若decision.page为真，用decision.probability触发PagerDuty
把阈值设在0.50，代码抓住了数据集里全部500起事件，包括全部57行复制延迟日志，同时在3000条测试日志上零误报。
只问一个布尔问题还压低了token数。单问题提示词跑完3000次调用花了0.062美元，而要求多个字段时要0.087美元。
3000条日志上的横向对比
他们把概率阈值和传统严重级别过滤、以及OpenAI GPT-5.6 Luna做了对比。Luna通过同一个网关密钥调用，使用结构化JSON输出。
传统日志级别作为值班触发器是失败的。按ERROR分页只抓到不到一半的事件，还因为500个预期内的校验错误把工程师叫醒。
Luna抓到了57起复制延迟事件中的46起，但Azure内容过滤丢掉了130行包含搜索注入字符串的日志。Jev则把所有行都处理完了，没有报错。
预过滤反而推高账单
很多开发者考虑把Jev放在更大的语言模型前面，丢掉日常日志来降低总成本。财务结果取决于你丢掉日志的比例。以一百万条日志的流为例。
如果下游模型是GPT-5.6 Luna，每百万输入token 0.20美元、每百万输出token 1.20美元，用Luna处理100万条日志要花120美元。
Jev每条日志大约消耗537个输入token，处理一百万条要花22.55美元。要打平，Jev必须丢掉至少18.8%的日志流。
在Loghub HDFS数据集上，Jev表现得很保守。它的默认分数保留了99.16%的行，只丢掉0.84%。把Jev加为预过滤器，总账单反而从120美元涨到了142美元。
如果你的过滤标准只能丢掉一小部分日志，加一个分诊模型就等于加了一笔附加费。
缓存重复的日志模板
系统日志大多由静态模板构成，变化的是ID、IP地址和时间戳。
在调用Jev之前，他们先清洗日志正文，把IP地址和block ID替换成固定字符串。然后对清洗后的字符串算SHA-256哈希，查一个五分钟过期的内存缓存：
- 用sanitizeLog把IP替换为[IP]、把blk_开头的ID替换为[BLOCK]
- 用createHash('sha256')对清洗后的字符串求哈希
- 若缓存命中则直接返回概率，否则调用Jev并把结果写入缓存
在2500行的HDFS样本上，有2412行命中了此前的模板。这个内存缓存把模型调用从2500次降到88次，token消耗从1350308降到48019。
日志评估的生产规则
第一，在本地保护错误。如果日志带着FATAL或CRITICAL级别进来，直接在代码里路由。不要为已经需要人工查看的记录花模型token。
第二，避免多字段schema。只问一个布尔问题，让token数保持低、响应保持快。
第三，读取连续概率。不要让模型去选离散的紧急度桶。把切分阈值放在应用代码里执行。
第四，把你的架构分开。（原文在此处截断）
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
