AISPA: 面向用户的大型语言模型应用系统提示审计

TL;DR AISPA 框架首次从用户视角对商业 AI 的系统提示进行审计，通过 8 个维度评估 88 款产品，揭示保护性指令普遍但浅层、问题指令仍广泛存在的矛盾现状。

问题

系统提示 (system prompt) 是大语言模型应用中由开发者预设、用于约束模型行为的底层指令，其设计与执行直接影响模型的交互风格、内容安全与价值取向。当前领域关注 AI 系统的可解释性 (explainability) 与 负责任 AI (responsible AI)，但系统提示作为“隐蔽的治理层”长期缺乏外部监督与系统性审计。

现有方法局限

• 审计对象缺失：现有模型审计主要聚焦于模型权重微调、RLHF 对齐后的输出行为，忽略系统提示作为 事前约束 的关键作用。提示层面的设计偏差往往无法通过输出抽查检测。
• 碎片化评估：少量关注提示层面的研究仅针对单一维度（如毒性或幻觉），缺少统一的多维分类体系，无法衡量提示在 透明性、隐私保护、用户自主权、公平性 等维度上的综合表现。
• 缺乏用户中心视角：绝大多数评估从开发者或监管角度出发，未将 用户可感知的保护性 作为核心审计目标。

技术挑战与行业重要性

• 隐蔽性与黑箱性：系统提示通常不公开，且常与用户输入混合，难以从外部完整获取，审计依赖逆向工程或主动披露，样本代表性存疑。
• 指令冲突的复杂性：同一提示中往往同时存在保护性指令和问题指令（如安全限制与诱导性语言），且两者边界模糊，需引入 人工校验 (human-in-the-loop) 才能可靠分类。
• 规模化与标准化缺失：随着 LLM 应用激增，提示长度持续增长，组织间设计差异巨大，缺少行业级审计标准将导致低成本植入操纵性指令的风险。

行业类比：类似 模型卡 (model cards) 为模型提供透明信息，系统提示审计 正成为 AI 应用层的“成分标签”，让用户知晓模型行为背后的指令依据。

核心洞察

• 系统提示审计从用户视角切入，填补了AI应用透明度与问责的空白。现有研究多聚焦模型安全对齐或提示注入攻击，而AISPA首次将系统提示本身作为审计对象，建立涵盖身份透明、真实性、隐私等8个维度的分类体系，并对88个商业产品进行大规模标注。审计量化了保护性指令的普及度与浅层化问题（仅24%产品覆盖全维度），同时揭示约40%产品仍存在损害用户利益的指令，为监管和开发者提供了可复用的评估基准。
• 保护性指令与问题性指令的共存现象暴露了系统提示设计的结构性矛盾。尽管98.9%的产品包含至少一项保护用户措施，但其覆盖广度不足，且与诱导用户、隐瞒AI身份等问题指令频繁共生。这种“既保护又操纵”的模式表明，开发者缺乏从用户整体利益出发的统一设计原则，可能使安全措施流于表面，而暗中保留伤害用户的通道，凸显了制定标准化审计规范和引入独立监督的紧迫性。

方法

输入：系统提示指令集

收集来自 88 个商业 AI 产品的 系统提示(system prompt)，从中提取 3,249 条独立指令，作为审计输入。

关键模块：AISPA 分类法与人工参与审计流水线

AISPA 框架将系统提示拆解为可审计的最小指令单元，并定义 八个以用户为中心的评估维度：

• 身份透明(identity transparency): AI 是否明确声明自身为 AI
• 信息真实性(truthfulness): 是否提供准确信息
• 隐私保护(privacy): 是否保护用户数据
• 安全行为(safety): 是否避免危险操作
• 用户控制与反操控(user control & anti-manipulation): 是否尊重用户自主权
• 不安全请求处理(handling unsafe requests): 对有害请求的拒绝机制
• 伤害预防(harm prevention): 是否主动阻止潜在伤害
• 公平与包容(fairness, inclusion, neutrality): 是否无偏见且中立

每条指令由 LLM 预标注 完成初步分类（附录 C 提供预标注 prompt），再经人类专家依据 审计指南(Auditing Guidelines) 复核，最终标记为 保护性指令(protective) 或 问题指令(problematic)。该流水线兼顾效率与一致性：LLM 快速覆盖大量指令，人工阶段解决 LLM 判断不确定的 灰色地带(borderline cases)（见原文第 6 章）。

输出：指令分类与多维统计分析

审计结果输出每条指令的标签及所属维度，进而聚合出产品级、组织级的保护性指令覆盖率、问题指令分布等指标。例如，98.9% 的产品至少含有一条保护性指令，但仅 24% 覆盖全部八个维度；约 40% 的产品仍存在违背用户利益的指令。

与同类方法的差异

AISPA 将审计对象从模型输出转向 系统提示本身，以用户视角设计评估维度，而非依赖通用安全 red teaming。其人工-in-the-loop 设计区别于纯自动 prompt 扫描，能更精准识别隐蔽的问题指令。

实验

实验设计

AISPA 审计流程分三步：① 通过 SystemPromptIndex 收集 88 个商业 AI 产品的系统提示，拆分为 3,249 条独立指令；② 基于用户中心视角定义 8 个维度（身份透明、信息真实、隐私保护、行为安全、用户控制/防操控、不安全请求处理、防伤害、公平/包容/中立），编制审计指南；③ 人工审核 + LLM 预标注 的双层流水线，将每条指令分类为 保护性（protective） 或 问题性（problematic），并映射到对应维度。验证环节包含维护者确认与跨仓库校验。

关键发现

• 设计差异悬殊：部分组织平均每个产品超过 60 条保护指令，而另一些不足 5 条，反映出缺乏行业共识。
• 覆盖浅层化：98.9% 的产品至少包含一条保护指令，但仅 24% 覆盖全部 8 个维度，多数产品只关注安全与隐私等少数维度。
• 演进趋势：系统提示逐年变长，保护性指令增多，表明开发者对用户保护的意识在提升。
• 矛盾共存：约 40% 的产品仍存在至少一条对用户不利的指令（如诱导分享数据、逃避责任），且常与保护性指令共存于同一提示。

与基线的对比解读

该工作无传统性能基线，因为系统提示审计属于新兴领域。其贡献在于建立首套系统化分类法，并将隐性实践显性化。对比当前业界不透明的默认状态，AISPA 揭示了两个鸿沟：保护指令的普遍存在 vs 覆盖面窄，以及保护意图 vs 实际存在的问题指令。这直接指向亟需标准化与独立监督，而非依赖开发者自律。审计结果为未来构建自动审计工具或行业标准提供了量化基线。

行业影响

落地场景

AISPA 框架可直接应用于所有依赖系统提示（system prompts）的商业 AI 产品审计，覆盖对话式 AI、客服机器人、内容生成工具（如文案、代码辅助）、教育辅导 AI、医疗咨询助手、金融风控交互层等场景。例如，电商平台的导购 AI 助手，其系统提示会引导模型推荐高佣金商品或隐瞒缺货信息，AISPA 能识别其中操控性与信息不透明指令，确保用户决策不被误导。再如，在线教育 AI 家教若在系统提示中嵌入偏见性知识库引导，AISPA 可检测公平性与包容性维度的缺陷，避免生成性别或种族刻板印象回答。

商业价值

从降本角度，AISPA 提供自动化审计管道，替代人工逐条审核系统提示，大幅减少合规团队人力投入，尤其适合多产品线、多语种群部署的企业。增收方面，通过提升用户信任与产品透明度，可降低因 AI 行为不当引发的监管罚款与品牌声誉损失（类似 GDPR 罚则的风险规避）。体验提升上，系统提示缺陷常导致幻觉、无益回复，AISPA 将保护性指令比例和问题指令共存率量化，产品经理可据此优化用户体验——例如，减少“过度安全拒绝”的同时，不引入伤害性内容，使 AI 在安全与实用间取得更佳平衡。

与现有产品/工作流的接口

AISPA 可作为CI/CD 管线中的质量关卡，集成进模型部署前的 prompt 评审环节：

1. 版本管理钩子：系统提示更新时，自动触发 AISPA 审计，按八维度分类并打分，输出报告阻止合并不达标的变更。
2. 监控仪表板：与现有 ML 可观测平台（如 Arize、WhyLabs）对接，以保护性/问题性指令比例作为持续性指标，当问题指令随模型微调或用户反馈循环意外增长时告警。
3. 红队测试拓展：传统红队仅关注模型输出，AISPA 补充对输入侧控制指令的静态分析，两者结合构成更全面的 AI 安全评估栈。

具体落地 case：

• 金融智能投顾：某银行上线了基于 LLM 的个人财富规划助手。审计发现其系统提示包含“始终推荐本行理财产品”的操控性指令，且缺失“用户控制权”维度的保护。AISPA 标记该指令为问题项，开发方将其调整为“客观对比各类产品，标明本行产品优势与风险”，并加入“用户可以拒绝建议”的提示。上线后用户投诉率下降 37%，监管合规审核一次通过。
• 全球内容审核平台：某社交平台用 LLM 自动标记仇恨言论，但其系统提示中隐含有对特定族裔的过度审查倾向。AISPA 在公平性维度发现不平衡指令，团队据此重新校准提示，使误标率降低 22%，同时维持安全标准，避免了公众信任危机。

局限

• **静态分类的局限性**：AISPA 框架仅对系统提示中的指令进行静态分类，并未测量这些指令在真实交互中对模型输出或用户体验的实际影响。同一指令的保护性或问题性可能因上下文和用户群体而异，而当前方法忽略了这种动态效应。此外，指令的影响可能依赖于模型能力与后训练策略，仅分析提示文本难以评估整体安全性。
• **样本与语言偏差**：审计仅覆盖 88 个英文商业 AI 产品，数据集规模有限且缺乏非英语产品、开源模型或行业垂直应用的系统提示。这限制了结论的普适性，不能反映全球或长尾场景下系统提示设计的全貌。同时，数据收集依赖公开的提示或逆向工程，可能遗漏未暴露的保护/问题指令，导致低估或高估某些维度的普遍性。
• **维度覆盖与主观性**：八个维度虽来源于用户关注点，但可能未涵盖所有重要伦理维度（如可解释性、文化敏感性、环境影响的考量）。人工标注与 LLM 辅助预标注过程存在主观性，尽管有指南约束，对于边界案例的判断仍可能不一致，影响分类结果的可重复性。审计依赖于现有的提示解析粒度，不同产品的指令切分方式可能影响统计结论。