Ownership Lens：用图数据库穿透离岸空壳公司网络

离岸空壳公司的调查向来棘手：一家在萨摩亚或巴拿马注册的公司，表面文件齐全、董事地址清晰，孤立来看毫无破绽。但若把公司、董事、中介和地址视为一张关系网络，风险信号往往藏在连接之中——一家看似干净的公司，可能与合规观察名单上的实体仅隔四层关系。这正是黑客松项目 Ownership Lens 试图解决的问题。

问题：干净记录不等于安全

Ownership Lens 由开发者构建，参加了 WeMakeDevs 与 FalkorDB 联合举办的 Graph Hacks 黑客松。项目用一个具体案例说明浅层查询的局限：目标公司 GLAISDALE LIMITED 在深度为 1 的调查中，未发现与观察名单实体 DOM Limited 的任何直接关联，系统返回“clear”。

但当调查深度扩展到 4 跳时，一条隐藏链条浮现：GLAISDALE LIMITED → Rachel Erickson → NEWCOMBE LIMITED → ANDREW MORAY STUART → DOM Limited。这条链通过 OFFICER_OF 关系串联起共享董事网络，触发 WATCHLIST_PATH 规则，路径成本为 4.0，低于阈值 8.0，最终判定升级为“escalate”。

公司记录本身没有变化，变化的是调查范围。这印证了项目的核心洞察：风险指标存在于实体之间的关系中，而非实体自身。

数据与图架构：真实离岸记录

为避免在玩具数据上纸上谈兵，Ownership Lens 采用了 ICIJ Offshore Leaks 数据库的真实子集，覆盖巴拿马文件中的萨摩亚和塞舌尔司法辖区。数据集包含 51,940 个节点（实体、高管、中介、地址）和 58,891 条关系，在 FalkorDB 中占用 40.91 MiB 内存，落在其云服务免费层 100 MiB 限制之内。

图模型定义了 REGISTERED_ADDRESS、OFFICER_OF、INTERMEDIARY_OF 等关系类型。项目特别强调：被 ICIJ 数据库收录并不构成不法行为的证据，因此系统只报告需要人工审查的暴露指标，而非自动指控。

为什么 FalkorDB 是架构核心

项目没有把图数据库当作装饰层，图遍历和圖算法直接参与调查本身。除了路径查找，Ownership Lens 还会为每次调查构建隔离的内存临时图，在局部 k 跳子网络上运行多种算法：

• 标签传播与弱连通分量：判断目标是否与观察名单实体属于同一结构社区，对应 COMMUNITY_WATCHLIST 规则。社区成员身份只是调查线索，不是共同所有权或不法行为的证明。
• 介数中心性：识别位于多条最短路径上的潜在“守门人”中介，对应 CENTRALITY_SPIKE 规则。
• PageRank：发现网络中结构影响力突出的公司枢纽，对应 PAGERANK_ANOMALY 规则。

这些算法补充了单纯路径查询容易遗漏的网络结构信号。项目还对 30 家随机抽取的空壳公司做了度数匹配的对照测试，均未与 DOM Limited 连通，为观察到的拓扑结构提供了参照。

MCP（Model Context Protocol） 是 Anthropic 于 2024 年底提出的一种开放协议，用于标准化大语言模型与外部工具、数据源之间的交互方式。在 MCP 框架下，应用层将可调用的能力封装为“工具”（tool），每个工具声明名称、参数结构和返回值类型，模型只能从注册的工具列表中选择并填充参数，而不能自由构造任意查询或调用。这种设计将“模型能做什么”与“模型想做什么”解耦：数据库连接、查询语法、权限控制全部由应用层掌握，模型仅作为决策与编排层。对于需要可审计性的合规场景，MCP 的价值在于每一次工具调用都可被记录、重放和验证，从而避免自由生成查询带来的不可预测遍历和提示注入风险。

介数中心性（Betweenness Centrality） 衡量一个节点出现在网络中其他节点对之间最短路径上的频率。数值越高，说明该节点越是网络中的“桥梁”或“瓶颈”——许多连接必须经过它。在离岸公司调查中，高介数中心性的中介或高管可能是连接多个看似无关实体的关键节点，即潜在的“守门人”。与之互补的 PageRank 则通过迭代传播的方式评估节点的重要性：一个节点被越多重要节点指向，其自身得分越高。在所有权图中，PageRank 高的公司往往是结构上的枢纽，可能集中了大量股权或董事关系。两者都只反映拓扑结构，不直接等同于风险，因此项目将其作为调查线索而非判定依据。

三项架构决策确保代理可靠

让代理探索图是一回事，让结果可验证、可审计是另一回事。项目通过三项设计来应对后者。

类型化 MCP 工具替代自由生成 Cypher

常见做法是让大模型动态生成 Cypher 查询，但项目选择不这样做。LLM 从不编写原始 Cypher，而是从六个类型化、参数化、只读的 MCP 工具中选择：resolve_entity、ownership_chain、shared_links、path_between、cluster_view 和 recall_cases。应用层掌握数据库查询，模型只负责选择批准的工具并解读结构化结果。这降低了模型虚构关系类型、引发昂贵遍历或扩大提示注入攻击面的风险，也让调查过程更易审计。

确定性规则引擎做最终判定

合规判定不应由语言模型基于自由文本解释做出。在 Ownership Lens 中，结论完全来自 core/rules.py 中的确定性 Python 规则层。流程是：MCP 工具取回证据，归一化为结构化证据账本，规则引擎按阈值评估，应用层分配四种判定之一——clear、review、escalate 或 insufficient_evidence。LLM 只负责生成基于调查结果的解释性备忘录。

规则信号包括高管度数≥5、与观察名单实体同社区、观察名单路径成本≤8.0，以及图算法识别的结构异常，阈值依据数据集的经验百分位校准。项目明确说明：clear 仅表示在配置规则和搜索范围内未发现合格指标，并不保证实体无风险。

证据账本（evidence ledger） 是项目中用于记录每次调查所取回全部结构化证据的数据结构。MCP 工具返回的实体、关系、路径和算法结果被归一化为统一格式后写入账本，规则引擎和验证层都只读取账本内容。这种设计将“取数”与“判定”分离：规则引擎的输入是确定性的结构化数据，而非模型生成的文本；验证层也可以逐条比对备忘录中的每个名称是否真实出现在账本中。证据账本同时充当审计轨迹，使每一条判定都能追溯到具体的工具调用和返回结果。

反幻觉验证层

即使只让 LLM 写备忘录，它也可能引入证据中不存在的细节——一个虚构的高管姓名或地址就足以毁掉一次正确的调查。core/verifier.py 会将备忘录中每个具名实体、高管和地址与当次调查的原始工具输出逐一比对。若发现未经验证的名称，系统丢弃备忘录，改由证据账本直接生成确定性模板。原则很简单：证据不支持的说法，不进最终备忘录。

模型基准测试与可靠性

受限工具接口只有在模型能可靠选择工具时才有价值。项目通过托管 NVIDIA 端点，用 10 个标准化工具调用场景对多个模型做了基准测试，部署了 nvidia/llama-3.3-nemotron-super-49b-v1.5。在三次多轮调查运行中，系统通过了 15/15 次判定保真度检查。项目同时实现了确定性回退循环，避免调查流程完全依赖模型调用成功，包括应对速率限制的情况。团队也坦承，这只是自身评估环境的结果，并非对模型普适准确性的声明，投入生产前还需覆盖更多实体、边缘案例和对抗性输入的测试。

本地运行与后续方向

项目可通过 Docker Compose 启动完整栈，包括 FalkorDB、浏览器界面和 FastAPI 应用。克隆仓库、配置 .env 后执行 docker compose up -d，即可在 localhost:8000 进入交互式 Cytoscape 图画布，对比深度 1 和深度 4 的结果。

下一步计划包括扩展评估数据集、测试更多对抗性和模糊案例、改进图指标校准，以及强化单条规则决策的审计轨迹。团队强调，任何真实部署都需要人工监督、独立验证和适当治理，才能用于支持有后果的合规决策。目标不是自动给公司贴上可疑标签，而是帮助调查人员发现连接、理解证据，并决定什么值得进一步查看。

对图数据库、AI 代理、欺诈检测和反洗钱领域感兴趣的开发者，可以在 GitHub 上查看完整代码并本地复现。