最近折腾知识库问答，遇到过几个处理不好的场景：
- 多跳推理抓瞎：比如问“张三的上级和李四负责的项目有什么合作”，但文档里张三、李四和项目分散在不同段落甚至不同文件里。单纯做向量相似度搜索（ Top-K ），很容易漏掉中间关联的 chunk ，上下文拼不起来。
- 全局总结回答不了：比如问“这批文档里主要讨论了哪几个核心方向？”，向量检索只能抓几个局部碎片，很难给出一个宏观维度的归纳。
微软之前开源的 GraphRAG 确实给了一个挺漂亮的解法，但官方那套强绑定 Python ，环境配置、微服务依赖和数据流对日常写 Node / TS 的同学来说实在有点重。加上平时业务数据库本来就是 PostgreSQL （加了 pgvector ），我就琢磨着能不能直接在 TypeScript 生态下搞一套干净好用的实现。
边写代码边整理了几篇技术博客，把整个技术细节和踩坑过程都记下来了，主要聊了下面这几块东西（长文都在 blog.ashesborn.cloud/category/AI）：
1. 搞懂 GraphRAG 最核心的“社区（ Community ）”到底是个啥
很多人第一眼看 GraphRAG 觉得玄乎，其实核心就是把非结构化文本抽成实体、关系和 claim 之后，通过图算法（比如 Leiden 算法）去算聚类。
博客里详细推导了层级社区（从顶层粗粒度到底层细粒度）是怎么划分的，以及为什么一定要给每个社区生成摘要（ Community Summary ）。有了这些按主题聚类的摘要，回答“全局大纲总结”类的问题时，直接在摘要层做 Map-Reduce 就行了，不用一股脑把几万字全塞给模型。
2. PostgreSQL + TypeScript 的落地与表结构设计
不依赖图数据库（ Neo4j 之类），直接用日常最熟悉的 PostgreSQL + pgvector 怎么搞？
在设计篇里我把底层的 DDL 表结构、边的权重计算、实体消歧去重，以及在 Node.js 环境下怎么调用 WASM 版本的 igraph 做社区聚类都理了一遍。对已经在使用 Prisma / Postgres 的技术栈来说，接入成本会低很多。
3. 检索阶段的设计：意图解析、多路召回与打分融合
索引建好之后，怎么查更准？
实际实现里单纯靠向量还是会漏精准词，博客里分享了我们在检索阶段的完整链路：先做 query 意图抽取，再走“向量召回 + 关键词匹配 + 图邻居扩散”三路并发，用 RRF （ Reciprocal Rank Fusion ）做倒数排名融合，最后结合实体重叠率和社区层级打分，挑出最紧凑的证据集再喂给 LLM 出答案。
4. 多文件分块与增量更新处理
真实项目里文档格式五花八门（ Markdown 、TXT 、JSON 等）。这部分记录了跨文档分块策略、基于语义和句界的切片边界，以及后续新文档进来时怎么做增量索引与实体去重，避免全量重建图谱爆炸。
博客与开源项目
上面这些环节的详细技术推导、表结构定义和算法细节，我都系统整理在个人博客的 AI 分类下了，欢迎感兴趣的 V 友围观：
👉 博客技术文章列表：https://blog.ashesborn.cloud/category/AI
代码也已经开源并发布了 npm 包（包名 @ashes_born/graph-rag-ts，支持 Markdown 解析、Leiden 社区划分、混合召回与证据问答）：
👉 GitHub 仓库：https://github.com/sadofriod/graphrag-ts
