LLM-FACETS：一种用于评估LLM透明度与问责制的隐私保护框架

# LLM-FACETS：用于评估LLM透明度和问责制的隐私保护框架 来源：https://arxiv.org/html/2605.31167 (2026) ###### 摘要 评估大语言模型的输出是否具有事实依据、认识论校准和方法论可重复性，是负责任部署AI的前提。然而，对非技术从业者而言，审计LLM的实践仍然难以入手：现有工具需要编程专业知识、非平凡的环境配置，且缺乏系统性方法论来支持多维度评估；与此同时，云端托管平台会将评估数据传输至外部服务，为在法律和伦理上承担AI监管责任的领域专家和合规官员带来了障碍。我们提出 LLM-FACETS（LLM事实性交叉评估系统）：一个开源评估框架，配套提供浏览器可访问的界面和插件架构，旨在帮助从业者对LLM质量做出明智、透明的决策。该框架围绕三种从业者画像（技术专家、领域专家和合规官员）构建评估结构，其灵感来源于《欧盟AI法案》和NIST AI风险管理框架中确定的、负责AI系统人类监督的利益相关者类别。该工具架构使数据流明确可见：确定性指标（BLEU、ROUGE、BERTScore）完全在自托管服务器进程中运行，无出站数据传输；LLM判定指标明确调用外部API，用户完全掌控凭据，并负责适用的数据保护协议。该框架通过三种审计机制实现透明化：用于认知不确定性（模型置信度）评估的令牌级对数概率可视化、用于减轻判定偏见的多元判定共识评估，以及用于检测和定位幻觉的RAG三元组指标（忠实度、答案相关性、上下文相关性）。插件架构允许在不修改评估流水线的情况下集成任何新指标或数据集。开源实现支持对同一属性使用多个指标进行交叉检查，确保开放科学原则所要求的可重复性，并将AI问责制与构建被评估系统的团队解耦。我们通过18个指标实现与规范参考库的交叉验证来验证该框架。 LLM评估, AI透明度, LLM即判定器, 检索增强生成, 数据流透明度, 负责任AI, 幻觉检测, 开源, 评估框架, 可重复评估, 开放科学, 面向从业者的透明度, 插件架构 ††copyright:cc ††journalyear:2026 ††doi:XXXXXXX.XXXXXXX ††journal:JRC ††journalvolume:0 ††journalnumber:0 ††article:0 ††publicationmonth:0 ††ccs:计算方法 机器学习 ††ccs:社会与专业主题 问责制 ††ccs:计算方法 自然语言处理 ††ccs:软件及其工程 软件创建与管理 ††ccs:一般与参考 开源软件 ## 1. 引言 审计大语言模型（LLM）——评估其输出是否具有事实依据、认识论校准和方法论可重复性——已成为在高风险领域（从临床决策支持到法律文档分析）负责任部署的前提条件(European Parliament and Council of the European Union, 2024 (https://arxiv.org/html/2605.31167#bib.bib15))。然而，这一实践对最需要它的从业者来说仍然遥不可及。所需工具需要编程专业知识、非平凡的环境配置以及向外部API传输数据。结果，最应负责的参与者（例如领域专家和合规官员）常常被排除在他们依法和伦理上必须执行的评估流程之外。 监管框架使这一差距难以忽视。《欧盟人工智能法案》（AI Act）(European Parliament and Council of the European Union, 2024 (https://arxiv.org/html/2605.31167#bib.bib15))要求高风险AI系统的人类监督者能够解释模型输出并证明合规性，这实际上是对评估接口的功能性要求，即应对非工程师人员也可访问。《通用数据保护条例》（GDPR）(European Parliament and Council of the European Union, 2016 (https://arxiv.org/html/2605.31167#bib.bib16))要求，当个人数据传输给第三方处理者时，必须签订正式的数据处理协议，这对应用于敏感数据集的云端评估平台提出了合规问题。 现有的评估生态系统加剧了这种碎片化。程序化评估库如 DeepEval(Confident AI, 2024 (https://arxiv.org/html/2605.31167#bib.bib19)) 和 Ragas(Eset al., 2024 (https://arxiv.org/html/2605.31167#bib.bib6)) 提供强大的评估能力，但需要编程专业知识、依赖管理和脚本编写——障碍1：编程障碍；障碍2：环境配置。这两个障碍共同导致非技术从业者被系统性地排除在评估工作流之外。在托管服务方面，诸如 Arize Phoenix(Arize AI, 2024 (https://arxiv.org/html/2605.31167#bib.bib30)) 和 Langfuse(Langfuse, 2024 (https://arxiv.org/html/2605.31167#bib.bib31)) 等平台专注于监控已部署的LLM应用在生产环境中的运行，而不是协作性指标探索。学术可视化分析工具(Kahnget al., 2024 (https://arxiv.org/html/2605.31167#bib.bib14)) 提供了复杂的可视化，但仍是孤立的原型。这些解决方案均未解决数据主权问题：通过第三方API评估敏感数据集（医疗记录、法律文档、专有语料库）会与数据保护法规产生不可调和的冲突——缺乏数据主权保障。 本文提出 LLM-FACETS，一个直接解决这些障碍的开源评估框架。该框架围绕三种从业者画像（技术专家、领域专家和合规官员）构建。这呼应了《欧盟AI法案》第14条(European Parliament and Council of the European Union, 2024 (https://arxiv.org/html/2605.31167#bib.bib15)) 和NIST AI风险管理框架(National Institute of Standards and Technology, 2023 (https://arxiv.org/html/2605.31167#bib.bib17)) 中确定为负责AI系统人类监督的功能角色。该框架做出三项主要贡献： 1. (1) 一个将透明度目标与具体评估实践联系起来的**方法论框架**，围绕上述从业者画像构建。每种画像具有不同的透明度需求、问责角色和推荐的指标配置。 2. (2) 一套**统一的透明度审计机制**，涵盖认知不确定性（对数概率可视化）、事实依据（RAG三元组）和流程公平性（多元判定共识），通过无需编程专业知识的浏览器可访问界面提供。 3. (3) 一个**开源工具**，通过18个TypeScript指标变体实现该框架，并已与规范的Python参考实现进行交叉验证，配备插件架构，添加新指标或数据集可自动传播到导航、基准测试仪表板和REST API，无需额外配置11Source code: https://github.com/Scriptor-Group/AIMVi.——实现独立于专有工具的可重复且可审计的评估（第6.1节 (https://arxiv.org/html/2605.31167#S6.SS1)）。 本文其余部分结构如下。第2节 (https://arxiv.org/html/2605.31167#S2) 识别LLM评估固有的挑战，包括跨多个维度的透明度需求。第3节 (https://arxiv.org/html/2605.31167#S3) 定义三种从业者画像，正式化框架，并呈现评估工作流。第4节 (https://arxiv.org/html/2605.31167#S4) 描述LLM-FACETS工具架构。第5节 (https://arxiv.org/html/2605.31167#S5) 详述实现的指标如何操作化透明度维度。第6节 (https://arxiv.org/html/2605.31167#S6) 提供交叉验证证据和性能分析。第7节 (https://arxiv.org/html/2605.31167#S7) 通过多方利益相关者的使用案例验证所提出的框架。第8节 (https://arxiv.org/html/2605.31167#S8) 讨论局限性和更广泛的影响。第9节 (https://arxiv.org/html/2605.31167#S9) 总结。 ## 2. 挑战 本节识别出五项推动本工作的挑战：现有评估工具的碎片化格局（§2.1 (https://arxiv.org/html/2605.31167#S2.SS1)）、可访问AI解释界面的设计需求（§2.2 (https://arxiv.org/html/2605.31167#S2.SS2)）、评估实践的法律与监管约束（§2.3 (https://arxiv.org/html/2605.31167#S2.SS3)）、LLM基准测试的可重复性危机（§2.4 (https://arxiv.org/html/2605.31167#S2.SS4)）以及透明度本身的多维度性质（§2.5 (https://arxiv.org/html/2605.31167#S2.SS5)）。这些挑战共同确立了框架必须满足的具体需求。 ### 2.1. C1 — 入门 对LLM的快速采用催生了大量评估工具，每个工具解决评估挑战的一个子集——广义上定义为以可重复、可解释和可扩展的方式系统衡量模型输出质量的问题(Gehrmannet al., 2023 (https://arxiv.org/html/2605.31167#bib.bib18))。存在一些解决事实准确性和针对性评估的框架。例如，Ragas(Eset al., 2024 (https://arxiv.org/html/2605.31167#bib.bib6)) 提供了一个评估检索增强生成（RAG）流水线的程序化框架，通过忠实度、答案相关性和上下文相关性等指标。DeepEval(Confident AI, 2024 (https://arxiv.org/html/2605.31167#bib.bib19)) 将其扩展到包含14多个指标的更广泛套件，包括幻觉检测(Liet al., 2023 (https://arxiv.org/html/2605.31167#bib.bib41))、偏见评估(Zhenget al., 2023 (https://arxiv.org/html/2605.31167#bib.bib7))和毒性评分，每个指标都基于同行评审的评估研究。这两个框架都是程序化的：它们需要Python环境、依赖管理和脚本编写来执行评估。 在托管服务方面，LangSmith(LangChain, Inc., 2023 (https://arxiv.org/html/2605.31167#bib.bib21)) 提供了一个云端可观测性平台，专注于跟踪和监控已部署的LLM应用在生产环境中的运行，提供自定义LLM即判定器模板，而非标准化指标套件。TruLens(TruEra, Inc., 2024 (https://arxiv.org/html/2605.31167#bib.bib20)) 提供评估RAG应用的反馈函数，并附带可视化仪表板。Arize Phoenix和Langfuse处于类似领域，专注于生产监控和跟踪分析。 这些工具共享两个结构限制。首先，它们呈现**技术障碍**：所有工具都需要编程专业知识和开发环境配置，使得领域专家和合规官员难以参与。其次，像LangSmith这样的云端平台将评估数据（可能包含敏感文档）传输到外部服务器，引发数据主权问题。即使是名义上开源、依赖于基于云的LLM判定器调用的工具，也会将待评估文本传输给第三方提供商。这种双重限制——技术复杂性和数据暴露——促使设计一个既可通过浏览器访问又明确说明数据流向的工具。 另一种方法是ARES(Saad-Falconet al., 2024 (https://arxiv.org/html/2605.31167#bib.bib34))，它专门为RAG评估任务训练轻量级判别判定器（DeBERTa变体）。通过在领域相关数据上微调小模型，ARES减少了对前沿模型API的依赖，同时以较低成本实现了相当的精度——这对于高容量或成本受限的评估而言是一个显著优势。然而，ARES仍然是一个没有可视化界面或数据主权保证的Python研究框架。 学术可视化分析工具已开始解决可访问性维度。LLM Comparator(Kahnget al., 2024 (https://arxiv.org/html/2605.31167#bib.bib14)) 提供LLM输出的并排可视化评估，用于定性比较。然而，此类工具仍然是孤立的原型，未将定量指标、隐私保证或多从业者工作流整合到一个统一的评估框架中。缺乏这样的统一工具对机构来说是一个重大的入门和可访问性障碍。 ### 2.2. C2 — 可访问性 越来越多的人机交互研究表明，AI解释界面的设计从根本上决定了从业者是否能有效行使监督权。Liao 等人(Liaoet al., 2020 (https://arxiv.org/html/2605.31167#bib.bib22)) 确定AI解释工具必须围绕从业者实际提出的问题来设计——而不是围绕工程师觉得方便生成的技术产物。他们的问题驱动设计框架揭示了一种持续存在的错位：大多数解释工具回答“模型如何工作？”，而用户需要知道“我能信任这个特定输出吗？”。Ehsan 等人(Ehsanet al., 2021 (https://arxiv.org/html/2605.31167#bib.bib23)) 将这一见解扩展到**社会透明度**的概念：使AI决策背后的推理过程和社会背景对非技术从业者可理解。他们的工作表明，透明度并非通过暴露模型内部结构实现，而是通过以能够促进不同参与者有意义参与的形式呈现评估过程。 对于LLM评估工具而言，其影响是具体的：将结果以原始数值分数的形式呈现于终端输出或Jupyter笔记本中，未能达到该研究领域认为对于真正人类监督至关重要的可访问性标准(Liaoet al., 2020 (https://arxiv.org/html/2605.31167#bib.bib22); Ehsanet al., 2021 (https://arxiv.org/html/2605.31167#bib.bib23))。因此，旨在支持多方从业者审计的评估框架必须将分数转换为交互式表示，并围绕非技术审计员实际提出的问题来构建：“这个输出有事实依据吗？”、“我能相信这个具体主张吗？”、“评估方法本身是否可靠？”(Liaoet al., 2020 (https://arxiv.org/html/2605.31167#bib.bib22))。 生产能够赋能领域专家而不牺牲技术深度的工具是一个关键挑战。 ### 2.3. C3 — 合规 全球监管环境日益要求现有工具无法提供的评估能力。虽然这些要求在不同司法管辖区（如拟议的美国算法问责法案）形式各异，但欧洲法律框架提供了这些义务的明确且广泛适用的示例。《欧盟AI法案》(European Parliament and Council of the European Union, 2024 (https://arxiv.org/html/2605.31167#bib.bib15)) 对高风险AI系统的提供者和部署者施加了多项与评估相关的义务。第9条和第11条要求持续的风险