2 分•作者: 2dogsanerd•4 天前
过去几个月,我一直在为受监管环境设计一个 RAG 系统。我不是专业开发人员,但我以严格的“系统工程”和审计思维来构建它。
虽然大多数教程止步于“LangChain + VectorDB”,但我发现,要使其在法律上站得住脚并在运营上保持稳定,需要大约 40 多个额外的组件。
我们从一个简单的摄取脚本转移到“多车道共识引擎”(灵感来自六西格玛),因为标准的 OCR/提取对于我们的用例来说,太容易产生幻觉了。
我们不得不构建广泛的审计、细化到文档级别的 RBAC,以及混合图数据库+向量检索,以获得可接受的准确性。
目前的架构包括:
摄取:4 个并行提取车道(视觉、布局、文本、法律),带有一个共识引擎(“Solomon”),该引擎仅索引由多个来源确认的数据
检索:混合 Neo4j(图数据库)+ ChromaDB(向量数据库),采用互易秩融合
性能:语义缓存(Redis),专门用于含义相似的查询(加速 40 倍)
安全性:完整的 RBAC、对每个提示/检索的审计日志记录以及 PII 屏蔽。
我记录了完整的功能列表和差距分析
[https://gist.github.com/2dogsandanerd/2a3d54085b2daaccbb1125601945ceeb](https://gist.github.com/2dogsandanerd/2a3d54085b2daaccbb1125601945ceeb)
我向社区提出的问题是:
看看这个列表——“稳健的生产工程”和“过度工程”之间的界限在哪里?
对于那些从事金融科技/医疗科技 RAG 的人来说:我还在这个列表中遗漏了哪些关键的失效模式?