New Relic AI Evaluation：按业务结果评判 Agent，而不只看单次 LLM 调用

New Relic 于 2026 年 10 月 6 日推出 AI Evaluation，作为其 AI Observability 平台中的新能力。它的设计赌注很直白：只看孤立的单次 LLM 调用，无法评判一个 AI 应用。AI Evaluation 在「事务级」工作，把响应质量与模型行为关联到分布式 trace，让工程师能判断故障究竟始于提示词、检索层、模型还是后端——并看清它在业务层面花了多少代价。这是一个信号：可观测性厂商如今已把 Agent 流量视为常态。

AI Evaluation 在事务级工作，而非单次 LLM 调用

只评测单次 LLM 调用的问题

如今大多数 AI 评测都是点式方案：你发一个提示词、给响应打分、然后继续。它有用，但不够。生产中的 AI 应用不是一次调用——而是一串调用，被检索、工具调用与后端服务包裹，并最终挂在用户的目标上。当这个目标失败时，给单次调用打分只会给你一个数字，却不告诉你原因。New Relic AI Evaluation 从相反的假设出发：想知道一个 AI 功能为什么失败，就得看事务，而不是调用。

# The core idea: evaluate at the transaction, not the LLM call.
# A transaction is the whole user goal, end to end.

EVALUATION = {
    'unit': 'transaction',        # not a single prompt/response
    'links': ['response_quality', 'model_behaviour', 'traces'],
    'measures': ['business_impact', 'guardrail_performance'],
    'scope': 'developer-to-production lifecycle',
}

「事务级评测」意味着什么

AI Evaluation 在「事务」这一层级，评估整个「开发者到生产」生命周期中的 AI 行为——而事务正是用户真正在乎的端到端单位。它把响应质量与模型行为关联到分布式 trace，这一步正是把模糊的质量分变成诊断的关键：你不再只知道「答案错了」，而能看到是提示词缺了上下文、检索层给了错文档、模型产生了幻觉，还是某个后端服务返回了错误。这条区分，就是「一块仪表盘」与「一件调试工具」之间的差别。

# Emit OpenTelemetry spans for every step, tagged with a user ID
# so an agent action can be tied to a downstream outcome.

span = tracer.start_span('agent.turn')
span.set_attribute('user.id', user_id)
span.set_attribute('agent.step', step_name)
span.set_attribute('retrieval.docs', len(docs))
span.set_attribute('model.name', model)
span.set_attribute('tokens.in', usage.prompt_tokens)
span.set_attribute('tokens.out', usage.completion_tokens)
span.end()
# One trace shows which layer actually caused the failure.

分布式 trace 揭示故障出在哪一层

实时护栏表现

还有一块更安静、但很重要的内容：该功能提供对 AI 护栏表现的自动化、实时洞察。护栏——约束模型可为之事的过滤器与策略——通常被当成「配置一次」的东西。实际上，它需要像其他任何生产控制一样被监控。如果某个护栏开始比平时频繁得多地触发，那是一个信号：要么流量变了，要么护栏误伤，要么它背后的模型发生了漂移。把这一比率实时呈现出来，团队才能继续信任那些本用来保护自己的控制。

# Attribute a failed transaction to the layer that caused it.

def diagnose(trace, expected):
    if trace.prompt_missing_context(expected):
        return 'prompt'
    if trace.retrieval_missed(expected):
        return 'retrieval'
    if trace.model_refused_or_hallucinated(expected):
        return 'model'
    if trace.backend_error():
        return 'backend'
    return 'unknown'

更大一次发布的一部分

AI Evaluation 并非孤立的发布。New Relic 的更广泛发布还包含 Ground Truth 命令行工具与 Infrastructure 360，两者都意在把可观测性数据更直接地交到开发者与运维者手中。合起来看，方向很清楚：厂商在赌 AI 工作负载如今是主角、而非配角，围绕它的工具应当与其余一切同处一个可观测性平台，而不是被塞进一个「只服务于 AI」的孤岛。

# Guardrail performance is a first-class metric, monitored live.

def guardrail_alert(traffic):
    trips = [t for t in traffic if t.guardrail_tripped]
    rate = len(trips) / max(len(traffic), 1)
    if rate > 0.02:            # more than 2% tripping
        page_on_call('guardrail-trip-rate', rate)
    return rate

# Guardrails that silently fire are guardrails nobody trusts.

护栏表现被当作一等指标来监控

这对 Agent 团队意味着什么

如果你在跑 Agent，实用的结论是：结果与 trace 是同一套度量的两半。只有成功率、没有 trace，无从知道该修什么；只有 trace、没有结果指标，无从知道修了有没有用。AI Evaluation 值得注意之处，不在于某个单项功能，而在于它把这种配对「写成了规矩」：用事务判断「有没有成功」，用 trace 弄清「为什么」。早早养成这一习惯的团队会发现调试回路显著变短，因为他们不再猜是哪一层，而是能直接看到。

# Wire evaluation into CI so regressions never reach production.

def ci_gate(eval_run, threshold=0.9):
    if eval_run.quality_score < threshold:
        raise SystemExit('Blocked: quality regressed below gate')
    if eval_run.guardrail_trip_rate > 0.02:
        raise SystemExit('Blocked: guardrails tripping too often')
    return 'ship'

一份实用的可观测性清单

无论你是否采用这款产品，这五件事你都能做。一：用 OpenTelemetry span 给每个 Agent 步骤打点，并带上用户 ID，让结果可以被归因。二：定义一小组与真实目标挂钩的事务级成功指标。三：把护栏触发率当作实时指标来监控，并设一个告警阈值。四：按事务、而非按调用，采集 token 与延迟成本。五：在 CI 中以质量与护栏的回退为门禁，卡住发布。这些都不必依赖某个特定厂商——但它们都要求你，把 AI 功能当作系统，而不是提示词。