Show HN: Sigma Guard – 用于图内存的确定性矛盾检查
1 分•作者: invariantjason•2 个月前
我为基于图的 AI 记忆和 GraphRAG 风格的系统构建了一个小型开源验证器。<p>基本问题：图数据库可以验证模式，但它们通常不知道两个被接受的事实是否相互矛盾。一个 AI 记忆层可以存储“Acme 偏好年度账单”和“Acme 拒绝年度账单并要求按月账单”。这两种写入都可能是有效的。这种矛盾只有在稍后代理检索到两者并对其进行推理时才会显现出来。<p>SIGMA Guard 试图更早地捕捉到这一点。<p>它将声明表示为具有局部一致性规则的图，并检查所提出的结构是否可以全局一致。其底层机制使用细胞层析上同调。实际接口更简单：给定声明、图或提议的写入，它会返回 SAFE 或 UNSAFE，并附带矛盾细节和收据哈希值。<p>该代码库包括：<p>verify_claims - 检查一组主语/属性/值声明
check_write - 在提交前测试提议的图写入
verify_graph - 验证完整图
支持 Claude Desktop / 代理工作流程的 MCP 服务器
本地演示，无需 API 密钥<p>安装：<p>pip install sigma-guard[mcp]<p>运行 MCP 服务器：<p>sigma-guard-mcp<p>或者运行本地演示：<p>git clone <a href="https://github.com/Jasonleonardvolk/sigma-guard" rel="nofollow">https://github.com/Jasonleonardvolk/sigma-guard</a>
cd sigma-guard
pip install -e .
python examples/verify_llm_output.py<p>我还进行了一项规模实验，因为显而易见的反对意见是，层状图验证不适合内存。在笔记本电脑上，当前的细胞实现完成了 500 万顶点 / 39,999,936 条边的流式运行。关键技巧是避免重复的限制矩阵：8000 万个端点映射由共享存储中的 1024 个规范映射表示。在该运行中，流式更新路径的平均值为 0.119 毫秒/编辑，p99 为 1.534 毫秒。<p>除了流式基准测试之外，我还在同一 500 万图上运行了一个“中毒边”演示。一个局部限制映射被替换为循环排列。精确的局部验证重新计算了 25,473 个受影响单元格中的一个。H0 从 8 降至 1，这意味着 7 个局部一致性模式被破坏。该精确检查耗时 11.5 秒，因为它对受影响的单元格使用了密集 SVD；该演示的重点是定位和精确性，而不是生产延迟。<p>局限性：<p>这不能替代图数据库。
它不能使 LLM 的输出为真。
当前的精确中毒边演示比流式更新路径慢。
一些演示使用结构化声明而不是任意自然语言。
有趣的问题是这是否应该作为代理记忆的预提交 / 预输出验证器，而不是一个独立的数据库。<p>代码库：<p><a href="https://github.com/Jasonleonardvolk/sigma-guard" rel="nofollow">https://github.com/Jasonleonardvolk/sigma-guard</a><p>我很感兴趣听取从事图数据库、GraphRAG 或代理记忆的人的反馈。在您的技术栈中，确定性的“在记忆写入 / 代理输出之前进行验证”层是否有意义？
查看原文
I built a small open-source verifier for graph-backed AI memory and GraphRAG-style systems.<p>The basic problem: graph databases can validate schema, but they usually do not know whether two accepted facts contradict each other. An AI memory layer can store both "Acme prefers annual billing" and "Acme rejected annual billing and requires monthly billing." Both writes may be valid. The contradiction only shows up later when an agent retrieves both and reasons over them.<p>SIGMA Guard tries to catch that earlier.<p>It represents claims as a graph with local consistency rules and checks whether the proposed structure can be made globally consistent. The underlying mechanism uses cellular sheaf cohomology. The practical interface is simpler: given claims, a graph, or a proposed write, it returns SAFE or UNSAFE with the contradiction details and a receipt hash.<p>The repo includes:<p>verify_claims - check a set of subject/property/value claims
check_write - test a proposed graph write before commit
verify_graph - verify a full graph
MCP server support for Claude Desktop / agent workflows
a local demo, no API key required<p>Install:<p>pip install sigma-guard[mcp]<p>Run MCP server:<p>sigma-guard-mcp<p>Or run the local demo:<p>git clone <a href="https://github.com/Jasonleonardvolk/sigma-guard" rel="nofollow">https://github.com/Jasonleonardvolk/sigma-guard</a>
cd sigma-guard
pip install -e .
python examples/verify_llm_output.py<p>I also ran a scale experiment because the obvious objection is that sheaf-style graph verification will not fit in memory. On a laptop, the current cellular implementation completed a 5M-vertex / 39,999,936-edge streaming run. The key trick was avoiding duplicated restriction matrices: 80M endpoint maps were represented by 1,024 canonical maps in a shared store. The streaming update path averaged 0.119 ms/edit with p99 1.534 ms in that run.<p>Separate from the streaming benchmark, I also ran a "poisoned edge" demo on the same 5M graph. One local restriction map was replaced with a cyclic permutation. Exact local verification recomputed one affected cell out of 25,473. H0 dropped from 8 to 1, meaning 7 local consistency modes were destroyed. That exact check took 11.5s because it used dense SVD on the affected cell; the point of that demo was localization and exactness, not production latency.<p>Limitations:<p>This is not a replacement for a graph database.
It does not make LLM output true.
The current exact poisoned-edge demo is slower than the streaming update path.
Some demos use structured claims rather than arbitrary natural language.
The interesting question is whether this belongs as a pre-commit / pre-output verifier for agent memory, not as a standalone database.<p>Repo:<p><a href="https://github.com/Jasonleonardvolk/sigma-guard" rel="nofollow">https://github.com/Jasonleonardvolk/sigma-guard</a><p>I would be interested in feedback from people working on graph databases, GraphRAG, or agent memory. Does a deterministic "verify before memory write / before agent output" layer make sense in your stack?