AI Regulatory Compliance Assistance System

背景故事：一个让酒商"睡得着觉"的 AI 系统

纽约州的酒类定价法规，可能是全美最复杂的之一。不同州的法规交叉、不同零售渠道的价格限制、批发价与零售价的关系——任何一位新入行的酒类经销商，面对厚厚的法规文本，都可能感到头皮发麻。传统的做法是雇佣专门的合规律师团队，每年花费数十万美元做合规审查。

Ramseygithub 决定用 AI 来解决这个问题。这个项目诞生于对"监管合规成本过高"这一痛点的深刻洞察，目标是将专业律师的合规分析能力，平民化地提供给每一个酒类经销商——无论规模大小。

这个系统的开发者（Rensi Chen 和 Yueqi Tian）在法规文本处理、自然语言理解、知识图谱构建三个方向都有技术积累。他们选择了 RAG（检索增强生成）+ 知识图谱的双轨技术路线，这在当时的法律 AI 领域是相当前沿的架构选择。

---

核心功能：从法规文本到合规建议

文档处理与理解

系统支持 PDF 和 HTML 两种格式的法规文档上传。底层使用 PyPDF2 解析 PDF 内容，BeautifulSoup4 处理 HTML。文档上传后，系统自动完成以下处理：

• 文本提取：将 PDF/HTML 中的文字内容完整提取出来
• 语义分段：按照法规的章节结构进行语义切分，便于后续检索
• 元数据提取：提取文档的标题、日期、适用范围等元信息

这个阶段是整个系统的"原材料加工"环节。如果输入的法规文本本身就存在歧义或信息残缺，后面的 RAG 和知识图谱再强大也无济于事。因此，文档处理模块的质量直接决定了系统输出的可靠性。

向量化与语义检索

提取后的文本片段，通过 阿里云百炼 Embedding API（text-embedding-v1 模型）进行向量化处理，转换为高维语义向量，然后存入本地向量索引。

检索时，用户输入的自然语言查询同样经过向量化处理，然后在向量空间中通过余弦相似度计算，找出与查询语义最接近的法规文本段落。这里使用 scikit-learn 的向量相似度计算模块，而非重型向量数据库（如 Milvus、Pinecone），体现了"够用就好"的设计哲学。

知识图谱构建

这是本项目区别于一般 RAG 系统的重要特征。系统不仅做向量检索，还会额外调用 阿里云百炼 Qwen-Turbo 模型，从法规文本中提取结构化的法律实体（条款、违规类型、处罚标准等）和它们之间的逻辑关系，最终输出 JSON 格式的知识图谱。

这个知识图谱有什么实际价值？举例来说，当你问"在某类零售商处销售某品牌葡萄酒，最低定价是多少"时，系统不仅能找到相关的法规文本段落，还能通过知识图谱理解"零售商类型 + 品牌分类 + 定价规则"之间的约束链条，给出有逻辑依据的答案，而不是一段模糊的原文摘录。

合规判断工作流

当用户描述一个具体的商业场景时，系统会综合以下因素进行多维度分析：

1. 相关法规检索：从向量索引中找出适用的法规依据
2. 上下文增强：通过知识图谱补充法规之间的关联关系
3. 逻辑分析：基于提取的规则进行多因素合规逻辑推理
4. 风险评估：给出风险等级（高/中/低）
5. 建议生成：如果存在违规风险，给出具体的整改建议

整个流程看起来简单，但背后涉及检索、上下文构建、逻辑推理三个环节的紧密配合，架构设计颇具挑战性。

Web 前端交互界面

系统提供了一个前后端分离的 Web 交互界面，包含两个端口：

• 用户端（/）：供普通用户进行法规问答和合规分析查询
• 管理端（/admin）：供管理员上传法规文档、管理知识图谱、查看系统统计

管理端还提供了一个系统统计面板，可以查看文档总数、向量片段数量、问答记录等运营数据。

---

技术架构：FastAPI + 本地 JSON 存储

后端技术栈

整个系统的后端基于 FastAPI 构建，选择 FastAPI 而非 Flask 或 Django，主要考虑是：

• 自动 OpenAPI 文档：FastAPI 自动生成 /docs API 文档，降低集成和调试成本
• 异步支持：原生支持异步处理，适合 I/O 密集型的文档处理和 API 调用场景
• 类型安全：基于 Pydantic 的数据验证，减少运行时错误

核心依赖包括：

依赖	用途
FastAPI + Uvicorn	Web 框架与 ASGI 服务器
Pydantic	请求/响应数据建模与验证
python-multipart	支持文件上传
requests	调用阿里云百炼 API
PyPDF2	PDF 文档解析
BeautifulSoup4	HTML 内容提取
numpy + scikit-learn	向量相似度计算
python-jose + passlib	认证与密码安全

部署架构分析

从部署角度来看，这个项目有几个值得注意的特点：

无需 GPU — 所有计算均为 CPU 密集型（文本处理、向量计算）和 API 调用（阿里云百炼），没有本地模型推理需求，因此不需要 GPU 资源，普通云服务器即可运行。

本地文件存储 — 系统使用本地 JSON 文件存储文档元数据、向量片段和知识图谱数据，存储目录为 ./data/ 和 ./uploads/。这种设计对中小规模使用场景足够了，但生产环境中建议替换为 PostgreSQL + 向量数据库（如 Qdrant）的组合。

必填 API 密钥 — 运行时必须配置 ALIBABA_API_KEY，指向阿里云百炼服务的凭证。如果没有这个密钥，系统的核心 AI 功能（向量化、RAG 问答、知识图谱构建）将完全不可用。

无容器化支持 — 项目未提供 Dockerfile 或 docker-compose.yml，部署需要手动安装 Python 依赖（pip install -r requirements.txt）。不过项目提供了一个交互式启动脚本 run_system.py，引导用户完成依赖安装、服务启动和 API 测试，降低了上手门槛。

代码结构

从 reprocess_documents.py 的引用关系可以推断，app/document_processor.py 是文档处理模块的核心类，负责 PDF/HTML 解析和元数据提取。由于 app/ 在 Git 树中作为单个文件存储（而非目录），项目结构实际上相当简洁：主要逻辑集中在 main.py 和 app/ 中，另外还有独立的脚本文件用于特定任务（reprocess_documents.py 处理文档重新统计，quick_test.py 用于 API 测试）。

---

使用体验：上手门槛与适用场景

适用人群

这个系统最适合以下场景：

• 中小型酒类经销商：没有专职合规团队，需要低成本的法律合规自查工具
• 法律科技创业公司：以本项目为基础进行二次开发，快速构建法律 AI 产品原型
• 法律研究者：用于研究酒类定价法规的文本结构和逻辑关系

局限性

必须坦诚地指出这个系统的一些局限：

1. 数据主权问题：法规文档和业务数据都存在本地服务器上，但如果部署在公有云，需要确保阿里云的数据处理符合你的隐私合规要求
2. 可扩展性有限：本地 JSON 存储方案在文档量超过数千份时会遇到性能瓶颈，不适合大规模生产环境
3. 仅针对纽约州法规：从项目的 topics（pricing-law、regulatory-analysis）和描述来看，当前主要面向纽约州的酒类定价法规，通用性有限
4. AI 模型依赖阿里云：所有核心 AI 能力（Embedding、Qwen-Turbo）都依赖阿里云百炼服务，离线或网络不稳定时功能受限

部署难度评估

整体部署难度较低，适合有一定技术背景的用户。标准部署流程如下：

1. 安装 Python 3.8+ 环境
2. 执行 pip install -r requirements.txt
3. 配置 .env 文件，填入 ALIBABA_API_KEY
4. 运行 python run_system.py，选择"完整测试"模式验证系统

---

行业意义与趋势

法律 AI 是近两年增速最快的 AI 应用垂直赛道之一。从海外的 Harvey AI、EvenUp 到国内的秘塔科技，法律场景天然具备高价值、高付费意愿的特点。本项目选择的"酒类定价合规"细分赛道切入点很有意思——这是一个被大厂忽视、但实际需求广泛的小切口。

从技术趋势来看，RAG + 知识图谱双轨架构正在成为法律 AI 领域的主流技术范式。RAG 提供检索的准确性，知识图谱提供推理的深度，两者结合能够弥补单纯向量检索在复杂逻辑推理上的不足。本项目的架构设计与这一趋势高度吻合，体现了开发者对技术选型的敏锐判断。

随着多州法规库的扩展和垂直领域知识图谱的积累，这类工具完全有可能演变为酒类行业合规领域的专业基础设施。