edgequake

想象你手里有一份上百页的技术报告，当被问到"这份报告中提到的所有AI技术之间的关联是什么"时，传统RAG只能给出零散的片段答案。而 EdgeQuake 能告诉你：这整份报告的实体关系图谱中，核心实体是哪些、它们之间通过什么关系连接、某一类实体在整份文档中呈现什么样的主题分布。这不是简单的关键词匹配，而是对文档深层次结构认知后的推理回答。

项目起源：从 Python 困境到 Rust 重写

EdgeQuake 的诞生直接源于一个现实痛点：作者 raphaelmansuy 在使用 LightRAG（Python 版 GraphRAG 实现）处理大规模文档时，遭遇了性能瓶颈。LightRAG 基于 NetworkX 的图数据结构在内存占用和查询延迟上都无法满足生产级需求，而 Python 的 GIL 限制也使得并行处理实体抽取难以发挥多核优势。

于是作者做了一个大胆的决定：用 Rust 重写整个框架。这个选择带来的收益是量化的——查询延迟从 ~1000ms 降低到 <200ms，内存占用从每文档 ~8MB 降低到 ~2MB，并发用户支持从 ~100 提升到 1000+。这套 Rust 实现最初受到 LightRAG 论文（arXiv:2410.05779）的启发，但在索引算法和存储后端上做了大量改进，目前版本已演进到 0.12.x，功能远超原始论文描述。

从 GitHub 趋势数据来看，该项目呈现持续上升势头，growth_trend_score 达到 2.75，属于 AI 基础设施赛道中难得的"性能型"选手。

核心技术：知识图谱 + 混合检索

EdgeQuake 的核心创新在于文档向量化与知识图谱双轨并行的检索架构。传统 RAG 将文档切成块（chunk），每个块生成向量 embedding，查询时做相似度匹配。这种方式对于"查找包含X关键词的段落"效果不错，但一旦问题涉及实体之间的关系、多跳推理（如"A和B通过什么关联"）或主题归纳，传统RAG就会力不从心——因为向量相似度无法捕捉语义结构。

EdgeQuake 的解决思路来自 LightRAG 论文的洞察：在文档索引阶段，让 LLM 充当"结构化信息提取器"。具体流程是：

文档处理管道（索引阶段）：

1. Chunk 切分：将文档按 ~1200 token 切分，块之间有 100 token 重叠，保证上下文连续性
2. LLM 实体抽取：对每个 chunk 调用 LLM，提取 (实体名, 实体类型, 描述) 三元组，以及 (源实体, 目标实体, 关系关键词, 描述) 关系元组
3. Gleaning（多轮提取）：可选的第二轮抽取专门用于捕捉遗漏实体，测试显示可提升 ~18% 的召回率
4. 实体归一化：大小写归一化 + 描述合并，将重复实体减少约 36-40%
5. 图存储：实体写入 Apache AGE（图数据库），向量写入 pgvector，块文本存入 PostgreSQL

查询阶段支持 6 种模式：

• Naive：纯向量相似度，最快（100-300ms），适合简单关键词查询
• Local：找到相关实体后，遍历其在图中的局部邻域，适合查询特定关系
• Global：通过 Louvain 社区检测找到主题聚类，获取社区摘要，适合归纳性问题
• Hybrid（默认）：结合 Local + Global，平衡精确度与全面性（400-1000ms）
• Mix：向量结果与图增强结果按比例加权混合
• Bypass：跳过检索，直接向 LLM 提问

这套架构的精妙之处在于：索引阶段的图结构提取是一次性的，但图结构可以在任意查询模式下被复用。查询越复杂，图结构的价值越显著。

架构设计：11 个 Rust Crate 的模块化工程

EdgeQuake 不是一个人写到底的单体应用，而是一个精心拆分的 Rust workspace，包含 11 个核心 crate：

Crate	职责
edgequake-core	核心协调和管道编排
edgequake-llm	多 LLM 提供者抽象（OpenAI、Claude、MiniMax、Ollama、Mistral）
edgequake-storage	PostgreSQL AGE + pgvector 存储后端
edgequake-api	Axum 框架 REST API 服务
edgequake-pipeline	文档摄取处理管道
edgequake-query	6 种查询模式引擎
edgequake-pdf	PDF 提取（text 模式和 vision 多模态模式）
edgequake-auth	认证授权
edgequake-audit	合规审计日志
edgequake-tasks	后台任务队列
edgequake-rate-limiter	限流中间件

后端基于 Tokio 异步运行时和 Axum Web 框架，前端使用 React 19 + TypeScript + Shadcn/ui，图可视化采用 Sigma.js。数据库层面，PostgreSQL 15+ 通过 Apache AGE 扩展支持属性图模型，pgvector 扩展提供 HNSW 向量索引。

API 层遵循 OpenAPI 3.0 规范，完整 Swagger 文档在 /swagger-ui，支持 SSE 流式响应（token-by-token 逐字显示），以及 Kubernetes 友好的健康检查端点（/health、/ready、/live）。

LLM 提供者支持：OpenAI (GPT-4o)、Anthropic (Claude)、Mistral、MiniMax、Ollama（本地）、LM Studio、xAI (Grok)、Gemini，覆盖了主流商业模型和开源本地模型，通过环境变量自动检测。

PDF 处理：多模态 AI 读取"图片型"文档

v0.4.0 引入的 PDF 处理能力是 EdgeQuake 的一大亮点。传统 PDF 文本提取在遇到扫描件、复杂表格、多栏排版时几乎束手无策。EdgeQuake 采用了双轨策略：

• Text 模式（默认）：使用嵌入式 pdfium 引擎，无需外部依赖，适合标准文本 PDF
• Vision 模式：将每一页 PDF 渲染为图片，发送给 GPT-4o、Claude 3.5+ 或 Gemini 2.5，让多模态 LLM"看"懂页面内容——这使得扫描件、复杂表格、多栏排版文档都能被正确解析

Vision 模式支持自动降级（API 调用失败时回退到 text 提取），以及对大文件的内存保护机制（自适应 DPI 和并发限制）。

部署体验：30 秒一键启动

EdgeQuake 的部署体验在同类项目中属于顶级水准。无需安装 Rust 工具链，无需 Node.js 编译前端，一条命令即可拉起完整三件套：

curl -fsSL https://raw.githubusercontent.com/raphaelmansuy/edgequake/edgequake-main/quickstart.sh | sh

该脚本会交互式引导：选择 LLM 提供者（OpenAI/Ollama）、选择模型、验证 API key、拉取镜像、启动服务，最长等待 90 秒即可完成。

通过 docker-compose.quickstart.yml，自动启动三个容器：

• edgequake API（端口 8080）：REST + SSE 流式
• edgequake-frontend（端口 3000）：Next.js Web UI
• PostgreSQL 15（AGE + pgvector 扩展）：图 + 向量存储

所有镜像通过 GitHub Actions CI/CD 在每次 Release Tag 时自动构建并发布到 GHCR，支持 linux/amd64 和 linux/arm64（Apple Silicon 原生支持，无需 QEMU 模拟）。

本地开发模式（make dev）需要 Rust + Node.js 环境，适合深度定制开发。

亮点功能：知识注入与自定义实体类型

v0.8.0 引入的**知识注入（Knowledge Injection）**功能让 EdgeQuake 超越了普通 RAG 的能力边界。用户可以上传专业术语词典（如"OEE=Overall Equipment Effectiveness，设备综合效率"），系统自动将其注入知识图谱，并在查询时通过同义词扩展提升检索覆盖率。注入的术语可以作为图谱节点参与推理，但不会出现在最终答案的引用来源中——真正做到了"知识融入"而非"答案污染"。

v0.9.0 的自定义实体类型功能支持在创建 workspace 时从 6 个预设模板（General、Manufacturing、Healthcare、Legal、Research、Finance）中选择，并可额外配置最多 50 个自定义 UPPERCASE_UNDERSCORED 实体类型。这意味着在法律场景中可以定义 CONTRACT_PARTY、LEGAL_CITATION 等领域实体，医疗场景可以定义 DRUG_INTERACTION、DIAGNOSIS_CODE，实体识别精度大幅提升。

多语言 SDK 与 MCP 集成

EdgeQuake 提供了 Python、TypeScript、Rust、Go、C#、Java、Kotlin、PHP、Ruby、Swift 10 种语言的 SDK，降低了集成门槛。

更重要的是 MCP（Model Context Protocol）支持：EdgeQuake 实现了 MCP Server，AI Agent（如 Claude Desktop、Cursor）可以直接调用 EdgeQuake 的查询、上传、图谱探索能力。这意味着 EdgeQuake 不仅是一个 RAG 引擎，更是一个可以嵌入 AI Agent 工作流的知识图谱工具。

局限与注意事项

EdgeQuake 并非银弹，有几个实际使用时需要注意的点：

1. LLM 成本：每次文档索引都需要大量 LLM 调用（实体抽取 + 关系抽取 + gleaning），处理长文档成本不低。系统内置了成本追踪（cost tracking）功能，可以按操作维度监控 LLM 消耗。
2. PostgreSQL 依赖：必须依赖 PostgreSQL + AGE + pgvector 三合一环境，虽然 Docker compose 一键搞定，但轻量级场景（单机小数据量）显得过重。
3. 图可视化性能：Sigma.js 图可视化在实体数量超过数千时，浏览器端渲染可能出现卡顿，需要在后端做图采样或聚合。
4. 模型选择影响大：实体抽取质量直接决定图谱质量，GPT-4o 和 Claude 的抽取效果明显优于小型开源模型。

总结

EdgeQuake 是 GraphRAG 赛道中值得关注的基础设施级项目。它用 Rust 的性能优势解决了 Python GraphRAG 的核心痛点，将知识图谱构建、多模态文档理解、6 模式混合检索集成在一个生产可用的系统中。如果你需要处理大量文档的复杂问答场景、对检索质量要求较高、或希望将知识图谱能力嵌入 AI Agent 工作流，EdgeQuake 值得优先评估。Docker 一键部署的特性也极大降低了试用门槛。