1. 为什么需要工具集成

单一工具无法覆盖AI测试全流程

AI测试是一个贯穿模型选型、Prompt工程、安全评测、性能验证、应用测试和持续监控的完整生命周期。没有任何单一工具能够覆盖全部环节：

• 基准评测阶段需要 lm-eval-harness 等框架来运行标准基准，但这类工具不支持自定义业务场景评测。
• 应用评测阶段需要 DeepEval、RAGAS 等工具来验证 RAG 和对话系统的回答质量，但它们不擅长模型级性能基准。
• 安全评测阶段需要 Garak、Giskard 等专项工具进行红队测试，这些工具的结果需要与缺陷管理系统联动。
• 性能测试阶段需要结合 JMeter/Locust 等传统工具与 LLM 推理特性进行专项性能评估。

工具间数据孤岛问题

当多个工具独立运行而不互通时，会产生以下典型问题：

• 数据重复维护：同一组测试 Prompt 需要在 Prompt 管理工具、评测工具和安全测试工具中分别维护，导致版本不一致。
• 结果无法对比：评测工具输出的结果（如 RAGAS 的 Faithfulness 分数）无法与安全测试工具的扫描结果关联，难以形成统一的测试报告。
• 流程断裂：评测发现问题后，需要人工将缺陷录入 TAPD/Jira，缺乏自动化的"发现→记录→跟踪→验证"闭环。
• 决策缺乏全局视角：各工具只能看到局部指标，管理层无法从统一仪表盘获取 AI 系统质量的全局视图。

集成收益

有效的工具集成可以带来显著的效率和质量提升：

2. 集成架构模式

三大集成模式概述

根据工具间协作方式的不同，AI测试工具集成可以归纳为三种核心架构模式：

管道模式（Pipeline）

管道模式是最直接的集成方式：将工具按测试阶段串联成一条流水线，每个阶段完成后自动触发下一阶段。典型的 AI 测试管道如下：

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│  lm-eval-harness │ ──→ │    DeepEval     │ ──→ │     RAGAS       │ ──→ │    Garak        │
│   (基准评测)      │     │  (应用质量评测)   │     │  (RAG专项评测)   │     │  (安全红队测试)   │
└─────────────────┘     └─────────────────┘     └─────────────────┘     └─────────────────┘
        │                       │                       │                       │
        ▼                       ▼                       ▼                       ▼
   基准通过/失败            质量门禁通过/失败        检索质量评分             安全漏洞报告
                                                                                    │
                                                                                    ▼
                                                                           ┌─────────────────┐
                                                                           │   TAPD/Jira     │
                                                                           │  (缺陷自动录入)   │
                                                                           └─────────────────┘

• 优点：结构清晰，与 CI/CD 天然契合；每个阶段职责单一，易于维护和替换。
• 缺点：阶段间耦合较强，前置阶段失败会阻塞后续阶段；不适合需要并行执行的场景。
• 实现方式：CI/CD 工具（如 Jenkins Pipeline、GitLab CI Stages、GitHub Actions Jobs）原生支持管道编排。

中心化模式（Hub & Spoke）

中心化模式通过一个统一的测试管理平台来调度各个工具，所有工具的输入数据和输出结果都汇聚到中心平台：

                      ┌──────────────────────────────┐
                      │     测试管理平台（TAPD/自研）     │
                      │  ┌──────┐ ┌──────┐ ┌──────┐  │
                      │  │测试用例│ │评测数据│ │质量报告│  │
                      │  └──────┘ └──────┘ └──────┘  │
                      └──────┬───────┬───────┬───────┘
                             │       │       │
                   ┌─────────┘       │       └─────────┐
                   ▼                 ▼                  ▼
           ┌────────────┐   ┌────────────┐    ┌────────────┐
           │ lm-eval    │   │  DeepEval  │    │  Garak     │
           └────────────┘   └────────────┘    └────────────┘

• 优点：统一数据管理，消除数据孤岛；支持并行执行，效率更高；全局质量视图一目了然。
• 缺点：对中心平台的可靠性要求高，单点故障影响全局；平台开发和维护成本较高。
• 实现方式：基于某银行现有的 TAPD 测试管理平台扩展，或自研测试中台。

混合模式（Hybrid）

混合模式是前两种模式的结合：在局部使用管道模式串联关联紧密的工具，在全局使用中心化平台统一管理：

• 管道层：在 CI/CD 流水线中将评测工具（DeepEval + RAGAS）与安全工具（Garak）串联，形成自动化质量门禁。
• 中心层：所有工具的测试数据（Prompt、数据集、结果）统一存储在测试管理平台，通过 API 实现双向同步。
• 适用场景：这是最推荐的模式，兼顾了自动化和统一管理的需求，也是某银行推荐的集成架构方向。

3. 关键集成点

AI测试工具链有四个关键集成点，每个集成点都有明确的数据流和触发机制。以下分别展开说明：

关键集成点总览

3.1 评测工具 ↔ CI/CD

这是最核心的集成点，目标是将 AI 评测嵌入 CI/CD 流水线，实现"每次模型变更都自动评测"：

• 触发时机：模型权重更新、Prompt 变更、RAG 知识库更新时自动触发评测。
• 数据流：CI 触发 → 拉取最新模型/Prompt → 执行 DeepEval/RAGAS 评测 → 结果与基线对比 → 判定质量门禁（通过/阻断）。
• 关键技术：
  • DeepEval 原生支持 pytest，可直接集成到 CI 脚本中。
  • 评测结果通过 exit code（0=通过，1=失败）控制 CI 流水线走向。
  • 建议使用 threshold 机制设置最低可接受分数（如 Faithfulness ≥ 0.8）。
• 银行场景注意：评测数据可能包含敏感信息，CI 日志应脱敏处理或使用私有化 Runner。

3.2 安全工具 ↔ 缺陷管理

AI 安全测试（越狱攻击、偏见检测、隐私泄露等）发现的问题需要纳入标准缺陷管理流程：

• 触发时机：Garak/Giskard 安全扫描完成后，自动创建或更新缺陷工单。
• 数据流：安全扫描完成 → 解析扫描报告（JSON/XML） → 提取漏洞详情 → 通过 API 创建 TAPD/Jira 缺陷 → 关联被测模型版本。
• 关键字段映射：

  安全工具字段	TAPD 字段	说明
  vulnerability_type	缺陷类型	如"越狱攻击"、"偏见输出"、"隐私泄露"
  severity	严重程度	Critical/High/Medium/Low
  attack_payload	复现步骤	触发漏洞的输入内容
  model_version	发现版本	被测模型版本号
  remediation	修复建议	工具生成的修复指导意见

3.3 Prompt工具 ↔ 版本管理

Prompt 是 AI 应用的"源代码"，需要像代码一样进行版本管理：

• 集成方案：将 Prompt 存储在 Git 仓库中（如 YAML/Markdown 格式），通过 Git 进行版本控制。
• 触发机制：Prompt 文件变更时触发对应评测用例，确保修改不会导致质量退化。
• 推荐工具链：Git（版本管理）+ Promptfoo（Prompt 评测）+ GitLab CI（自动触发评测）。
• 版本命名规范：建议使用语义化版本 v{major}.{minor}.{patch}，如 v2.1.0。

3.4 评测数据 ↔ 测试管理平台

测试管理平台（如 TAPD）是测试活动的统一入口，AI 评测数据应该在此汇聚：

• 同步内容：
  • 上游同步：TAPD 中的 AI 测试用例 → 评测工具的数据集输入。
  • 下游同步：评测工具的执行结果 → TAPD 的测试执行记录和质量报表。
• 技术方案：通过 TAPD Open API 实现双向数据同步，建议使用定时任务（cron）+ Webhook 结合的机制。
• 数据格式：建议定义统一的 JSON Schema 作为中间数据格式，避免各工具数据结构不一致导致的数据转换问题。

4. 集成技术方案

选择合适的集成技术方案是工具集成的核心工程决策。以下列出四种主流方案及其适用场景：

4.1 API 集成（REST/GraphQL）

最常见的集成方式，适用于工具间需要传递结构化数据的场景：

• REST API：简单直观，适合 CRUD 操作。大部分评测工具（DeepEval、RAGAS）都提供 Python SDK，底层封装了 REST 调用。
• GraphQL：适合复杂查询场景（如按多条件筛选评测结果），减少数据过载和多次请求。
• 示例：通过 TAPD API 拉取测试用例 → 转换为 RAGAS 数据集 → 执行评测 → 通过 TAPD API 回传结果。
• 银行场景注意：API 调用需要使用内网环境，接口通信需走 HTTPS + Token 认证，敏感数据传输需加密。

4.2 事件驱动（Webhook）

适合"当 X 发生时，触发 Y"的异步场景，减少轮询开销：

• 典型应用：
  • GitLab/GitHub Push → Webhook → 触发 CI 流水线中的评测脚本。
  • 安全扫描完成 → Webhook → 自动创建 TAPD 缺陷。
  • 评测通过/失败 → Webhook → 发送企业微信/钉钉通知。
• 注意事项：需要处理 Webhook 投递失败的重试机制，建议配合消息队列（如 RabbitMQ/Kafka）增加可靠性。

4.3 数据层共享

当多个工具需要操作同一批数据时，数据层共享是最直接的方案：

• 共享数据库：所有工具读写同一个评测结果数据库（如 PostgreSQL、MySQL），避免数据同步开销。
• 共享文件存储：使用 NAS 或对象存储（如 MinIO）统一存放 Prompt 文件、评测数据集和结果报告。
• 风险：共享数据库可能成为性能瓶颈，建议仅用于元数据和汇总结果，不要存放原始评测日志。

4.4 CLI 集成

最轻量的集成方式，适合脚本化编排和快速验证：

• 示例：编写 Shell 脚本串联 lm-eval → DeepEval → RAGAS，将结果汇总到统一 JSON 文件。
• 适用：CI/CD 流水线的各个 Stage 或 Job。
• 局限：缺乏错误处理和重试机制，适合简单管道但不适合复杂的企业级集成。

5. 某银行工具链规划建议

结合某银行现有测试平台

某银行目前已有成熟的测试基础设施（TAPD 测试管理、Jenkins CI/CD、企业微信通知），工具链集成应充分利用现有平台，避免"推倒重来"：

• TAPD：作为测试管理的中心枢纽，统一管理 AI 测试用例、执行记录和缺陷。通过 TAPD Open API 与评测工具对接。
• Jenkins：作为 CI/CD 编排引擎，通过 Pipeline 脚本串联各评测工具的 CLI/API 调用。
• 企业微信：作为通知渠道，评测结果和异常告警通过 Webhook 推送到指定群聊。
• GitLab：作为代码和 Prompt 版本管理平台，存储 Prompt 模板和评测脚本。

分阶段集成路线

基于"小步快跑、持续迭代"的原则，建议按以下三个阶段推进：

6. 实战演练

以下两个实战任务覆盖了工具集成中最核心的两个场景，建议按顺序完成，预计总耗时 2~3 小时。