LoomLoom 真实案例：一次 AI 安全 POC 如何自然用到批量生成与批量评测
一句话
这个案例不是为了宣传 LoomLoom 而编出来的 demo。我们在做一个真实的 AI 安全 POC 时，自然遇到了「需要批量生成数据、批量评测效果、批量对比模型回答质量」的问题，于是用 LoomLoom 把原本单条验证的 POC，变成了可规模化、可复查、可沉淀报告的实验流程。
背景：一个端侧脱敏 POC
最近 OpenAI 开源了 OpenAI Privacy Filter。我们判断它可能对胜算云的大模型生态有启发，因此做了一个小型 POC：
能不能在客户侧先完成敏感信息识别和脱敏，让模型 router 和上游模型供应商只看到脱敏后的内容？这个 POC 的核心卖点是：
明文敏感信息不出客户环境。一开始，单条 demo 很容易验证：
输入一段包含姓名、手机号、邮箱的文本。本地脱敏成 PERSON_001、PHONE_001、EMAIL_001。再把脱敏后的内容发给模型。模型返回后，在客户侧恢复。但这只能证明「演示能跑通」，回答不了团队和潜在客户真正关心的问题：
- 多种类型的数据都能处理吗？
- 清洗后真的没有泄漏吗？
- 脱敏后模型回答质量会不会明显下降？
- 单次回答结果是不是偶然？
- 后续换模型、换规则、换场景，能不能快速复测？
这时 LoomLoom 的价值就自然出现了。
LoomLoom 在这个案例里做了什么
第一个问题：测试数据不够
POC 一开始只有几条手工样本，可以证明流程能跑通，但不能证明覆盖面。靠人工写测试样本，很快会卡在规模上：
写 10 条还可以。写 100 条就开始重复。写 300 条基本不可维护。于是我们把「生成测试数据」设计成一个 LoomLoom 工作流：先定义需要覆盖的样本类型，再让 LoomLoom 批量生成 synthetic 测试样本。
| 类型 | 用途 |
|---|---|
| 中文手机号 + 密码 | 验证混合敏感信息 |
| 中文姓名 + 手机号 + 邮箱 + 地址 | 验证中文 PII |
| 英文姓名 + email + phone | 验证英文 PII |
| API key / JWT / 数据库连接串 | 验证 Secret 阻断 |
| 普通技术问题 | 验证非敏感内容不被误伤 |
我们定义目标类型。LoomLoom 批量生成样本。最终得到 300 条 synthetic 测试数据。全程不使用真实客户数据。这一步解决的是「测试数据从哪里来」的问题。更重要的是，它让数据集从「演示样本」变成了「可回归样本」——后续改规则、换模型、换策略，都可以用同一批样本再跑一遍。
第二个问题：不能靠人工判断是否清洗干净
有了 300 条数据后，下一个问题是：怎么判断清洗结果是否安全？靠人工逐条看，很难稳定，也很难复查。我们真正要回答的是：
脱敏后的内容里，还有没有原始手机号、邮箱、密码、API key？于是我们把「清洗结果检查」也变成 LoomLoom 工作流：每条样本经过本地 Privacy Filter 清洗后，再由 LoomLoom 批量进入 judge 评测。得到的不是某个人的主观判断，而是一批样本在同一标准下的评测结果——哪些类型稳定可处理、哪些类型容易漏、哪些规则需要增强，一目了然。
这次就发现了一个具体问题：
中文自然语言里的密码表达容易漏检。例如：密码为 Temp@2024新密码 NewPass#789发现后我们增强规则，再用同一批数据回归验证。LoomLoom 的价值不是「跑了一次任务」，而是让问题发现和修复验证都变成批量、可重复的过程。
第三个问题：脱敏后回答质量有没有下降
安全只是第一步，这个 POC 还要回答另一个业务问题：脱敏后模型还能不能正常完成任务？
一开始我们做了简单对照——原始输入的回答 vs 脱敏输入的回答。但很快发现单次对照不可靠：大模型本身有随机性，有时回答短一点，不一定是脱敏导致的，也可能只是模型这次输出更保守。于是我们把「回答质量对照」也放进 LoomLoom 工作流：
同一类样本多次执行 -> 原始输入得到多次回答 -> 脱敏输入得到多次回答 -> judge 统一评分 -> 汇总平均质量差异这一步把「模型回答看起来还行」变成了「同一标准下批量打分」。团队讨论的不再是感觉，而是业务问题本身：脱敏以后，模型还能不能完成客服总结？回答质量下降是在可接受范围内，还是会影响使用？
第四个问题：实验过程怎么留下来
最后一个问题是沉淀。如果只是工程师手工跑脚本，最后往往只剩几张截图和几句口头结论。用 LoomLoom 后，这次 POC 留下了：
- 批量生成的数据
- 每条样本的清洗结果
- raw 与 sanitized 的回答对照
- judge 的统一评分
- 可整理成案例和报告的过程记录
这意味着它不是「工程师说测过了」，而是有一套可复查的过程。最后形成的闭环是：
生成数据 -> 执行实验 -> 评测结果 -> 发现问题 -> 回归验证 -> 沉淀案例LoomLoom 的真实价值：可嵌入的子工作流
LoomLoom 在这次案例里证明的不是「它能做隐私治理」，也不只是「它能批量跑评测」。更准确地说，它体现的是一种更通用的能力：
LoomLoom 可以把一段结构化 AI 工作流，作为子工作流嵌入到真实业务工作流里。在这个 POC 中，真实业务工作流是：发现 OpenAI Privacy Filter → 判断是否对胜算云生态有启发 → 做端侧脱敏 POC → 需要更多测试数据 → 需要批量评测安全性 → 需要对比回答质量 → 需要沉淀结果给团队判断。LoomLoom 嵌入其中，承担了可结构化、可重复执行的子工作流：批量生成测试数据 → 批量执行评测 → 批量 judge 打分 → 汇总结果 → 支持再次迭代。
这类子工作流不是固定死的，它可以根据不同工作目标重新设计：
| 工作目标 | LoomLoom 子工作流可以怎么设计 |
|---|---|
| 生成测试数据 | 定义数据类型、风险类型、语言、长度和输出格式，批量生成样本 |
| 评估模型质量 | 设计 judge 标准，批量比较不同模型或不同 prompt 的输出 |
| 做安全回归 | 固定测试集，反复验证规则、模型、策略变更后的效果 |
| 做内容生产 | 批量生成初稿，再用审核 workflow 做质量筛选 |
| 做客户交付验证 | 把客户场景拆成结构化输入，批量跑结果并形成报告 |
| 做产品增长素材 | 从真实使用过程里抽取案例、指标和可传播叙事 |
它也支持多次迭代优化。比如这次 POC 中，工作流不是一次设计就结束的：先做单条 demo；发现单条 demo 说服力不够，扩展成批量数据集；发现单次回答有偶然性，再升级为重复采样；发现 judge 标准不够清楚，再调整评分边界；发现中文密码规则漏检，再用同一批数据回归验证。
这个案例带出了一个很清晰的业务表达：LoomLoom 不是「又一个 AI 聊天工具」，而是让团队把 AI 能力组织成结构化工作流，并把这些工作流嵌入真实业务过程的工具。
案例亮点
这个案例的价值不只在于完成了一次 Privacy Filter POC，也在于它展示了 LoomLoom 适合服务哪类 AI 团队工作流：
- 它是真实场景：不是为了 LoomLoom 宣传而设计出来的场景，而是我们做另一个真实 POC 时自然用到了 LoomLoom。
- 它有明确业务问题：企业在使用大模型前，担心敏感信息外发。我们要验证端侧脱敏是否可行。
- 它体现了 LoomLoom 的核心能力：批量生成数据、批量执行任务、批量 judge 打分、重复采样降低偶然性、结果沉淀成报告。
- 它能引出更大的产品叙事：未来 AI 应用不是只要能调用模型就行，还需要持续评测、持续回归、持续证明质量和安全边界。LoomLoom 可以成为这个过程里的批量实验基础设施。
表达边界
可以说：
- LoomLoom 支撑了真实 AI POC 的批量实验流程。
- LoomLoom 适合批量生成 synthetic 测试数据。
- LoomLoom 适合做模型输出质量评测和对照实验。
- LoomLoom 帮助团队发现规则缺口并快速回归。
不要说：
- LoomLoom 本身负责隐私检测。
- LoomLoom 保证隐私合规。
- 脱敏后模型回答完全无损。
- 真实客户敏感数据可以直接外发给评测模型。
更准确的边界是：Privacy Filter POC 负责验证端侧隐私治理方向，LoomLoom 负责让这个验证过程批量化、可复查、可沉淀。