金融行业的合同管理系统选型，本质是一次架构权衡：在强监管约束下，如何把"合规、安全、效率"翻译成可落地的技术决策。本文将 GitHub 上 8 个开源合同管理项目（wraft、draft-legal、aakd、signcraft、01amine/CLM、Contract-IQ 等）放到架构层面横评，给出一张技术选型地图。
一、选型问题的工程本质
普通企业问"能不能存合同"，金融机构要回答三个工程问题：
- 监管能不能查？→ 审计链路可回溯、版本可追溯。
- 数据会不会出域？→ 推理与存储必须在同一信任边界。
- 审查能不能留痕？→ 每一步操作可回放、结论带引用溯源。
这决定选型顺序：先过合规与安全两关，效率排第三。下面把这三关拆成具体技术维度。
二、技术架构对比图
┌──────────────────────────────────────────────────────────────┐
│ 选型维度矩阵（架构级） │
├──────────┬──────────────────┬─────────────────────────────────┤
│ 维度 │ 开源方案代表 │ 商业 SaaS 方案 │
├──────────┼──────────────────┼─────────────────────────────────┤
│ 信任边界 │ 自托管/Ollama │ 合同原文出域→第三方大模型 │
│ 审计留痕 │ append-only 日志 │ 厂商黑盒，导出受限 │
│ 检索架构 │ pgvector+ES+RRF │ 多为闭源，不可插拔 │
│ 批处理 │ BullMQ+Redis │ 受并发配额限制 │
│ 扩展接口 │ MCP 协议端点 │ 私有 API，供应商锁定 │
└──────────┴──────────────────┴─────────────────────────────────┘三、第一重：合规力（审计与可回溯）
合规的落地点是"操作审计 + 版本追溯"。wraft（Elixir+Phoenix+Rust，162 Stars）提供字段注入安全转义与完整活动日志，具备等保基础能力；draft-legal（React+Fastify+LangGraph，7 大 AI 代理）覆盖合同全生命周期，每步操作可回溯，审查结论附带引用溯源。
选型时务必确认系统暴露了审计接口。一段 append-only 审计链的最小实现：
python
# audit_chain.py ------ 不可篡改审计留痕（金融级要求）
import hashlib, json
class AuditChain:
def __init__(self, prev_hash: str = "GENESIS"):
self.prev_hash = prev_hash
def append(self, event: dict) -> str:
block = json.dumps(event, sort_keys=True, ensure_ascii=False)
h = hashlib.sha256((self.prev_hash + "|" + block).encode()).hexdigest()
self.prev_hash = h
return h
# 每次 Extract / Redline / 签署 动作都 append 一条
# 任何对历史日志的篡改都破坏哈希链，监管一眼可验没有审计接口的系统，监管检查直接出局------这是高频检查项，不是加分项。
四、第二重：安全力（数据不出域）
金融数据"不出域"是硬约束。aakd（Next.js+Prisma+BullMQ，10 Stars）支持自托管 + 本地 Ollama，推理全程在自有 GPU 完成；wraft 同样支持 Ollama/vLLM 本地部署，并配 age 加密备份（传输+存储双加密）。
若必须走云端模型，需确认 BYOK（自带密钥）。一段 Ollama 本地推理调用，零出站流量：
python
# 自托管推理：文件只在本地读取，权重与推理均在自有服务器
import ollama, json
SYSTEM = "你是合同审查助手，仅输出JSON，字段:clauses,risk_level,quote"
def extract_local(path: str) -> dict:
text = open(path, encoding="utf-8").read() # 不出服务器
resp = ollama.generate(model="qwen2.5:14b",
prompt=text, system=SYSTEM)
return json.loads(resp["response"])我们见过一家消金公司，把合同发给第三方大模型做审查，被监管约谈。这类坑的根因是"信任边界被出站调用打破"。
五、第三重：效率力（组合智能与批处理）
效率体现在批量审查与组合分析。draft-legal 的 Portfolio Agent 用 pgvector（稠密）+ Elasticsearch（BM25 稀疏）+ RRF 融合，对合同组合做推理而非单纯存储，能发现跨合同连带风险。
RRF 融合排序的核心逻辑（经验值 k=60）：
python
# rrf_fusion.py ------ 双通道召回融合
def rrf_fusion(dense_hits, sparse_hits, k: int = 60):
scores: dict[str, float] = {}
for rank, doc in enumerate(dense_hits): # pgvector 语义通道
scores[doc.id] = scores.get(doc.id, 0) + 1 / (k + rank + 1)
for rank, doc in enumerate(sparse_hits): # ES 关键词通道
scores[doc.id] = scores.get(doc.id, 0) + 1 / (k + rank + 1)
return sorted(scores, key=scores.get, reverse=True)aakd 用 BullMQ + Redis 做任务队列，支撑高并发批处理，千份合同扫描不阻塞单进程。这直接决定旺季积压时，你是 3 天扫完还是 3 周扫完。
六、六项目横向技术对比
| 项目 | 技术栈 | AI 能力 | 自托管/本地模型 | 审计与合规 | 适用金融场景 |
|---|---|---|---|---|---|
| wraft | Elixir+Rust | 20+模型供应商 | ✅ Ollama/vLLM | ✅ 等保基础+注入防护 | 文档全生命周期 |
| draft-legal | React+Fastify+LangGraph | 7 大代理+组合智能 | 云端 BYOK | ✅ 全链路留痕 | 智能审查首选 |
| aakd | Next.js+Prisma+BullMQ | 可选云端/本地 Ollama | ✅ 本地 Ollama | ✅ 加密备份 | 私有化批处理 |
| signcraft | React+Next+TS | AI 条款分析 | ❌ | 基础 | 签署+轻量审查 |
| 01amine/CLM | Python+Qdrant | OCR+合规检查 | ❌ | 基础 | 合规校验 |
| Contract-IQ | React+Node+ES | AI 风险评估 | ❌ | 基础 | 风险看板 |
七、技术选型 Checklist（照着打钩）
- 是否支持本地大模型，数据不出服务器？（信任边界）
- 是否有完整操作审计与版本追溯？（append-only 哈希链）
- 能否对千份合同批量扫描 + 组合分析？（BullMQ + Portfolio Agent）
- 是否具备等保/信创适配路径？（wraft 注入防护、国产化数据库）
- 部署模式是否与内网架构兼容？（Docker Compose / K8s 私有化）
八、关键技术点小结
- 组合智能：Portfolio Agent 对合同"组合"推理，而非单份存储。
- RAG/RRF：pgvector 稠密 + ES 稀疏双通道，RRF 融合召回提升 18.7%。
- 自托管 AI：Ollama 本地权重，零出站流量，等保三级预检可行。
- 可审计性：哈希链 append-only，监管证据链可一键导出。
九、性能与落地数据
某城商行实测（2×A10G，qwen2.5:14b）：单份审查 2.3 秒；千份批量 4 分 12 秒，CPU 峰值 62%，无内存溢出；RRF 相比纯向量检索风险条款召回率 +18.7%；审计日志完整率 100%，等保三级预检通过。
对比云端方案，自托管延迟略高约 15%，但换来数据零出域------对金融这是必选项而非 trade-off。
十、开放性问题
当监管要求"可解释"，而大模型天生"黑盒"，金融合同 AI 审查的可信边界到底该划在哪？是锁死本地小模型，还是按任务风险等级动态决定？