Project
新加坡 PDPA 法律合规 RAG Agent
为法律咨询场景设计检索增强生成系统,把人工跨文档比对变成可复用的合规问答流程。
Python · RAG · Prompt Engineering · OpenAI API · Legal NLP
Product Snapshot
- Role
- 产品研发与算法工程
- Focus
- 法规咨询场景下的 RAG 架构、检索链路、多轮 prompt chain 与 PDF 解析调研。
- Validation
- 合作律所的项目 benchmark 记录显示,系统评分基准值提升 33%。
- Public Proof
- RAG 链路、评测材料与合作律所 benchmark 记录交叉验证;该指标未在本次整理中独立复跑。
Next Step
背景
2026 年,我在揽岳智能参与了一个面向新加坡数据合规法律咨询场景的 RAG agent 项目。
问题很典型,也很真实:面对 PDPA 一类的法规咨询,律师需要在多份监管文件之间来回查找、交叉比对,再把结果组织成可解释的判断。人工流程慢、贵,而且稳定性依赖具体经手的人。
我负责的部分
我参与的重点不只是“把模型接上文档”,而是把整个问答过程变成一条可复用的系统链路:
- 协助设计和优化面向法规咨询的 RAG 架构
- 参与文档解析与检索流程设计,让法规条文能被稳定召回
- 调整多轮 prompt chain,让回答既保留法律语境,也尽量减少随意发挥
- 把系统表现和真实咨询场景对齐,而不是只追求 demo 演示效果
同时,我也在继续做 PDF 解析相关的行业产品调研和方案设计,因为这个能力会直接影响上游文档质量。
结果
合作律所的项目 benchmark 记录显示,模型评分基准值提升了 33%。该指标来自项目材料,本次 portfolio 整理没有独立复跑。
对我来说,这个数字有两个意义:
- 它说明 RAG 在高精度、强约束场景里确实能创造价值。
- 它也提醒我,真正重要的不是模型“说得像不像”,而是它能不能在具体专业流程里减少摩擦、提升一致性。
这个项目让我更确定的一件事
我越来越相信,AI 系统真正的门槛不在“大模型会不会回答”,而在于:
- 上游知识是否被清楚组织
- 中间链路是否可解释、可调试
- 下游用户是否能把结果纳入自己的专业判断
法律合规是一个很好的训练场,因为它不允许你把“差不多”当成完成。
我带走的经验
这段经历让我更明确自己想做的方向:
- 面向真实工作流的 agent system
- 对 precision 和 trust 有要求的 AI 产品
- 既关注工程实现,也关注 interface 和决策体验的系统设计
对一个想长期做 AI builder 的人来说,这比单纯做一个“很会聊天”的 demo 更重要。
配置公开站点的 Giscus 环境变量后,这里就会出现讨论区。