金融文档欺诈正在变得更快、更像真文档，也更难靠人工逐页检查。Inscribe 的做法是把专家欺诈分析师的工作方式拆成一个基于 Amazon Bedrock 的 agentic AI 系统：跨文档推理、寻找篡改和伪造痕迹、识别 AI 生成内容，并在 90 秒内给出可解释判断。相比传统人工复核，这类流程的关键价值不只是“快”，而是把速度、准确性和监管需要的解释链放在同一个系统里。
反欺诈不是单点分类，而是跨文档推理
很多文档风控系统容易被做成一个二分类器：上传文件，输出 fraud 或 not_fraud。这对金融服务场景通常不够。
真实的欺诈分析师会做几件事：
- 看单份文档是否有篡改痕迹，例如字体、边距、表格、日期、金额格式不一致。
- 对比多份文档之间的事实，例如银行流水、工资单、税表、身份信息是否互相矛盾。
- 判断文档是否可能由生成式 AI 制造，例如文本过于规整、元数据异常、缺少真实业务噪声。
- 写出能被审计、复核和监管解释的理由，而不是只给一个分数。
Inscribe 使用 Amazon Bedrock 构建 agentic AI 系统，核心变化就在这里：模型不是只执行一次“分类”，而是像分析师一样拆解任务、读取证据、比较字段、形成结论。对于金融机构来说，这种设计更接近合规审查流程，因为系统输出需要能说明“为什么怀疑这份文档”。
Bedrock 在这里适合承担什么角色
Amazon Bedrock 的价值不在于替代所有文档处理组件，而是作为托管的基础模型和智能体编排层，承接推理、总结、证据组织和自然语言解释。
一个较稳妥的工程拆分可以是：
- 文档解析层：提取文本、表格、图片、元数据，可结合 OCR 或既有文档处理流水线。
- 证据层：把金额、日期、账户、雇主、地址、文件属性等结构化出来。
- 推理层：使用 Bedrock 上的模型或 Agent 做跨文档比较和异常解释。
- 决策层：把模型输出变成风险等级、人工复核队列、审计记录。
这样设计的好处是边界清楚。模型负责它擅长的语义推理和解释生成；确定性的校验，例如日期格式、金额求和、账户尾号匹配，仍然可以由普通代码完成。反欺诈系统里，确定性规则和 LLM 推理不是互斥关系，而是互相补位。
可以这样实践：用 Bedrock Runtime 做一个文档风险审查原型
下面示例演示一个最小可改造版本：把已经抽取出的文档文本交给 Amazon Bedrock，让模型输出结构化 JSON，包括风险等级、发现点和建议动作。
运行前需要替换：
AWS_REGION：你的 Bedrock 可用区域，例如us-east-1。MODEL_ID：你账户已开通的模型 ID。- AWS 凭证：本机需已配置
aws configure，或通过环境变量/角色提供权限。
安装依赖：
python -m venv .venv
source .venv/bin/activate
pip install boto3
保存为 bedrock_document_review.py：
import json
import os
import boto3
AWS_REGION = os.getenv("AWS_REGION", "us-east-1")
MODEL_ID = os.getenv("MODEL_ID", "anthropic.claude-3-5-sonnet-20240620-v1:0")
client = boto3.client("bedrock-runtime", region_name=AWS_REGION)
DOCUMENTS = [
{
"name": "bank_statement.txt",
"text": """
Bank Statement
Account holder: Alex Chen
Statement period: Jan 1 2024 - Jan 31 2024
Ending balance: $48,920.13
Employer deposit: Northstar Labs Payroll $8,400.00 on Jan 26 2024
PDF metadata creator: Unknown
""",
},
{
"name": "paystub.txt",
"text": """
Paystub
Employee: Alex Chen
Employer: North Star Laboratory LLC
Pay date: Jan 26 2024
Net pay: $8,400.00
Address: 120 Market Street
Font spacing appears inconsistent in the employer line
""",
},
]
prompt = f"""
You are a financial document fraud analyst.
Review the following extracted document text. Reason across documents.
Look for tampering, fabrication, AI-generated content, metadata anomalies, and cross-document inconsistencies.
Return strict JSON only with this schema:
{{
"risk_level": "low|medium|high",
"findings": [
{{"type": "tampering|fabrication|ai_generated|inconsistency|metadata", "evidence": "...", "why_it_matters": "..."}}
],
"recommended_action": "approve|manual_review|reject",
"explanation": "short explanation for an audit log"
}}
Documents:
{json.dumps(DOCUMENTS, indent=2)}
"""
body = {
"anthropic_version": "bedrock-2023-05-31",
"max_tokens": 1200,
"temperature": 0,
"messages": [
{
"role": "user",
"content": [{"type": "text", "text": prompt}],
}
],
}
response = client.invoke_model(
modelId=MODEL_ID,
body=json.dumps(body),
)
payload = json.loads(response["body"].read())
text = payload["content"][0]["text"]
print(text)
运行：
AWS_REGION=us-east-1 \
MODEL_ID=anthropic.claude-3-5-sonnet-20240620-v1:0 \
python bedrock_document_review.py
这个示例不是完整的 Inscribe 系统，只是一个可实践的骨架。生产系统还需要接入真实 OCR、文件哈希、元数据提取、图像取证、权限隔离、审计日志和人工复核工作台。
让输出可解释，而不是只给风险分
来源摘要里提到，Inscribe 的系统在保持金融服务监管所需准确性和可解释性的同时，将检测时间压到 90 秒内。这里的“可解释性”非常关键。
建议把模型输出拆成三个层次：
finding：具体发现了什么，例如雇主名称不一致、PDF 元数据缺失、字体局部异常。evidence：证据来自哪份文档、哪个字段、哪段文本或哪个图像区域。action：系统建议放行、拒绝，还是进入人工复核。
不要只保存最终结论。审计时真正有价值的是证据链：模型看到了什么、如何比较、为什么触发人工复核。对于高风险金融流程，建议把原始文档版本、抽取结果、提示词版本、模型 ID、响应 JSON、人工复核结果全部归档。
落地时要守住的边界
这类 agentic AI 文档反欺诈系统适合放在“高吞吐初筛 + 专家复核增强”的位置，而不是一开始就完全自动拒绝用户。原因很现实：文档质量差、OCR 错误、合法格式差异、跨地区模板差异，都会让模型判断出现偏差。
采用时可以按这个清单推进：
- 从人工复核耗时最长、欺诈成本最高的文档类型开始，例如银行流水、工资单、税务文件。
- 把 LLM 判断和确定性规则结合，避免所有事实校验都交给模型。
- 要求模型输出结构化 JSON，便于审计、检索和回放。
- 对
high risk结论设置人工复核，先收集误报和漏报样本。 - 持续评估延迟、成本、准确率和解释质量，不只看单次模型输出是否“像专家”。
Inscribe 的案例说明，Amazon Bedrock 可以支撑一个更接近专家工作流的文档欺诈检测系统：不是简单问模型“这是不是假的”，而是让系统在秒级时间内阅读、对比、推理并留下可审计的解释。对金融团队来说，这才是从 AI demo 走向生产风控的分界线。