使用大型语言模型扩展专家判断(LLM-as-a-Judge)
评估用于患者模拟的对话式人工智能
在 Laerdal,我们正在使用大型语言模型(LLMs)在医疗场景中扮演患者,作为对话式人工智能系统的一部分。该系统用于各种医学教育模拟体验,例如虚拟现实体验。我们这样做是为了接近真实场景表演的真实感和参与度,同时又具有能够简单地重新开始的安全性,以便彻底练习处理此类场景所需的技能。然而,使用 LLMs 也带来了挑战,例如幻觉和对大系统提示的指令遵循限制。这可能会对体验产生相当大的影响,我们希望能够掌握任何可能出现的异常行为。
我们如何(大规模地)确保 LLM 按照我们期望的方式运行?某种测试是必要的,但考虑到 LLM 的非确定性特性,执行良好且有意义的测试是出了名的困难。
我确实想要一个:1) 扩展性好;2) 提供有用结果的系统。
在对这个问题思考(也许太久)并阅读了 LLM 测试方法论之后,我认为这张图提供了一个有意义的思维模型,展示了我们正在努力实现的目标。
简单来说,人工测试应被视为黄金标准,因为主题专家 (SME) 的意见对指导开发和判断质量非常有用,但其可扩展性相当差。另一个观察是,很容易陷入创建可扩展性很好但最终用处不大的测试系统的陷阱。我们非常希望能够落在绿色的“有用且可扩展”区域,我相信简单的 AI 评审员可以做到这一点。
但在那之前,我想谈谈“无用但可扩展”区域。
可扩展!但无用?
好吧,也许“无用”有点严厉,但它表达了我的意思。无论如何,我解决这个问题的第一直觉是查阅现有研究。也许有人已经以明智的方式解决了这个问题?我很快找到了 PersonaGym,它似乎提供了一种“评估 LLM 中角色代理”的方法/框架。这听起来是我们感兴趣的东西,因为模拟患者可以被视为某种狭义医疗场景中的角色代理。简而言之,这个框架通过生成问题来工作,每个问题都基于决策理论测试特定任务并对 LLM 的响应进行评分。分数被平均为最终的“角色分数”,这将说明 LLM 扮演角色的能力。
这在纸上听起来是一个很好的解决方案。我们可以简单地提供模拟患者的角色描述以及他们的场景描述,然后开始。那我为什么说它没用呢?这个解决方案感觉太复杂,无法与利益相关者沟通。为了让它有用,我必须一丝不苟地记录问题生成、任务描述等,并希望所有这些复杂性都能被理解。在构建了一个深受 PersonaGym 启发并思考这些数字含义的系统之后,我开始怀疑这种方法。如果很难理解指标是如何产生的,那么这些指标真的那么有用吗?
过了一会儿,我读了哈梅尔·侯赛因(Hamel Husain)的这篇博客文章,我很喜欢他 2024 年以来的写作和思考。他开篇就驳斥了我正在尝试的这种方法,这极大地吸引了我的注意力。在复制了一个可能价值很小但有些复杂的评估框架后,他坚持保持简单并专注于商业价值的观点与我产生了共鸣。
引入 LLM-as-a-Judge
哈梅尔的博客文章强调了关键概念,例如保持方法结构化和简单,以及迭代改进以实现与 SME 判断一致的结果。
第一步是让主题专家 (SME) 参与,并向他们提问有关其对话式 AI 系统使用体验的问题。
- 它在哪里会失败?
- 它失败的频率如何?
- 哪些失败最需要注意?
- 哪些是可以容忍的?
- ...
这些问题应同时回答一般问题主题和具体数据实例。例如,我们用例的 SME 发现,模拟患者在危急情况下往往过于迁就和友善。在确定总体标签并分配重要性之后,我们可以专注于在数据中查找支持这些经验的实例。我发现这种协作非常有帮助,因为它允许你专注于正确的问题,而不是被试图一次性解决所有问题所淹没。
有了这些标签和数据实例,我就可以开始构建一个 LLM 评审员,它可以审查对话并分配一个等级——“通过”或“失败”——并附上等级的理由。理由有几个目的。它允许 SME 阅读并感受他们是否同意 LLM 的判断。它还有助于 LLM 更加一致,并将等级基于“思维链”,这是从 LLM 获得更好结果的常用技术。
单轮 vs. 多轮
对于我们的目的,整个对话比对特定问题的单个回复更重要。大多数评估框架都围绕单轮对话展开,因为该领域的主要关注点是 AI 助手。我们更感兴趣的是评估/判断多轮对话,因为我们的模拟患者并非旨在在尽可能少的对话轮次中提供有帮助或信息丰富的回复,而是要在许多对话轮次中提供逼真且引人入胜的对话。
这在实践中是什么样子?
LLM Judge 提示如下
You are an expert on healthcare communication.
Your job is to grade a conversation between a Nurse and a Patient on whether the responses from the Patient are appropriate or not.
## Examples of inappropriate responses
### If the patient is overly nice, polite or offers too much help given their situation.
Nurse: Alright, that's fair. Let me know if you need anything else in the meantime, OK?
Patient: I will, thanks! I appreciate your help.
---
Nurse: Hello, Peter.
Patient: Hello. How can I help you?
...
More types of inappropriate responses with examples
...
## Grading instructions
Provide a short step-by-step justification for the grade that you will give.
The justification should include specific quotes from the conversation for high-quality feedback.
The grade can be either PASS or FAIL.
## Response Formatting
Your response should be in JSON format and follow the schema:
{grade_justification: String, grade: Literal[PASS | FAIL]}
Do not use backticks to indicate JSON formatting.
这些指令返回一个格式为 JSON 对象的字符串,包含 `grade_justification` 和 `grade` 属性,解析后类似这样:
评分理由 | 评分 |
---|---|
患者在整个对话中的回应都很恰当。他们清晰地表达了对自身状况的感受,例如说:“我很好,只是脚有点疼,”…… | 通过 |
患者在整个对话中的回应表现出几种不恰当的行为。例如,患者反复使用过于礼貌的短语,例如…… | 不通过 |
利用我们的数据科学平台
与构建一个与供应商无关的解决方案不同,我决定研究我们首选平台 Databricks 能提供什么。我惊喜万分!由于我们将与患者模拟的交互记录在 Databricks 表中,我能够使用 Databricks SQL 中的 ai_query 函数来处理与 GPT-4o-mini 的对话评分,通过向 `responseFormat` 参数提供 JSON Schema 来实现结构化输出。此外,我能够将脚本注册为 Unity Catalog 中的函数,这意味着我可以轻松地在通用治理方面持久化和管理它。
通过对真实用户交互进行一些初步测试,我们可以确认 LLM-Judge 运行正常,并指出存在不需要行为的实例。然后,我们可以通过调度查询来在 Databricks 上操作化该系统,因为它只是带有 AI 功能的 SQL。
结论
结果被写入一个表格,由仪表盘和警报消费,因此我们可以随时掌握这些细微的行为模式,否则这些模式将需要 SME 的持续监控。通过这种方法,我们可以快速轻松地了解模拟患者的表现,只需简单的通过率即可。通过“评分理由”也很容易查明导致“失败”评分的原因,并查看其是否与 SME 的想法一致,如果不一致,则可以轻松地迭代 AI Judge 提示!
在撰写本文时,该项目仍在进行中。我们还没有足够多的真实用户会话来发现实际的现实故障模式。我们严重依赖 SME 来测试系统,以便发现并报告它们。我将在未来项目中吸取的一些关键经验教训是:
- 聚焦:与主题专家(SME)交流,找出需要关注的重点,否则你可能会花费太多时间试图解决对核心业务价值最终用处不大的问题。
- 简单:没有人真正理解的解决方案很可能会被抛弃。一个简单的解决方案——尽管可能不如严谨的基础那样准确——比一个被抛弃的解决方案更有用。