背景
知识库将分散的信息组织成结构化的概念文档，为团队理解和 AI 辅助开发提供基础。
然而，构建、维护和检索高质量的知识库，始终面临三个核心挑战：
构建：数据分散且杂乱，概念边界难以自动发现与聚合
维护：文档持续变化，难以精确定位受影响的 wiki 文章
检索：文本只能匹配关键词，无法回答结构化关系问题
背景
当前主流做法是让 LLM 阅读全部原始数据并直接生成 wiki 文档。然而，LLM-Wiki 在构建、维护和检索三个环节都存在根本性痛点：
构建不稳定：概念边界随模型理解漂移，结果不可复现
更新不精确：难判断间接影响，容易遗漏或过度更新
检索无结构：Grep定位查询内容，向量找“相似”，但无法查询知识之间的关联关系
一、构建 wiki
NeuG Repo 的1,359 个源文件直接交给 LLM 阅读并生成 wiki，会遇到哪些根本问题？
痛点 01
LLM 倾向按目录分章，但目录结构并不等于概念结构
NeuG 方案
依据调用与引用关系聚类，让跨目录的相关文件自然归组
痛点 02
依赖文件名启发式选择，容易偏向短名 header 与边缘文件
NeuG 方案
按全局引用度排序，为每个概念组定位真正重要的入口文件
痛点 03
每次运行的分组边界和文件选择都可能发生漂移
NeuG 方案
相同的图得到相同的聚类与排序，结果 100% 可复现
实验结果一：跨目录聚合能力
典型社区 type-and-value-system 包含 187 个文件、跨 6 个路径前缀；下图用 6 个代表元素呈现两种方案的差异。
原始目录结构
实验结果二：文件重要性排序
同一 cypher-parser 章节各选 Top-5 文件：PageRank 按全局引用度排序，LLM 按文件名启发式选择，Top-5 重合率为 0%。
Cypher 解析器将查询语句转换为 AST。入口类 Transformer 声明 80+ transform 方法，覆盖完整 Cypher 语法。
parser.cpp → ANTLR4 生成解析树Transformer::transform() 遍历解析树并分发transform*() 将 ANTLR context 转为 AST 节点transformExpression() 运算符优先级链 (OR→XOR→AND→NOT→比较→算术)，返回 ParsedExpressiontransformCreateNodeTable() / transformCreateRelTable()transformQuery() → RegularQuery → SingleQuery (MATCH/RETURN/WITH)transformPattern() → 节点-关系-节点模式transformCopyFrom() / transformCopyTemp()Cypher 解析器将查询语句解析为内部表示，使用 ANTLR4 作为语法分析工具。parser.cpp 是解析入口，接收 Cypher 文本并生成解析树。
解析器支持多种语句类型（statement.h 定义），包括查询、DDL、数据库管理、数据导入等。
UseDatabase — 切换当前数据库，继承 DatabaseStatementDatabaseStatement — 数据库操作基类COPY FROM 从文件导入数据，COPY TO 导出数据。
支持 MATCH、RETURN、WITH 等查询子句和表达式运算，具体实现分布在多个 transform 源文件中。
⚠ 缺少 Transformer 类 80+ 方法分发架构、运算符优先级链、图模式解析细节
实验结果三：可复现性与效率
同一份 NeuG 代码库（1,359 文件、71 个社区 → 23 个章节）连续生成两次大纲：图方案逐字一致，LLM 的章节数量与分组边界均发生变化。
图方案 · 两次运行
23/23二、维护 wiki
当源文件持续新增、修改和删除，直接让 LLM 阅读 git diff 并更新 wiki，会遇到哪些问题？
痛点 01
可能漏掉间接影响，也会把无关的小改动误判为需要更新
NeuG 方案
Cypher group by 识别 stable、changed、new 与 dissolved
痛点 02
重新归组后旧章节编号变化，可能触发大量无意义重写
NeuG 方案
冻结旧节点与概念组，只为新增节点分配社区
痛点 03
继续依赖文件名启发式，容易遗漏真正受影响的核心文件
NeuG 方案
只对受影响社区排序，定位最重要的更新依据
痛点 04
每次推断的影响范围和文件选择都可能发生变化
NeuG 方案
相同的图变更得到相同的增量结果与文件排序
实验：图增量 vs LLM 增量扫描
47 文件变更后，图方案冻结旧章节 + 归类新文件，LLM 方案读全部 diff + 对比全部章节。
已有 Wiki（23 章节）
新增文件（git diff，35 个）
三、检索 wiki
当开发者询问“Leiden 在哪里实现、哪些模块依赖 GDS 扩展”，传统搜索为什么仍需要多轮拼接？
痛点 01
精确匹配字符串，但搜不到语义相关的代码
NeuG 方案
全文索引快速匹配符号，向量索引支持语义相似检索
痛点 02
“谁调用 Leiden？”“GDS 依赖了哪些模块？“grep 和向量 DB 都回答不了
NeuG 方案
直接返回调用路径、依赖关系和影响范围
痛点 03
AI 助手平均需要 4.8 次 grep 与文件读取才能拼出答案
NeuG 方案
1 次 context_query 返回符号定位、调用路径与依赖关系
检索实验：三类查询的端到端对比
在 NeuG 代码库上使用 GPT-5.6 完成 100 个查询 case；以下三个代表性 use case 覆盖全文、向量和结构查询。
“Leiden::local_moving_phase 在哪实现？”
返回结果：精确定位 leiden_impl.cc:157，并返回入口、主流程、refinement、sink 等 9 个相关符号。
“哪些代码实现了社区发现？”
返回结果：定位 Leiden 和 Louvain 两个算法，包含核心实现、结果结构和查询集成入口。
“GDS模块依赖哪些其他模块？”
返回结果：直接返回 4 个子模块，以及具体函数调用和源文件路径。
检索实验总结
100个查询 case 的聚合数据表明：NeuG 不只减少调用、延迟和 token，更提供 grep 与向量 DB 无法完成的结构查询。
| 方案 | 关键词搜索 | 结构查询 | 工具调用数 | 信息深度 | token 成本 |
|---|---|---|---|---|---|
| grep / 文件搜索 | ✓ 搜文本 | ✗ | 4.8 次平均 | 只能搜到文本内容 | 高（多轮搜索） |
| 向量 DB | ✓ 搜语义 | ✗ | 同上 | 可以搜到语义相关内容 | 同上 |
| NeuG 图检索 | 全文索引 + 向量索引 | Cypher 路径、依赖、影响分析 | 1 次 | 图结构信息（调用路径、依赖关系、枢纽节点） | 低（单次查询返回完整结果） |
额外能力
除 wiki 的构建、维护与检索外，NeuG 还支持远程数据读写，以及 AP/TP 访问、嵌入式和服务器部署方式。
通过统一 SQL 从 OSS/S3 导入节点与关系，或将查询和 wiki 结果直接导出到远程存储。
COPY node FROM 's3://bucket/nodes.csv'
(header=true, delim=',');
EXPORT 's3://bucket/wiki_result.csv'
FROM ...;
面向图分析、批量计算和复杂关系查询。
面向在线读写、持续更新和事务型访问。
随应用进程运行，适合本地和端侧集成。
作为独立服务运行，支持共享访问与集中管理。
总结
图数据库负责结构化、确定性的部分；大模型负责语义理解与内容生成。
NeuG 图数据库
结构化、确定性的部分
· 概念发现（Leiden 聚类）
· 变更检测（freeze-assign）
· 结构查询（Cypher）
· 文件选择（PageRank）
大模型（LLM）
语义理解与内容生成
· wiki 章节内容撰写
· 自然语言交互与问答
· 代码摘要与解释
图提供结构骨架，大模型填充语义血肉 —— 二者结合，才能构建、维护和检索高质量的知识库。