[Feature]: 构建类似图谱的功能

[liunux4odoo]

Problem Statement

虚拟文件系统在层级结构上很好，但广度不足，容易陷入局部深度陷阱

Proposed Solution

在解析阶段提取实体或关键概念短语，在不同的md文件之间建立 wiki link （类似obsidian的双链， mempalce的 room tunnel），在深层的段落之间建立横向关联，形成类似图的结构。在检索阶段进行一定的图扩展，可以帮助发现相同概念的横向关系。

Alternatives Considered

No response

Feature Area

Core (Client/Engine)

Use Case

我有两个独立的项目A和B，里面都使用了 fastapi + JWT 作为认证。
当前检索下，很可能在其他额外条件约束下结果都收窄到项目B的目录下，忽略了项目A的知识。通过 fastapi+jwt 这一link，可以把两个项目的知识都检索到。

Example API (Optional)

Additional Context

No response

Contribution

• I am willing to contribute to implementing this feature

[qin-ctx]

目前有一个方案，后续会发出来

[qin-ctx]

cc @chenjw

[huangruiteng]

I re-audited this issue against current main and the complete open-PR queue. It is no longer an entirely uncovered feature request, but the implementation boundary is still ambiguous.

Current main already has persistent relation tables plus GET /api/v1/relations, POST/DELETE /api/v1/relations/link, and a build_graph endpoint. However, retrieval does not currently expand or score those links: HierarchicalRetriever._convert_to_matched_contexts() still initializes every result with relations = [].

Open PR #2555 is a semantic overlap even though it does not reference this issue. It proposes optional graph-aware scoring from .relations.json and memory links/backlinks. That covers retrieval-time use of existing relations, but the original request also asks for parse-time extraction of concepts/entities and automatic cross-document link construction. Those are separate capabilities and should not be implicitly treated as delivered by a relation-count score alone.

Suggested disposition/acceptance split:

1. Link feat(retrieve): add knowledge-graph-aware scoring to retrieval pipeline #2555 to this issue as the retrieval-expansion slice, if maintainers intend to pursue it.
2. Keep parse-time automatic relation extraction as a separate slice with explicit scope, confidence/provenance, update/delete behavior, and cross-project tests.
3. Define an end-to-end acceptance case where two independent project trees sharing concepts such as FastAPI + JWT both surface after graph expansion, while graph_alpha=0 preserves current ranking.

Could maintainers confirm whether #2555 is the previously mentioned planned approach? Once that is clear, this issue can track the remaining extraction slice instead of staying as a broad, stalled graph request.