利用Hugging Face与RAG构建本地GPU合规审查系统

我在自己的 GPU 上跑了一个 AI 合规助手——经验总结

结合 RAG、本地 LLM 推理、Terraform 配置的 AWS 基础设施，以及全栈可观测性，让南非金融监管法规变得可检索

如果你在银行合规部门工作过，一定有过这种体验：那份 200 页的指引文档里明明有你要找的条款，但你完全不知道在哪一页 📄🔍。南非金融机构面临着一整套密密麻麻的监管要求——反洗钱、反恐融资、CPF、FIC 法案、跨境电子转账报告、审慎监管局要求——这些内容大多以冗长、专业的 PDF 形式存在，搜索体验极差。

所以我决定做一个真正能回答合规问题的系统，以真实监管文本为依据，端到端可控的基础设施来运行 🛠️。不调用第三方模型的 SaaS API 黑盒服务——LLM 推理完全在本地、跑在我自己的 GPU 上，基础设施全部用 Terraform 配置 ⚙️，我能实时看到每个请求在系统中的流转路径。

这就是 Compliance RAG 的构建故事 🤖：一个面向南非监管情报的检索增强生成平台，集成本地 GPU 推理、向量数据库、基础设施即代码，以及完整的可观测性技术栈。

南非银行需要处理的义务涵盖：

反洗钱（AML）和反恐融资（CTF/CPF）

客户尽职调查与风险为本的方法

跨境电子资金转账与国际报告

FIC 法案实施要求

外国银行代表处规则

合规专员可能会问这样的问题："银行在进行客户尽职调查时必须获取哪些信息？"——这是一个完全合理的问题，但答案埋在某份指引笔记的某个角落。传统关键词搜索要么完全丢失上下文，要么返回十页八竿子打不着的相关内容 😩。真正需要的，是一个能理解问题、检索相关段落、且仅依据源文档中的内容来回答的系统——不能 hallucinate 出不存在的法规或凭空编造处罚条款。

💡 解决方案：检索增强生成，私有化部署

RAG 的核心思想很简单：不要让语言模型靠"记忆"回答（它很可能会自信地胡编），而是先从真实源文档中检索最相关的片段，然后只让模型基于这些检索到的上下文来回答。

以下是我构建的 pipeline：

PDF → Document Loader → Text Splitting → Embeddings → ChromaDB
    → Similarity Search → Relevant Regulatory Context → Gemma → Answer

监管 PDF——ML/TF/PF 行业风险评估、FIC 法案指引笔记 7B、电子转账指引笔记 8、以及外国银行代表处相关文档——存储在 S3 的"合规文档库"🪣 中，摄取、分块、嵌入、存入 ChromaDB 以支持相似性搜索。

S3 中的监管文档库——每份 PDF 都是权威源文档，更新时会重新摄取和重新嵌入。

当问题输入时，系统检索最相关的片段，连同问题一起传递给本地托管的 Google Gemma 2 2B IT 模型进行生成。我选择 Gemma 2 2B 是因为它足够小，能在单块 GPU 上流畅运行、成本可控，同时能力足够遵循严格的 grounding 指令——这正是私有化合规工具需要的权衡 🎯。在本地运行模型而非调用外部 API，意味着需要配置真正的 GPU 基础设施。

🏗️ 用 Terraform 搞定一切

我不想在 AWS 控制台里点点鼠标来启动这个系统——我要的是可重现、可版本控制、一条命令就能销毁的东西。因此每一块 AWS 基础设施——启用 GPU 的 EC2 实例、VPC、安全组、IAM 角色、S3 存储桶——全部用 Terraform 定义和部署 🧱。

cd infrastructure
terraform init
terraform plan
terraform apply

一条 terraform apply，就拥有了一个完整的网络连接、GPU 就绪的 EC2 实例，带着正确的 IAM 权限与 S3 通信——无需手动设置、无配置漂移、不想付闲置 GPU 费用时一条 terraform destroy 就清理干净 💸。

g5.xlarge EC2 实例，配备 NVIDIA A10G GPU——由 Terraform 配置，24/7 运行，托管整个 Docker 化技术栈。

🖥️ 实际使用体验

前端是一个我用 React/Vite 构建的聊天界面，我叫它"企业监管顾问"。我希望的答案不只是看起来流畅的文本——必须精确注明来自源文档的哪个位置，这样合规专员几秒钟就能自己去核实 ✅。

提问："银行在进行客户尽职调查时必须获取哪些信息？"注意侧边栏的"AI Engine: Gemma-2 Active"状态 🤖——模型仅从检索到的上下文中作答，而且——关键的是——当源文档没有明确说明时，会主动标记出来，而不是自己补全。每个答案都附有精确到页码的来源引用。

最后这一点对我非常重要。系统 prompt 明确指示模型不要编造法规、要求、处罚或日期，当文档中没有相关内容时，要直白地说出来。在合规场景下，一个自信满满的错误答案比没有答案更糟糕 ⚠️。

📡 观察系统思考过程：可观测性

自己跑 LLM 基础设施意味着你不能只相信它"在工作"——你得真正看到底层发生了什么 🔬。我用 OpenTelemetry 给整个 FastAPI 后端做了插桩，通过 OTEL Collector 导出 trace 和指标到 Prometheus、Grafana 和 Jaeger。

Prometheus 查询从 OTEL Collector 抓取的指标——请求耗时、活动请求数、直方图桶，所有数据都带标签、可查询。

Prometheus 给我原始指标——请求速率、延迟直方图、活动请求数 📊——Grafana 把这些变成我能一眼读懂的仪表盘。

基于 Metrics Drilldown 视图构建的实时 Grafana 仪表盘——请求耗时桶、吞吐量和载荷大小实时更新。

当我需要理解某个具体请求为什么慢——是嵌入步骤慢、ChromaDB 相似性搜索慢、还是 Gemma 生成本身慢？——Jaeger 给我完整的分布式 trace 🔎。

这把原本可能成为黑盒的系统变成了真正可观测的东西——我能看到请求速率、延迟百分位、GPU 健康状态，以及任意单个查询的 trace 级细节。

🧰 端到端技术栈

🐍 后端：Python、FastAPI、LangChain、ChromaDB、PyTorch、Hugging Face Transformers

🤖 AI/ML：Google Gemma 2 2B IT，NVIDIA A10G 本地 GPU 推理

⚛️ 前端：React + Vite

📈 可观测性：OpenTelemetry、Prometheus、Grafana、Jaeger

☁️ 基础设施：AWS EC2（GPU）+ AWS S3，Terraform 配置，Docker Compose 容器化，Kubernetes/Helm Manifest 扩展用

🚀 CI/CD：GitHub Actions

本地/单实例部署用 Docker Compose，需要迁移到 Kubernetes 时有配套的 Helm Chart——每块底层 AWS 资源都能追溯到一个 Terraform 模块，而非手工在控制台点击。

Grounding 决定一切。🎯 最难的不是把 pipeline 连起来，而是把 prompt 层的 guardrail 做对，让模型拒绝猜测。2B 参数的模型足够小，能在单块 GPU 上经济地运行，但也意味着你必须刻意让它保持"被牵着走"：检索上下文输入，grounded 答案输出，文档没说的就老老实实说"未找到"。

基础设施即代码回报很快。🏗️ 用 Terraform 配置 GPU 实例、网络和 S3 文档库，意味着我能在两次使用之间把整个环境销毁重建，一小时后原样恢复——这对成本控制和保持清醒都是巨大的帮助。

一旦私有化部署，可观测性就不是可选项。🔭 从你对自己的推理基础设施负责的那一刻起，"它工作正常吗？"就成了一个真正需要真实工具来回答的问题。看着 trace 瀑布流经 embedding → retrieval → generation，让我比任何猜测都更清楚地了解到延迟究竟发生在哪里。

合规 AI 有一个非常特殊的门槛。⚖️ 这个项目明确不是合规专员或法律顾问的替代品——免责声明在文档中置于显著位置。目标从来不是"相信 AI 的判断"，而是"让源材料可检索，并且始终展示你的工作过程"。

路线图上还有：混合搜索（BM25 + vector）+ cross-encoder 重排序、RAGAS 评估（忠诚度和检索精度）、监管变更检测（当源文档被取代时文档库会自动标记），以及在真正接触生产数据之前通过 Cognito/OIDC 实现企业级认证。

如果对架构感兴趣，或想构建类似系统，全部项目——Terraform 配置、Helm Chart、摄取 pipeline——都在 GitHub 上开源 ⭐。

作为专注于南非监管情报的 AI、云与合规工程项目 🇿🇦。不构成法律建议 ⚠️——请始终对照最新官方监管出版物进行核实。