展示HN：Sigma Guard – 图形内存的确定性矛盾检查
我构建了一个小型的开源验证器，用于图形支持的人工智能记忆和GraphRAG风格的系统。
基本问题是：图数据库可以验证模式，但通常无法判断两个被接受的事实是否相互矛盾。一个人工智能记忆层可以同时存储“Acme偏好年度计费”和“Acme拒绝年度计费并要求按月计费”。这两个写入可能都是有效的。矛盾只有在代理检索到这两个事实并进行推理时才会显现出来。
SIGMA Guard试图更早地捕捉到这一点。
它将声明表示为一个图，并使用局部一致性规则来检查所提议的结构是否可以实现全局一致性。其底层机制使用细胞层叠同调。实际接口更简单：给定声明、图或提议的写入，它会返回SAFE或UNSAFE，并附带矛盾的详细信息和收据哈希。
该代码库包括：
- verify_claims - 检查一组主题/属性/值声明
- check_write - 在提交之前测试提议的图写入
- verify_graph - 验证完整图
- MCP服务器支持Claude Desktop/代理工作流
- 本地演示，无需API密钥
安装：
```bash
pip install sigma-guard[mcp]
```
运行MCP服务器：
```bash
sigma-guard-mcp
```
或者运行本地演示：
```bash
git clone https://github.com/Jasonleonardvolk/sigma-guard
cd sigma-guard
pip install -e .
python examples/verify_llm_output.py
```
我还进行了一个规模实验，因为显而易见的反对意见是，层叠风格的图验证无法适应内存。在一台笔记本电脑上，当前的细胞实现完成了一个5M顶点/39,999,936边的流式运行。关键技巧是避免重复的约束矩阵：80M端点映射通过一个共享存储中的1,024个标准映射表示。该流式更新路径的平均时间为0.119毫秒/编辑，p99为1.534毫秒。
除了流式基准测试，我还在同一个5M图上进行了一个“中毒边缘”演示。一个本地约束映射被替换为一个循环排列。精确的局部验证重新计算了25,473个受影响的单元中的一个。H0从8降到1，意味着7种局部一致性模式被破坏。该精确检查耗时11.5秒，因为它在受影响的单元上使用了稠密SVD；这个演示的重点是局部化和精确性，而不是生产延迟。
限制：
- 这不是图数据库的替代品。
- 它并不使LLM输出为真。
- 当前的精确中毒边缘演示比流式更新路径慢。
- 一些演示使用结构化声明而不是任意自然语言。
- 有趣的问题是，这是否作为代理记忆的预提交/预输出验证器，而不是作为独立数据库更为合适。
代码库：
[https://github.com/Jasonleonardvolk/sigma-guard](https://github.com/Jasonleonardvolk/sigma-guard)
我希望听到从事图数据库、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?