评估驱动型LLM产品开发：医疗保健领域的实践心得 - AI与医疗健康

大型语言模型（LLM）及其应用领域的发展速度非常迅速。成本正在下降，基础模型的能力不断增强，能够处理文本、图像和视频中的通信。开源解决方案在多样性和能力方面也迅速增长，许多模型足够轻量，可以进行探索、微调和迭代，而不会产生巨大开销。最后，Databricks和Nebius等云人工智能训练和推理提供商正使组织越来越容易将实用AI产品从概念验证扩展到生产就绪系统。这些进步与LLM业务用途的多样化和代理应用的兴起相辅相成，其中模型计划并执行涉及与工具或其他代理互动的复杂多步骤工作流程。这些技术已经在医疗保健领域产生了影响，并预计会迅速增长。

所有这些能力使得入门变得令人兴奋，为特定用例构建基线解决方案可以非常快速。然而，本质上LLM是非确定性的，比传统软件或机器学习模型更不可预测。因此，真正的挑战在于迭代：我们如何知道我们的开发过程正在改进系统？如果我们修复了一个问题，如何知道这个更改不会破坏其他内容？一旦投入生产，我们如何检查性能是否与开发阶段相当？回答这些涉及单一LLM调用的系统的问题已经足够困难，但对于代理系统，我们还需要考虑所有单独的步骤和它们之间的路由决策。为了解决这些问题——从而获得对我们构建系统的信任和信心——我们需要评估驱动型开发。这是一种将迭代、可操作的评估置于产品生命周期核心的方法，从开发和部署到监控。

作为Nuna公司的数据科学家，一家医疗保健AI公司，我一直在领导我们的努力，将评估驱动型开发嵌入我们的产品中。在领导层的支持下，我们分享了一些迄今为止学到的关键教训。我们希望这些见解不仅对在医疗保健领域构建AI的人有价值，也对任何开发AI产品的人，特别是那些刚刚开始旅程的人有所帮助。

本文分为以下几个部分，旨在解释我们从文献中的广泛学习以及从经验中获得的技巧和提示。

在第1节中，我们将简要介绍Nuna的产品，并解释为什么AI评估对我们以及整个医疗保健领域的AI如此关键。
在第2节中，我们将探讨评估驱动型开发如何为我们的产品在部署前阶段带来结构。这涉及使用LLM作为判断者和程序化方法开发指标，这受到了这篇优秀文章的强烈启发。一旦建立了可靠的判断者和专家对齐的指标，我们将描述如何使用它们通过错误分析向正确的方向迭代。在本节中，我们还将触及聊天机器人应用带来的独特挑战。
在第3节中，我们将讨论使用基于模型的分类和警报来监控生产中的应用，并利用这些反馈进行进一步改进。
第4节总结了我们学到的所有内容。

任何组织对这些主题的看法都会受到其使用工具的影响——例如我们使用MLflow和Databricks Mosaic Evaluation来跟踪我们的预生产实验，并使用AWS Agent Evaluation来测试我们的聊天机器人。然而，我们相信这里提出的想法应适用于任何技术栈，并且有许多优秀的选项可供选择，例如Arize（Phoenix评估套件）、LangChain（LangSmith）和Confident AI（DeepEval）。在这里，我们将关注主要涉及提示工程迭代的项目，但类似的方法也可以用于微调模型。

1.0 Nuna的AI和评估

Nuna的目标是降低慢性病患者的护理总成本，改善他们的生活，例如高血压（高血压）和糖尿病，这些疾病共同影响着超过50%的美国成年人。这是通过一个以患者为中心的移动应用程序实现的，该应用程序鼓励健康的习惯，如服药依从性和血压监测，此外还有一个以护理团队为中心的仪表板，将来自应用程序的数据组织给提供者。为了让系统取得成功，患者和护理团队必须觉得它易于使用、引人入胜且具有洞察力。它还必须产生可衡量的健康益处。这一点至关重要，因为它将医疗保健技术与大多数其他技术领域区分开来，在这些领域中，商业成功更紧密地与参与度相关。

AI在产品中扮演着关键的角色，面向患者和护理团队：在患者方面，我们有一个内置的护理教练聊天机器人，以及诸如药物容器扫描和餐食照片扫描等功能。在护理团队方面，我们正在开发总结和数据排序功能，以减少行动时间并为不同用户提供定制的体验。下表显示了四个由AI驱动的产品组件，其开发过程启发了本文，并将在以下部分中提及。

产品描述 | 独特特征 | 最重要的评估组件

--- |---|---

药物容器扫描（图像到文本） | 多模态，有明确的地面实况标签（从容器中提取的药物详细信息） | 代表性开发数据集、迭代和跟踪、生产监控

餐食扫描（成分提取、营养洞察和评分） | 多模态，混合明确的地面实况（提取的成分）和LLM生成的评估及SME输入的主观判断 | 代表性开发数据集、适当的指标、迭代和跟踪、生产监控

内置护理教练聊天机器人（文本到文本） | 多轮对话记录、工具调用、广泛的人物角色和用例、主观判断 | 代表性开发数据集、适当的指标、生产监控

医疗记录总结（文本和数值数据到文本） | 复杂的输入数据、狭窄的用例、对高准确性和SME判断的迫切需求 | 代表性开发数据集、专家对齐的LLM判断者、迭代和跟踪

图1：显示Nuna公司AI用例的表格，这些用例将在本文中提到。我们认为这里提出的评估驱动型开发框架足够广泛，适用于这些和类似的AI产品。

尊重患者及其委托给我们的敏感数据是我们业务的核心。除了保护数据隐私外，我们还必须确保我们的AI产品以安全、可靠和符合用户需求的方式运作。我们需要预见到人们可能如何使用这些产品，并测试标准和边缘用例。当错误可能发生时——例如从餐食照片中识别成分——我们需要知道在哪里投资以建立让用户轻松纠正的方法。我们还需要警惕更微妙的失败——例如，最近的研究表明，长时间使用聊天机器人可能导致孤独感增加——因此我们需要识别并监控令人担忧的用例，以确保我们的AI符合改善生活和降低护理成本的目标。这与NIST AI风险管理框架的建议一致，该框架强调预先识别可能的滥用场景，包括边缘情况和意外后果，尤其是在医疗保健等高影响领域。

该系统仅提供健康支持，不打算用于医疗诊断、治疗或替代专业医疗判断。

2.0 部署前：指标、对齐和迭代

在LLM驱动产品的开发阶段，建立与业务/产品目标一致的评估指标、足够代表生产行为的测试数据集以及用于计算评估指标的稳健方法非常重要。有了这些，我们就可以进入迭代和错误分析的良性循环（详见这本短书）。我们越快朝正确的方向迭代，成功的几率就越高。同样不言而喻的是，当测试涉及通过LLM传递敏感数据时，必须在一个安全的环境中进行，并由可信的提供商按照数据隐私法规进行。例如，在美国，健康保险流通与责任法案（HIPAA）对保护患者的健康信息设定了严格的标准。任何对这些数据的处理都必须符合HIPAA的安全和保密要求。

2.1 开发数据集

在项目的开始阶段，重要的是要识别并聘请主题专家（SME），他们可以帮助生成示例输入数据并定义成功的标准。在Nuna，我们的SME是咨询医疗专业人士，如医生和营养师。根据问题背景，我们发现医疗专家的意见可以几乎统一——答案可以从他们的培训核心原则中找到——或者相当多样化，基于他们的个人经验。为了缓解这种情况，我们发现从项目一开始就聘请一个小专家组（通常为2-5人）并以他们的共识观点作为我们的最终真相来源是有用的。

建议与SME合作，构建系统的代表性输入数据集。为此，我们应该考虑可能使用它的广泛用户角色和主要功能。用例越广泛，这些角色就越多。例如，Nuna聊天机器人对所有用户开放，帮助回答任何基于健康的提问，并且还可以通过工具调用访问用户的个人数据。因此，一些功能是“情感支持”、“高血压支持”、“营养建议”、“应用支持”，我们可能会进一步将其分为“新用户”与“退出用户”或“怀疑用户”与“高级用户”角色。这种细分在数据生成过程和错误分析中非常有用，这些输入在系统中运行后进行。

还需要考虑系统必须处理的具体场景——无论是典型的还是边缘情况。对于我们的聊天机器人，这些包括“用户根据症状询问诊断”（在这种情况下，我们总是将他们推荐给医疗专业人员）、“用户询问被截断或不完整”、“用户尝试破解系统”。当然，不太可能考虑到所有关键场景，这就是为什么后续迭代（第2.5节）和生产中的监控（第3.0节）是必要的。

有了这些分类，数据本身可以通过过滤现有的专有或开源数据集（例如，Nutrition5k用于食品图像，OpenAI的HealthBench用于患者-临床医生对话）生成。在某些情况下，输入和黄金标准输出都可能可用，例如Nutition5k中每张图像上的成分标签。这使得指标设计（第2.3节）更容易。更常见的是，黄金标准输出需要专家标注。事实上，即使没有预先存在的输入示例，也可以通过LLM生成合成数据，然后由团队进行整理——Databricks有一些工具，描述在这里。

这个开发集应该有多大？我们拥有的例子越多，就越可能代表模型在生产中看到的内容，但迭代成本也会更高。我们的开发集通常从几百个例子开始。对于聊天机器人，为了具有代表性，输入可能需要是包含上下文样本患者数据的多步骤对话，我们建议使用像AWS Agent Evaluation这样的测试框架，输入示例文件可以通过手动或通过LLM提示和整理生成。

2.2 基线模型管道

如果从头开始，思考用例和构建开发集的过程可能会让团队对这个问题的难度有所了解，从而构建基线系统的架构。除非因安全或成本问题而无法实现，否则建议保持初始架构简单，并使用强大的基于API的模型进行基线迭代。后续部分中描述的迭代过程的主要目的是改进这个基线版本中的提示，因此我们通常保持简单，同时尝试遵循一般提示工程的最佳实践，如这篇指南中描述的那样。

一旦基线系统启动并运行，就应该在开发集上运行以生成第一个输出。运行开发数据集是一个批处理过程，可能需要多次重复，因此值得并行化。在Nuna，我们使用Databricks上的PySpark来实现这一点。这种类型批处理并行的最简单方法是pandas用户定义函数（UDF），它允许我们在Pandas数据帧的行上循环调用模型API，然后使用Pyspark将输入数据集分成块，通过集群的节点并行处理。另一种方法，描述在这里，首先需要将调用模型的脚本记录为mlflow PythonModel对象，将其加载为pandas UDF，然后使用该对象进行推理。

图2：高层次工作流程，显示构建开发数据集和指标的过程，并获得主题专家（SME）的输入。数据集的构建是迭代的。运行基线模型后，SME的批评可用于定义优化和满意指标及其相关的成功阈值。图片由作者生成。

2.3 指标设计

设计可操作且与功能目标一致的评估指标是评估驱动型开发的关键部分。根据您正在开发的功能的上下文，可能存在一些最低要求的指标，例如在图表上文本摘要的最低数值准确率。特别是在医疗保健领域，我们发现SME在识别对利益相关者认可和最终用户解释重要的补充指标方面再次是必不可少的资源。SME应该能够安全地审查开发集的输入和输出，并对它们进行评论。各种专用工具支持这种审查，并可以根据项目的敏感性和成熟度进行调整。对于早期阶段或低流量的工作，轻量级方法如安全电子表格可能就足够了。如果可能，反馈应包括对每对输入/输出的简单通过/失败决定，以及解释该决定的LLM生成输出的批评。这样做的目的是我们可以利用这些批评来指导评估指标的选择，并为任何我们构建的LLM法官提供少量示例。为什么选择通过/失败而不是利克特评分或其他数值指标？这是开发人员的选择，但我们发现让SME和LLM法官在二进制情况下达成一致更容易。将结果汇总成开发集的简单准确度测量也很直接。例如，如果30%的“90天血压时间序列摘要”得到0分的根基性评分，而30天摘要中没有一个得到0分，那么这表明模型在处理长输入时存在困难。

在初步审查阶段，通常还需要记录一套明确的成功标准，以便所有注释者都有一个真相来源。SME注释者之间的分歧通常可以通过参考这些指导方针来解决，如果分歧持续存在，这可能表明指导方针——以及因此AI系统的目的——没有明确界定。同样重要的是要注意，根据您公司的资源、发布时间表和功能的风险水平，可能无法在这里获得SME对整个开发集的评论——因此选择代表性示例非常重要。

作为一个具体的例子，Nuna开发了一个药物记录历史AI摘要，将在护理团队面向的门户中显示。在该AI摘要开发的早期，我们整理了一组代表性患者记录，将它们通过摘要模型运行，绘制了数据，并与我们的SME共享了一个包含输入图表和输出摘要的安全电子表格以供评论。通过这项练习，我们识别并记录了需要一系列指标，包括可读性、风格（即客观且不耸人听闻）、格式和根基性（即输入时间序列中洞察的准确性）。

一些指标可以通过对输出的简单测试来计算。这包括格式和长度限制，以及通过像F-K年级水平这样的评分量化的可读性。其他指标需要LLM法官（见下文详细说明），因为成功的定义更为微妙。这是提示LLM像人类专家一样行动，给出通过/失败的决定和输出的批评。想法是，如果我们可以将LLM法官的结果与专家的结果对齐，我们就可以在开发集上自动运行它，并在迭代时快速计算我们的指标。

我们发现为每个项目选择一个“优化指标”很有用，例如在输入数据中准确根基的开发集比例，但也要用几个“满意指标”来支持它，例如符合长度限制的百分比、具有合适风格的百分比、可读性评分>60等。延迟百分位数和每请求的平均代币成本等因素也使理想的满意指标。如果更新使优化指标值上升而不将任何满意指标值降至预定义阈值以下，那么我们知道我们正在朝着正确的方向前进。

2.4 构建LLM法官

LLM法官开发的目的是将SME的建议提炼成一个提示，使LLM能够以与他们的专业判断一致的方式对开发集进行评分。法官通常是比被评判的模型更大/更强大的模型，尽管这不是严格的要求。我们发现，虽然可以让一个LLM法官提示输出几个指标的评分和批评，但这可能会令人困惑且与2.4节中描述的跟踪工具不兼容。因此，我们为每个指标制作一个法官提示，这还有一个好处是强制对LLM生成的指标数量保持保守。

初始法官提示，用于在开发集上运行，可能看起来像下面的块。在对齐步骤中将迭代这些指令，因此在这个阶段，它们应代表对SME编写批评时思维过程的最佳努力。确保LLM提供其推理，并且这个推理足够详细，以理解为什么它做出这样的决定。我们还应该检查推理与通过/失败判断是否逻辑一致。关于这种情况下LLM推理的更多细节，我们推荐这篇优秀文章。

<task> 您是一位专家医疗保健专业人员，被要求评估一个自动化系统生成的患者医疗数据摘要。请遵循以下评估摘要的说明 {详细说明} 现在仔细研究以下输入数据和输出响应，给出您的推理和通过/失败的判断，格式如下 task> <input data> {需要摘要的数据} input data> <output_format> {格式说明} output_format>

为了保持法官输出尽可能可靠，其温度设置应尽可能低。为了验证法官，SME需要查看输入、输出、法官决定和法官批评的代表性示例。这应该最好是与他们在指标设计中查看的示例不同的集合，鉴于这一步骤涉及的人工努力，可以是小规模的。

SME可能首先在不看到法官版本的情况下对每个示例进行自己的通过/失败评估。然后他们应该能够看到所有内容，并有机会修改模型的批评，使其更符合他们自己的想法。结果可以用来修改LLM法官提示，并重复这个过程，直到SME评估和模型评估之间的对齐不再改进，时间允许。对齐可以通过简单的准确度或统计测量如Cohen's kappa来衡量。我们发现，在法官提示中包含相关的小样本示例通常有助于对齐，还有研究表明，为每个示例添加评分注释也是有益的。

我们通常使用电子表格进行这种类型的迭代，但也存在更复杂的工具，如Databrick的审查应用，也可以用于LLM法官提示开发。在专家时间短缺的情况下，LLM法官在医疗AI中非常重要，随着基础模型变得越来越复杂，它们替代人类专家的能力似乎在提高。例如，OpenAI的HealthBench工作发现，医生通常无法改进2025年4月模型生成的响应，并且当GPT4.1用于医疗相关问题的评分时，其评分与人类专家的评分非常一致。

图3：高层次工作流程显示如何使用开发集（第2.1节）来构建和对齐LLM法官。实验跟踪用于进化循环，包括计算指标、改进模型、重新生成输出和重新运行法官。图片由作者生成。

2.5 迭代和跟踪

有了我们的LLM法官，我们终于处于一个良好的位置，可以开始对我们主系统进行迭代。为此，我们将系统地更新提示，重新生成开发集输出，运行法官，计算指标，并在新旧结果之间进行比较。这是一个可能有多个循环的迭代过程，因此需要追踪、提示日志记录和实验跟踪。重新生成开发集输出的过程在第2.1节中描述，像MLflow这样的工具也可以跟踪和版本法官迭代。我们使用Databricks Mosaic AI Agent Evaluation，它提供了一个添加自定义法官（包括LLM和程序化法官）的框架，以及几个带有预定义提示的内置法官（我们通常关闭这些）。在代码中，核心评估命令如下所示：

with mlflow.start_run( run_name=run_name, log_system_metrics=True, description=run_description, ) as run: # run the programmatic tests results_programmatic = mlflow.evaluate( predictions="response", data=df, # df contains the inputs, outputs and any relevant context, as a pandas dataframe model_type="text", extra_metrics=programmatic_metrics, # list of custom mlflow metrics, each with a function describing how the metric is calculated ) # run the llm judge with the additional metrics we configured # note that here we also include a dataframe of few-shot examples to # help guide the LLM judge. results_llm = mlflow.evaluate( data=df, model_type="databricks-agent", extra_metrics=agent_metrics, # agent metrics is a list of custom mlflow metrics, each with its own prompt evaluator_config={ "databricks-agent": { "metrics": ["safety"], # only keep the âsafetyâ default judge "examples_df": pd.DataFrame(agent_eval_examples), } }, ) # Also log the prompts (judge and main model) and any other useful artifacts such as plots the results along with the run

在幕后，MLflow会发出对法官模型的并行调用（在上面代码中的代理指标列表中打包），并调用程序化指标的相关函数（在程序化指标列表中），保存结果和相关工件到Unity Catalog，并提供一个不错的用户界面，用于比较实验间的指标、查看跟踪和阅读LLM法官的批评。需要注意的是，MLflow 3.0是在本文撰写后不久发布的，有一些工具可能简化上面的代码。

为了识别ROI最高的改进，我们可以重新审视第2.1节中描述的开发集细分，按角色、功能和情况。我们可以比较各细分之间的优化指标值，并选择关注得分最低的细分，或最令人担忧的边缘案例。有了我们的评估循环，我们可以捕捉模型更新的任何意外后果。此外，通过跟踪，我们可以在需要时重现结果并恢复到以前的提示版本。

2.6 何时准备就绪进入生产环境？

在AI应用中，尤其是在医疗保健领域，一些失败比其他失败更具后果性。例如，我们永远不希望我们的聊天机器人声称自己是医疗专业人员。但是，我们的餐食扫描仪在识别上传图片中的成分时犯错误是不可避免的——人类并不特别擅长从照片中识别成分，因此即使是人类水平的准确性也可能包含频繁的错误。因此，与SME和产品利益相关者合作，制定现实的优化指标阈值非常重要，在这些阈值之上，开发工作可以宣布成功，以便迁移到生产环境。一些项目可能在这个阶段失败，因为不可能在不损害满意指标或资源限制的情况下将优化指标推高到商定的阈值之上。

如果阈值非常高，那么由于LLM法官的不可避免的错误或模糊性，略微错过可能是可以接受的。例如，我们最初设定的发布要求是100%的开发集健康记录摘要被评定为“准确根基”。然后我们发现，LLM法官偶尔会对诸如“患者在过去一周的大多数日子里记录了血压”这样的陈述提出异议，而实际记录的天数是4天。在我们的判断中，一个合理的最终用户不会觉得这个陈述令人困扰，尽管LLM作为法官将其分类为失败。彻底的手动审查失败案例对于确定性能是否实际可接受和/或是否需要进一步迭代非常重要。

这些决定与NIST AI风险管理框架一致，该框架鼓励情境驱动的风险阈值，并强调在整个AI生命周期中可追溯性、有效性和利益相关者对齐的治理。

即使温度为零，LLM法官也不是确定性的。一个可靠的法官应该在每次对给定示例进行评估时给出相同的判断和大致相同的批评。如果这没有发生，表明法官提示需要改进。我们发现这个问题在使用AWS评估框架进行聊天机器人测试时特别成问题，其中每个要评分的对话都有一个自定义评分标准，生成输入对话的LLM在“用户消息”的确切措辞上有一定的自由度。因此，我们编写了一个简单的脚本，多次运行每个测试并记录平均失败率。失败率不在0或100%的测试可以标记为不可靠，并更新直到它们变得一致。这一经验突显了LLM法官和更广泛的自动化评估的局限性。它强调了在宣布系统准备好生产之前纳入人工审查和反馈的重要性。清楚地记录性能阈值、测试结果和审查决定支持透明度、问责制和知情部署。

除了性能阈值外，评估系统是否符合已知的安全漏洞也很重要。OWASP Top 10 for LLM Applications概述了常见的风险，如提示注入、不安全的输出处理以及在高风险决策中过度依赖LLM，这些对医疗保健用例都非常相关。按照这一指导评估系统可以帮助在产品进入生产阶段时减轻下游风险。

3.0 部署后：监控和分类

将LLM应用程序从开发阶段扩展到生产部署是一个复杂的过程，需要可扩展、可持续和可重复的方式，这也是优秀的“LLMOps”文章如这篇文章的主题。拥有这样的过程，可以操作数据管道的每个阶段，对于评估驱动型开发非常有用，因为它允许快速部署新迭代。然而，在本节中，我们将主要关注如何实际使用LLM应用程序在生产环境中生成的日志来了解其性能并指导进一步开发。

监控的一个主要目标是验证在开发阶段定义的评估指标在生产数据中的表现是否相似，这本质上是对开发数据集代表性的测试。这首先应该在内部进行，比如在“狗食测试”或“bug bashing”练习中，由无关团队和SME参与。我们可以在这里重用在开发中构建的指标定义和LLM法官，定期在生产数据样本上运行，并保持结果的分解。在Nuna，出于数据安全的考虑，所有这些都在Databricks中完成，这使我们能够利用Unity Catalog进行谱系跟踪和仪表板工具进行可视化。

对LLM驱动产品的监控是一个广泛的话题，我们的重点是它如何用于完成评估驱动型开发的闭环，从而使模型能够改进并调整漂移。监控还应用于跟踪更广泛的“产品成功”指标，如用户反馈、用户参与度、代币使用率和聊天机器人问题解决率。这篇优秀文章包含了更多细节，LLM法官也可以在这种能力下部署——它们将经历第2.4节中描述的相同开发过程。

这种方法与NIST AI风险管理框架（“AI RMF”）一致，该框架强调连续监控、测量和文档记录，以随着时间的推移管理AI风险。在生产环境中，歧义和边缘案例更为常见，仅靠自动化评估通常是不够的。结合结构化的人类反馈、领域专业知识和透明的决策对于构建可信系统至关重要，尤其是在医疗保健等高风险领域。这些实践支持AI RMF的核心原则：可治理性、有效性、可靠性和透明度。

图4：高层次工作流程显示了部署后数据管道的组件，允许在生产中监控、警报、标签和评估模型输出。这对于评估驱动型开发至关重要，因为见解可以反馈到开发阶段。图片由作者生成。

3.1 额外的LLM分类

LLM法官的概念可以扩展到部署后的分类，为模型输出分配标签，并提供关于应用程序在“野外”使用情况的见解，突出意外互动并警告令人担忧的行为。标签是为数据分配简单标签，以便更容易分割和分析。这对聊天机器人应用程序特别有用：例如，如果某个Nuna应用程序版本的用户开始向我们的聊天机器人询问有关我们的血压袖带的问题，这可能指向袖带设置问题。同样，如果某些类型的药物容器导致我们的药物扫描工具失败率高于平均水平，这表明需要调查并可能更新该工具。

在实践中，LLM分类本身就是一个如第2节所述的开发项目。我们需要构建一个标签分类法（即每个可能分配的标签的描述）和使用它的指令提示，然后我们需要使用开发集来验证标签准确性。标签通常涉及生成一致格式的输出，以便下游流程使用——例如每个聊天机器人对话段的标签ID列表——这就是为什么在此处对LLM调用强制执行结构化输出非常有用的原因，Databricks有一个如何大规模完成此任务的示例。

对于长聊天机器人对话记录，LLM分类可以适应摘要以提高可读性和保护隐私。然后可以将对话摘要向量化、聚类和可视化，以了解从数据中自然出现的组。这通常是设计主题分类分类法的第一步，如Nuna用来标记我们的聊天记录的分类法。Anthropic还为此类目的构建了一个内部工具，揭示了Claude使用模式的迷人见解，并在他们的Clio研究文章中进行了概述。

根据信息的紧迫性，标签可以在实时或批处理过程中进行。寻找令人担忧的行为的标签——例如，如果聊天描述暴力、非法活动或严重健康问题，则立即标记聊天进行审查——可能最适合实时系统，在聊天标记后立即发送通知。而更一般的摘要和分类可能可以作为批处理过程进行，更新仪表板，可能只在部分数据上进行以降低成本。对于聊天分类，我们发现为LLM提供一个“其他”标签来标记那些不符合分类法的示例非常有用。标记为“其他”的数据可以进一步详细检查，以添加新主题到分类法中。

3.2 更新开发集

监控和标签提供了应用程序性能的可见性，但它们也是驱动评估驱动型开发的反馈循环的一部分。当新的或意外的示例进来并被标记时，它们可以添加到开发数据集中，由SME审查并通过LLM法官运行。可能需要调整法官提示或少量示例以适应这些新信息，但第2.4节中概述的跟踪步骤应允许在没有混淆或意外覆盖的风险下取得进展。这完成了评估驱动型开发的反馈循环，使我们不仅在产品发布时，而且在产品随时间演变时都能对LLM产品充满信心。