小红书推荐系统评测 Agent：上下文驱动的 LLM-as-Judge 实践

推荐语

点击率、停留时长和互动率能够判断推荐策略是否改变了用户行为，却难以说明推荐内容具体发生了什么变化，为补足这层内容诊断，小红书构建了上下文驱动的推荐评测 Agent，以一次推荐请求为评测单元，通过确定性规则与 LLM-as-Judge 的分工，对用户当时看到的内容进行分维度判断。

01

从行为指标回到推荐现场

推荐策略上线后，研发团队首先关注 CTR、停留时长和互动率，这些指标汇总大量用户反馈，能够判断用户行为是否变化，但不会保留某个用户当时看到了什么、内容如何排序，或者策略实际改变了哪些内容特征。

例如，两组推荐结果可能得到接近的 CTR，却由完全不同的内容结构产生：一组兼顾兴趣匹配与内容探索，另一组依靠更强的标题刺激获得点击，同时出现类目集中。仅凭 CTR，这两种体验会被压缩成相近的数字；反过来，内容结构改善也不能直接推导出用户行为指标一定提升，实验分析还需要一组来自内容侧的证据。

我们把对这类内容变化的系统化判断称为语义评测。它回到具体推荐请求，描述内容在质量、兴趣、时效和组合方式上发生了怎样的变化。行为指标用于验证线上效果，语义评测提供可下钻的内容证据；两者对应同一次推荐，但承担不同任务。过去这类内容侧判断主要依赖人工抽样，评测人员需要补齐背景、逐篇检查，再汇总结论，覆盖规模和判断一致性都会受到限制。LLM 让规模化语义理解成为可能，但一次模型调用并不等于可靠评测；稳定的判断还需要清晰的上下文边界、评分标准，以及规则与模型之间的明确分工。

02

把一次推荐作为评测单元

回到具体推荐请求后，首先要确定评测什么，普通内容质检关注一篇内容本身是否安全、完整或优质，然而推荐评测还要回答这些内容在此时、以这一顺序呈现给这个用户时，整体表现如何。因此，推荐评测的最小单元不是孤立的内容，而是一次带有完整现场的推荐请求。本文将它概括为：

EvaluationContext = <UserState, RequestTime, OrderedItems>

• UserState 包括用户画像、长期兴趣和近期消费，决定内容是否适合当前用户

• RequestTime 是推荐实际发生的时间，决定内容在当时是否仍然有效

• OrderedItems 保留用户看到的内容及其顺序，用于判断单篇质量之外的重复、集中和整刷体验

• EvaluationContext 记录“当时发生了什么”，实验目标则限定“本次想验证什么”。同一篇露营笔记，对长期关注户外的用户可能符合稳定兴趣，对刚刚连续消费过多篇露营内容的用户则可能造成重复；同一篇节日攻略，在活动前后也会得到不同的时效判断。

用户状态、请求时间或内容顺序中的任一项发生变化，评测样本就随之变化，这三个要素共同定义了一次推荐请求。因此，上下文驱动不只是向 Prompt 中增加字段，它还会改变评测系统组织采样、执行和结果的方式：

• 采样以推荐请求为单位，保存当时的用户状态、请求时间和有序内容列表。

• 评测同时覆盖单篇、完整列表和用户请求三个粒度。

• 每个结果都绑定对应的上下文与评测版本，不能脱离现场单独解释。

• 上下文缺失、获取失败和未请求需要分别记录，不能由模型自行补全。

• 只有当采样、执行和结果都围绕一次推荐请求组织时，上下文才真正进入评测体系。

03

从上下文到判断：评测 Agent 的执行链路

确定评测单元后，最直接的做法是把 EvaluationContext 和一句“请打分”交给 LLM，这可以得到一次判断，却很难形成稳定的评测能力。因为所有证据堆在同一个 Prompt 中，模型可能跨维度使用信息；多个问题被压缩成一个总分后，输入缺失、规则命中和模型失败也难以区分。评测 Agent 负责组织上下文、解析评测配置、调度规则与 LLM 评测器，把一次判断组织成有状态、可追踪的执行链路。

04

从体验问题到评测标准

前面讨论了评测 Agent 如何组织一次执行，真正决定判断是否稳定的，是每个评测分支回答什么问题、可以使用哪些证据。但是推荐体验无法直接压缩成一个总体分，内容质量关注内容本身，时效性依赖推荐发生的时间，兴趣匹配需要结合用户状态，多样性则必须观察完整列表，评价对象和证据不同，就需要拆成彼此独立的评测维度。

这些维度分为两类：基础体验维度用于检查每次推荐都应满足的质量底线；目标符合度，用来验证策略希望改变的内容特征是否真正出现在结果中。以营销内容治理为例，目标符合度判断营销感是否下降，基础体验维度继续检查兴趣匹配、多样性和内容质量是否受损，从而将“策略是否生效”与“是否带来体验代价”分开。

当前语义维度采用 0/1/2 三档评分，各档条件由相应的评分规则单独定义，不把“好、一般、差”的尺度留给模型自由发挥。每次判断输出分数、理由和执行状态，分数与理由表达业务判断，状态记录材料是否完整、评测是否成功。各维度结果首先独立保留，综合分只用于任务概览和样本筛选；对于明确不可接受的问题，任务可以设置门控条件，防止其他维度的高分将其掩盖。进入诊断时，仍需回到具体维度、内容、理由和执行状态，而不能只看聚合后的数字。这些标准描述的是一次推荐在内容侧呈现出的语义特征，而不是孤立内容的质量，曝光后的点击、停留、互动和负反馈沿独立链路输出，不作为 LLM 语义评分的证据，两类结果只在分析阶段对齐。

05

确定性规则与 LLM 的分工

评测标准明确了问题和证据边界，但并不意味着所有判断都应该交给 LLM。我们的基本原则，是结构化字段能够确定的结论由代码直接计算；代码能够稳定提取、但仍需语义解释的信息，先转换为统计特征再交给 LLM；只有依赖用户、内容或策略语境的判断，才由 LLM 在限定范围内完成。

评测标准进入批量任务前，人工与模型需要在相同输入、相同 Rubric 下独立评分。对于不一致样本，先区分问题来自输入缺失、标准边界模糊还是模型理解偏差，再决定调整数据、规则或 Prompt，而不是直接迎合人工结果修改分数。一致性也不能只看“完全相同率”，三档分数可能集中在中间档，单一一致率容易高估 Judge 的能力；更有意义的观测包括加权 Kappa、0 分问题样本的召回率，以及人与人之间的一致性上限。

当 Prompt、规则或模型升级时，除了重新计算一致性，还要在同一批样本上对比新旧版本，由评审者标记新结果相对基线是改善、持平还是退化。这里衡量的是输出是否更符合评测标准，而不是分数是否发生变化。规则负责守住确定性事实，LLM 处理边界明确的语义问题，人工校准和版本回归持续检查判断尺度。

06

让评测结果可比较、可回放

一次任务能够产出评分，并不代表结果可以跨时间比较。推荐侧的用户画像和 Feed 候选状态会变化，评测侧的 Prompt、规则阈值、输入裁剪方式和模型版本也会迭代。如果这些变量没有被同时记录，两次评分的差异就无法解释，它可能来自推荐结果，也可能只是输入数据或判断尺度发生了变化。

因此，评测链路需要同时固定两类条件：输入快照记录评测发生在什么现场，评测版本记录系统依据什么标准作出判断。只有两者能够分别追溯，分数变化才有明确的比较基础。

回放前，系统会核对快照版本、用户、请求时间、内容集合及数据状态。在同一份输入快照上，使用原评测配置可以追溯历史结果产生的条件；显式替换 Prompt、规则、权重或模型配置，则可以比较新旧评测器的判断差异。每份结果都会记录实际生效的配置版本，作为解释差异的坐标。当输入现场和评测标准都能对齐后，结果才适合进入实验组与对照组的比较，并继续下钻到具体请求和内容。

07

从请求级判断到实验级诊断

前面的链路解决了单次推荐如何在固定现场和评测标准下被稳定判断，但实验决策面对的不是一个请求，而是实验组和对照组中的大量请求。这里需要解决一个新的问题：如何把局部的语义判断组织成可比较的实验级证据，同时保留返回原始推荐现场的路径，只有这样，LLM-as-Judge 的输出才能从单次评分进入实验分析。

为此，系统不会只保存一个综合分或一段模型结论。每条有效结果都与评测维度、单篇或整刷粒度、内容位置、分数和判断理由关联，并保留实际输入、执行状态与评测版本。这种组织方式使同一份结果具备两个方向的能力：向上可以按实验分组聚合，观察不同维度的整体变化；向下可以回到用户请求、有序内容列表和单篇证据，复查判断是如何产生的。

请求级结果进入实验分析后，首先分别观察策略目标和基础体验。前者判断策略希望增加或减少的内容特征是否真实发生变化，后者继续检查内容质量、时效性、兴趣匹配和多样性。以一项希望降低某类内容曝光密度的策略为例，目标内容占比下降只能说明调节方向可能已经生效；如果兴趣匹配或整刷多样性同时下降，还需要判断策略是否以其他体验为代价。

实验级比较也不能退化为两个平均分相减。相同均值可能对应完全不同的样本结构：变化可能只集中在少量低分请求，也可能出现在特定内容位置；单篇质量保持稳定时，整刷仍可能出现类目集中或语义重复。因此，分析还需要结合有效样本数、分数分布、低分请求以及单篇与整刷结果，判断差异究竟发生在哪里。

当某个维度出现差异后，系统再沿“维度分布 → 用户请求 → 有序内容列表 → 单篇结果 → 输入证据与判断理由”逐层下钻。以多样性下降为例，实验级结果只能说明整刷结构发生了变化。展开代表请求的内容列表，才能进一步区分类目集中、作者类型集中、标题近似或语义重复。分数在这里承担定位索引的作用，真正支持诊断的是与分数绑定的内容、证据、理由和执行状态。这样，聚合结论最终能够落到可复查的推荐现场，而不是停留在一段无法验证的模型总结。

这套诊断回答的是推荐结果发生了什么变化，并不直接证明用户行为已经改善，也不能单凭内容证据确定系统根因。CTR、停留时长和互动率仍用于验证用户是否作出了不同响应，语义评测则解释变化发生在哪些内容和请求中，两者共同进入实验分析但不能彼此替代。评测 Agent 可以输出组间差异、代表请求和有证据支持的语义解释；至于问题是否来自召回、融合或打散环节，还需要结合推荐链路数据或后续实验继续验证。

08

从单次判断走向连续用户模拟

前面以一次推荐请求为边界：给定用户状态、请求时间和有序内容列表，LLM-as-Judge 判断这次推荐呈现出怎样的语义特征。但是这个过程不会预测用户接下来会点击还是跳过，也不描述一次消费如何改变后续兴趣。

进一步的 LLM-as-User 会把评测对象从一次固定请求扩展为连续交互。模型观察当前内容，行为模块生成经过校准的动作概率，再根据曝光和消费更新短期兴趣、重复感与疲劳状态，并进入下一轮推荐。除语义判断外，这条链路还必须处理行为生成和状态转移。同时也需要分别验证单次动作是否准确、群体行为分布是否接近真实日志，以及在历史实验中能否判断正确的策略方向，偏正向、过度理性和多轮误差累积，都会让一段看似合理的模拟轨迹偏离真实用户。

因此，LLM-as-User 目前更适合作为策略上线前的离线预筛和问题探索工具，不替代线上 A/B 实验。这也是推荐评测从“理解一次推荐”走向“模拟连续体验”时，需要继续探索的方向。

///

结语

这套实践把一次推荐定义为可复查的评测单元，并将上下文构建、评测标准、规则判定、语义判断、版本快照和人工校准串成一条受约束的工程链路。它不追求用一个总分概括体验，重点在于补充可定位、可下钻的内容证据。Agent 的价值来自模型、规则、数据和人工校准之间的受控协同，它不会替代真实行为，也无法消除模型偏差。但当每次判断都能对应到具体现场、证据、标准和版本时，推荐体验就能从依赖专家感受的模糊问题，转化为可观察、可比较、可追溯的工程对象。

///

团队介绍

招聘信息

• 小红书引擎架构部内推简历投递：

  [email protected]

• 小红书质效研发部内推简历投递：

  [email protected]

• 小红书社区推荐算法团队内推简历投递：

  [email protected]

• 小红书社区推荐产品团队内推简历投递：

  [email protected]