【图数据库内核】全文与向量属性边界：Lucene 旁路，不是 page cache 里的第二套邻接
内容提要
本文介绍Neo4j图数据库中全文索引与向量索引的边界：两者均由Lucene驱动，不自动被Cypher规划器选用，需显式调用过程或SEARCH查询。全文索引用于分词匹配与打分，向量索引用于嵌入近邻搜索。内存上依赖OS缓存而非page cache，分数不可跨源比较，可与图拓扑扩展结合实现混合检索。
延伸解读
内存误区：加大 page cache 救不了向量查询
向量索引由 Lucene 驱动，依赖 OS 文件系统缓存，而非 Neo4j 的 page cache。因此，当向量查询变慢时，不应默认归因于 hit_ratio 问题，而应检查 OS 层内存是否充足。若内存不足，向量搜索会反复读盘，甚至触发 swap。运维上需在 heap 和 page cache 之外预留足够 RAM，并注意索引 warm-up 特性：重启后需通过查询预热。
分数不可跨源比较：混合检索的融合陷阱
全文索引和向量索引的分数仅在同一次查询结果内可比，不同来源的原始 score 不能直接相加或比较。进行混合检索时，应各源独立排序，再通过 RRF 等融合算法合并结果。常见误用是将两种分数视为同一量纲直接相加，这会导致结果偏差。
语义索引与图拓扑的拼接模式
语义索引（全文/向量）用于召回候选集，但无法替代图遍历（hop）。合理模式包括：先用语义召回获得候选，再通过 MATCH 或短 expand 进行图约束；或先用图过滤收窄范围，再对候选计算向量分。常见误用是认为 ANN 已理解关系类型，或全库向量 top-k 后再做昂贵多跳。
Q&A
Neo4j中的全文索引和向量索引有什么区别？
全文索引用于分词匹配和打分，向量索引用于嵌入向量的近邻搜索。两者都由Lucene驱动，但全文索引处理字符串内容，向量索引处理数值向量（如LIST<FLOAT>或原生VECTOR类型）。
Neo4j的全文索引和向量索引会被Cypher规划器自动使用吗？
不会。全文索引和向量索引都不会被Cypher规划器自动选用，必须通过显式调用过程（如db.index.fulltext.queryNodes）或使用SEARCH子句（向量索引）来查询。
如何创建Neo4j全文索引？
使用CREATE FULLTEXT INDEX语句，例如：CREATE FULLTEXT INDEX namesAndTeams IF NOT EXISTS FOR (n:Employee|Manager) ON EACH [n.name, n.team] OPTIONS {indexConfig: {`fulltext.analyzer`: 'english', `fulltext.eventually_consistent`: true}}。
Neo4j向量索引的内存配置有什么注意事项？
向量索引由Lucene驱动，依赖OS文件系统缓存，而非Neo4j的page cache。因此需要在heap和page cache之外预留足够RAM，否则向量搜索会频繁读盘。容量估算：逻辑向量体积约4B×d×n，量化后OS缓存约为物理索引的40%，未量化约100%。
Neo4j中全文索引和向量索引的分数可以跨源比较吗？
不可以。全文索引和向量索引的分数只在各自查询结果集内可比，混合检索时应独立排序或融合，不能直接比较原始分数。
如何将全文索引或向量索引与图拓扑扩展结合实现混合检索？
常见模式包括：先用全文或向量索引得到候选集S，再通过MATCH过滤标签或短expand进行图约束；或先用图过滤收窄候选，再计算向量分进行重排；混合检索时各源独立排序后融合。
