为什么选择正则表达式，而不是AI？
为了满足监管合规性，您需要可以解释和重现的结果。我们的确定性方法正是提供这一点——没有黑箱，没有惊喜。
详细比较
We use the best tool for each job: deterministic regex patterns for structured data, and proven ML models for names and entities. Built on Microsoft Presidio.
| Entity Type | Detection Method | Examples |
|---|---|---|
| 结构化数据 | 正则表达式模式 | 电子邮件、社会安全号码、信用卡、国际银行账户号码、电话号码 |
| 姓名与组织 | 机器学习模型（spaCy, Stanza） | 个人姓名、公司名称、地点 |
| 48种语言 | XLM-RoBERTa | 跨语言实体识别 |
| 可重复性 | 100% 可重复 | 相同输入 = 每次相同输出 |
| 姓名检测 | 高准确率机器学习 | 经过验证的自然语言处理模型，具有置信分数 |
| 可审计性 | +完全可审计 | 每个实体的位置、类型、置信度 |
模式匹配的工作原理
每种实体类型都有精心设计的正则表达式模式，匹配特定格式。
电子邮件地址
[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}匹配标准电子邮件格式：local-part@domain.tld
信用卡号码
\b(?:4[0-9]{12}(?:[0-9]{3})?|5[1-5][0-9]{14}|...)\b匹配Visa、万事达、美国运通及其他卡格式，并进行Luhn验证
德国IBAN
DE[0-9]{2}\s?[0-9]{4}\s?[0-9]{4}\s?[0-9]{4}\s?[0-9]{4}\s?[0-9]{2}匹配带可选空格的德国IBAN格式
为合规性而构建
当审计员问“为什么会检测到这个？”时，您需要一个明确的答案。我们的基于正则表达式的方法正好提供这一点。
- GDPR第25条：隐私设计，具有可解释的处理
- ISO 27001：文档化、可重复的流程
- 审计轨迹：每个检测都可以追溯到特定模式
示例审计响应
问：为什么“john.smith@company.com”被标记？
答：在位置45-68匹配电子邮件模式，置信度0.95。模式：标准电子邮件格式验证。