常见问题 FAQ
先用 Ctrl+F 搜关键词；若问题涉及选型，请准备「查询形状 + 数据规模 + 一致性要求」三要素再对照答案。
A. 概念辨析
A1. 图数据库和关系型数据库谁更好？
没有绝对更好。深路 径、动态关系、频繁多跳模式匹配 → 图更合适。强事务报表、固定模式表连接、成熟 BI 工具链 → 关系库更合适。多数企业是共存：关系库作权威业务库，图作关系服务层。
A2. 属性图和 RDF 怎么选？
团队偏应用开发、需要灵活属性与 Cypher/GQL → 属性图。需要本体推理、跨组织语义交换、标准 SPARQL → RDF。也可以双模或同步关键子集。
A3. 知识图谱是不是就是图数据库？
不是。图数据库是存储与查询引擎；知识图谱是带语义约束与治理的数据产品。可以用图数据库实现知识图谱，也可以用 RDF 库或其他存储。
A4. GraphRAG 能否取代向量 RAG？
不能简单取代。GraphRAG 擅长结构化约束与多跳证据；向量擅长语义模糊匹配。生产系统多为组合。若语料本身几乎无稳定实体关系，硬上图可能得不偿失。
A5. GNN 是否必须？
否。许多问题用中心性、路径、规则就够。GNN 适合有标签/反馈、需要泛化到新节点或复杂模式的场景。先基线后神经网络。
A6. 「图计算」和「图数据库」区别？
图数据库侧重持久化与在线查询（OLTP 或混合）；图计算框架（GraphX、Pregel、cuGraph）侧重批量分析。也有系统试图统一两者，但运维与一致性模型仍要分别理解。
B. 建模问题
B1. 什么时候把概念建成节点而不是属性？
若它会作为查询起点、会与其他实体产生多种关系、需要独立生命周期或权限，倾向节点；否则属性。
B2. 时间应该放边上还是做成事件节点？
简单「从何时开始」→ 边属性通常够用。复杂事实（多人多地多阶段）→ 事件节点更清晰，便于审计与时序分析。
B3. 无向关系如何建模？
属性图通常仍存有向边，查询时不区分方向，或强制双向双写。需在词表中规定，避免半边存在。
B4. 多重边要不要允许？
若同一对节点同一类型边可能有多段历史（多次合作），允许多重并加时间属性；若语义是单例关系，用唯一约束或 MERGE 策略。
B5. 标签太多会怎样？
标签是查询与索引的重要信号，但过度标签化会让词表崩溃。保持受控集合，用属性表达细分类。
C. 查询与性能
C1. 为什么 *1..5 查询有时极慢？
中间结果组合爆炸、缺索引、从超级节点出发、边类型过宽。用 PROFILE、降深度、加类型过滤、换起点、限制返回。
C2. shortestPath 一定最优吗？
在无权或引擎定义的权重语义下找最短；业务「最优」可能含多约束（避开某类边、时间窗）。需要自定义算法或筛选。
C3. 索引是不是建越多越好？
否。索引加速点查，但拖慢写入并占空间。按慢查询与黄金查询驱动，定期废弃无用索引。
C4. 如何分页路径结果？
避免深 SKIP。使用游标（上一批最后路径签名）、限制路径数，或先返回摘要再按需展开。
C5. 缓存该缓什么？
热点 邻域摘要、物化计数、社区标签、实体链接词典。慎缓存完整大路径枚举（易不一致）。
D. 知识图谱与抽取
D1. LLM 抽取的三元组能直接入库吗？
不建议直接进生产正式层。需模式校验、实体链接、置信度阈值、抽样人工。建议进 staging 图。
D2. 实体融合冲突怎么办？
定义权威源优先级；冲突字段进入待审；保留来源溯源；禁止静默覆盖。
D3. 如何防止图谱腐烂？
新鲜度监控、过期边、源系统对账、定期死链检查、版本化流水线。
E. GraphRAG
E1. 微软 GraphRAG 的社区摘要一定要做吗？
全局概括类问题收益大；局部事实问题可能只需实体子图。先用评测集证明收益再承担索引成本。
E2. 如何减少幻觉？
强制引用、无证据拒答、降低温度、边类型白名单、答案与证据自动对齐检查、人工抽检。
E3. 图更新后向量要不要全量重建？
看映射：若块内容变，需更新对应向量；若仅图关系变，向量可不动但检索逻辑要读新图。版本号对齐是关键。
F. GNN
F1. 为什么验证集虚高？
链接泄漏、随机划分导致未来信息泄漏、用了测试邻接。 检查划分协议。
F2. 过度平滑是什么？
层数过深导致节点表示趋同，分类变差。减层、加残差、换架构、做邻域采样。
F3. 异构图必须上复杂模型吗？
先从简单关系型转换或 R-GCN 类基线开始；复杂度与数据量、收益匹配。
G. 工程与安全
G1. 能否让前端直接跑 Cypher？
强烈不建议。易注入、易拖垮、难租户隔离。用意图化 API。
G2. 多租户最常见漏洞？
服务端忘记附加租户过滤；管理员查询接口被普通用户复用；缓存键未含租户。
G3. 备份只拷数据文件够吗？
不够。还要约束、索引、配置、流水线位点、向量侧一致性与恢复演练证明。
H. 选型速答
H1. 十万节点入门？
Neo4j / 单机属性图 + NetworkX 分析通常足够。
H2. 十亿边分析？
考虑分布式图库或离线图计算（cuGraph、专用 MPP），并重做分区与超级节点方案。
H3. 强 OWL 推理？
RDF 库 + 推理机路径更直接。
H4. 云上托管？
可用托管图服务，但仍需自己负责模型、查询成本与安全边界。
I. 学习路径
I1. 不会图论能入门吗？
能。先掌握点边路径与 BFS/中心性直觉，再补形式化。边做边学优于先啃全书。
I2. 要先精通深度学习吗？
不必。图数据库与知识图谱可先独立掌握；GNN 放在能建图、会评测之后。
I3. 如何证明自己学会了？
交付物：Schema ADR、黄金查询 CI、一次 GraphRAG 评测报告、一次超级节点治理记录。比证书管用。
J. 排错决策树
K. 还有问题？
带着「查询文本、执行计划、度 Top、数据规模、期望结果」去社区或团队图诊所；没有这些上下文，任何建议都只是猜测。系统准则见 最佳实践；成长路径见 从零到一。
L. 更多情景问答
L1. 我只有 CSV，没有图库，能开始吗？
能。先用 NetworkX 验证查询形状与算法收益，再决定是否引入持久化图库。许多失败项目是「先买引擎后找问题」。
L2. 图可视化卡顿怎么办？
不要一次渲染十万点。只可视化查询返回的子图；服务端硬限制；用聚合节点（社区超点）做概览。
L3. 如何估计图存储容量？
粗估：节点数×平均属性字节 + 边数×（ 指针/类型/属性）×复制因子 + 索引开销。更可靠的是用真实样本 bulk 导入后测量，再线性外推并留 50%+ 余量。
L4. 事务里跑算法可以吗？
短事务里跑局部查询可以；全图迭代算法应脱离在线事务，以免锁与内存风险。
L5. 出现重复节点怎么清洗？
先冻结写入，建相似候选（名字/证件/向量），人工或规则合并到 canonical，重挂边，保留合并审计，再开放写入。
L6. Cypher 和 GQL 什么关系？
GQL 是国际标准，Cypher 是重要实践来源与方言。关注标准有助于长期可移植，但日常仍以你所选引擎文档为准。
L7. 图里适合存嵌入向量吗？
可以作属性，但大规模近邻检索通常仍用专门向量库。图负责关系约束，向量库负责相似检索， 各司其职。
L8. 如何向领导证明「该上图」？
用同一业务问题做 SQL 递归 CTE 与 Cypher 对比：代码复杂度、延迟、可解释路径。再估算维护成本。避免只讲潮流术语。
L9. 数据很少时 GraphRAG 失败？
实体稀疏、链接失败、扩展为空。先改善词典与同义词，降低跳数依赖，或暂时纯向量 + 人工知识表。
L10. 学完 FAQ 下一步？
按 从零到一 走 7 天，并把每天的产出物放到自己的脚手架仓库。
M. 术语速查
| 术语 | 一句话 |
|---|---|
| 免索引邻接 | 邻居指针可直接跟随，遍历少依赖全局索引 |
| 图投影 | 为算法抽取的临时子图 |
| 超级节点 | 度极高的节点 |
| TBox/ABox | 本体模式 / 实例事实 |
| 消息传递 | GNN 聚合邻居更新自身 |
| 忠实度 | 答案被证据支持的程度 |
| 黄金查询 | 用于回归的标准业务查询 |
N. 结语
FAQ 的正确用法是：带着自己的图与查询回来重读。第二遍你会看到第一遍忽略的限制条件。若某条答案与你的引擎行为不符，以引擎文档与 PROFILE 为准，并欢迎把差异写成团队笔记。
O. 课堂与面试高频题
O1. 解释免索引邻接
邻居存储为可直接跟随的结构，遍历成本与度数相关，而不是每次都通过全局索引查找边表。这是原生图存储常强调的点；是否「纯」免索引因实现而异，但思维模型有用。
O2. 什么是图投影？
从大图抽取算法所需的子图或无向化/过滤后的视图，例如只保留 KNOWS 边做社区发现。投影质量直接影响算法结论。
O3. 如何做图上的 AB 测试？
对推荐/风控策略：控制查询形状与特征版本；注意网络效应导致的干扰（一个用户影响邻居）。可用集群级或时间片实验，并报告干扰假设。
把这些题写进自己的闪卡，FAQ 就从「阅读材料」变成「主动记忆」。