把长篇小说整理成可解释、可导出、可供图谱前端消费的人物关系图谱。 📚
本地工作区驱动，逐章分析，最终导出 character_graph.json。 🕸️
适合把一本书从原始文本慢慢整理成一张能读、能查、也能展示的人物关系图谱。
在线演示
·
维护入口
·
导出契约
·
配套前端
Graph Every Novel 是一个面向长篇小说分析的本地桌面应用。
它的主链路很明确：导入小说文本，逐章抽取人物、事件、互动与关系线索，在本地持续累计状态，再导出一份适合图谱展示的 character_graph.json。这份导出文件不是单章结果的简单拼接，而是经过名称对齐、状态累计、量化和稳定图筛选之后留下来的最终图状态。
当前系统围绕工作区运行。一本书对应一个工作区，分析快照、SQLite 状态、导出文件和日志都保存在本地，便于持续分析、重复导出和事后排查。
(回到顶部)
以《红楼梦》为例，Graph Every Novel 可以把长篇小说整理成人物关系图谱，并导出供前端消费的图谱结果。
- 在线演示：https://renakoni.github.io/graph-every-novel/demo/红楼梦.html
- 仓库内示例页面：
assets/红楼梦.html - 配套前端仓库：https://github.com/Renakoni/novel-graph-viz
Graph Every Novel 当前可以：
- 导入 EPUB、TXT、JAR 小说文件
- 自动整理章节顺序
- 调用兼容 OpenAI 接口的大模型完成章节抽取
- 识别人、事件、互动与关系线索
- 在本地持续累计人物状态与关系状态
- 对人物重要度、双人关系支持度和图结构支持度进行量化
- 导出稳定的人物关系图谱 JSON
- 通过桌面 UI 完成导入、分析、浏览、导出与排查
如果只看单章，看到的是局部剧情；如果跑完整本书，再经过后续整理，得到的才是更适合展示和阅读的人物关系图谱。
(回到顶部)
如果已经下载发布版，直接运行安装版或便携版中的 Graph Every Novel.exe。
如果是在源码目录里直接运行，先安装依赖，再启动应用：
pip install -e .
python tools/run_project_ui.py启动后先创建一个新的工作区，或者打开一个已有工作区。
工作区会保存这本书的章节数据、累计状态、导出文件和日志。后续所有分析都围绕这个目录进行。
在应用里填写并保存模型配置。至少需要确认：
- base URL
- API Key
- model
保存后先做一次接口测试，再开始正式分析。
应用里的模型配置分成两部分：
- 主模型：负责章节抽取、人物与关系线索生成
- 关系裁决器：负责对仍然不稳定的双人共享关系做定点裁决
| 模型 | 适合场景 | 速度 | 人物覆盖倾向 | 说明 |
|---|---|---|---|---|
gemini-3.1-flash-lite-preview |
日常分析、快速试跑、低成本批量处理 | 很快 | 中等 | 默认推荐。速度优先时优先选它。 |
gemini-3-flash-preview |
想在速度和质量之间做更稳一点的平衡 | 快 | 中等偏高 | 比 lite 更重一些，适合常规整本分析。 |
doubao-seed-2-0-lite-260215 |
希望尽可能多保留人物、配角和龙套信息 | 中等 | 高 | 人物覆盖优先时推荐。适合想尽量少漏人的场景。 |
gpt-5.4-mini |
希望尽可能多保留人物，同时保持较稳的综合表现 | 中等 | 高 | 适合人物覆盖优先、同时希望结果更稳一些的场景。 |
- 速度优先：推荐
gemini-3.1-flash-lite-preview - 人物尽可能全：优先
doubao-seed-2-0-lite-260215和gpt-5.4-mini - 如果不想分开配两套模型，也可以主模型和关系裁决器直接使用同一个模型
以《红楼梦》120 章、约 858,628 个字符为例，使用 gemini-3.1-flash-lite-preview 的一次完整跑书，可粗略参考下面这组数据：
- 输入 token：
3,659,440 - 输出 token：
897,498 - 总 token：
4,556,938 - 估算成本：约
¥5.43（按doubao-seed-2-0-lite-260215官方≤32k档价格粗算，不计算缓存） - 总耗时：约
1 小时 45 分钟 - 单章耗时区间：约
19 秒到2 分 13 秒
这是一组便于估算的参考值。实际费用和耗时会受到单次请求长度、是否进入更高计价档位、是否启用关系裁决器，以及具体跑书策略影响。
- Gemini API 模型总览：https://ai.google.dev/gemini-api/docs/models
- 火山方舟快速入门：https://www.volcengine.com/docs/82379/1399008
- Doubao Seed 2.0 模型文档：https://www.volcengine.com/docs/6492/2250683
- Vertex AI 的 OpenAI 模型接入：https://docs.cloud.google.com/vertex-ai/generative-ai/docs/maas/openai
gpt-5.4-miniOpenRouter 模型页：https://openrouter.ai/openai/gpt-5.4-mini。同时也推荐通过 GCP 代理使用：https://github.com/router-for-me/CLIProxyAPI
如果你的服务商提供 OpenAI-compatible 接口，也可以直接把对应的 base URL、API Key 和 model 填进应用里使用。
当前支持导入：
- EPUB
- TXT
- JAR
导入后，Graph Every Novel 会整理章节顺序，并允许继续检查章节、重命名章节、拆分章节或合并章节。
可以按需要：
- 只分析单章
- 分析整本书
分析过程中，系统会逐章抽取人物、事件、互动与关系，并把累计状态持续写回工作区。
分析完成后，最重要的导出文件是：
<workspace>/export/character_graph.json
如果还需要做兼容调试或检查更宽的项目导出，也可以查看：
<workspace>/export/project.json
把下面这个文件交给配套图谱前端：
<workspace>/export/character_graph.json
Graph Every Novel 负责：
- 导入小说文本
- 运行章节分析
- 维护本地累计状态
- 量化人物与关系
- 导出图谱结果
- 提供日志与诊断入口
配套前端负责：
- 图谱展示
- 交互浏览
- 人物与关系的可视化探索
配套前端仓库： https://github.com/Renakoni/novel-graph-viz
当前两边的主交付边界是：
<workspace>/export/character_graph.json
这意味着：
- Graph Every Novel 要对这份导出的结构和语义负责
- 配套前端应该消费这份导出，而不是直接依赖工作区内部状态
<workspace>/export/project.json是兼容型项目导出，不是当前图谱前端的主输入
如果后续要调整协议，应该优先从这条边界讨论，而不是先改前端展示再倒推导出语义。
(回到顶部)
一个典型工作区通常会包含这些关键结果：
<workspace>/
analysis/ # 章节分析快照
state/analysis.sqlite # 本地状态与累计记忆
export/project.json # 兼容型项目导出
export/character_graph.json # 配套前端直接输入
logs/ # 调试与诊断日志
其中最重要的是：
这是当前推荐的图谱导出文件，主要包含：
- 人物节点
- 有向关系边
- 双人关系边
- 导出增强层的新鲜度状态
- 稳定图筛选后的最终结果
这是兼容型导出，保留的信息更宽，适合调试、检查或后续协议扩展。
(回到顶部)
Graph Every Novel 不会把某一章里的一次模型输出原样交给前端。
长篇小说的关系结构天然是累计出来的。人物会反复出现，称呼会变化，关系会推进，某一章里很强的一次互动，放回整本书里未必还是稳定结构。真正需要保留下来的，不是单章瞬时判断，而是跨章节、跨上下文、还能站得住的结果。
所以主链路在章节抽取之后，还会继续做这些事：
- 对齐名称和别名
- 把多章信息累计到本地状态
- 对人物重要度做量化
- 对双人关系和图结构做支持度计算
- 在导出前做稳定图筛选
这样导出的结果更适合拿来做整本书视角的人物关系图谱，而不是章节级的临时快照。
(回到顶部)
如果要排查某一章为什么抽取不理想，优先看：
<workspace>/logs/diagnostic/latest_chapter_diagnostic.json
如果要查看完整原始请求与响应，优先看：
<workspace>/logs/ai_raw/
<workspace>/logs/ai_debug.jsonl
如果要做跨会话问题复盘，优先看：
<workspace>/logs/exports/bundles/debug_bundle_<timestamp>.zip
(回到顶部)
Graph Every Novel 当前主要建立在这些组件之上：
- Python 3.11
- Flet 桌面 UI
- SQLite 本地状态存储
- Pydantic 数据模型与导出 schema
- NetworkX 图结构计算
- OpenAI-compatible LLM API
这些技术栈对应的是当前产品形态：本地桌面应用、本地工作区、模型驱动抽取、本地累计状态，以及面向图谱前端的稳定导出。
(回到顶部)
如果想继续了解 Graph Every Novel 的链路、量化和导出契约，建议从这些文档开始：
(回到顶部)
本项目采用 MIT License。
许可证全文见：LICENSE
MIT 是宽松许可证。保留版权声明和许可证文本的前提下，可以复制、修改、分发和商用。
(回到顶部)
Graph Every Novel 的量化设计、图结构判断、导出组织和部分工程实现，参考了下列理论工作、开源项目与设计启发。
- 人物重要度：Page, Lawrence; Brin, Sergey; Motwani, Rajeev; Winograd, Terry. The PageRank Citation Ranking: Bringing Order to the Web. 1999.
- 近期出场分与关系衰减：Ebbinghaus, Hermann. Über das Gedächtnis. 1885；Rutherford, Ernest; Soddy, Frederick. "The Cause and Nature of Radioactivity." 1902.
- 分数整理：Tukey, John W. Exploratory Data Analysis. 1977.
- 图结构支持：Jaccard, Paul. 1901；Adamic, Lada A.; Adar, Eytan. 2003；Zhou, Tao; Lü, Linyuan; Zhang, Yi-Cheng. 2009；Barabási, Albert-László; Albert, Réka. 1999.
- 多证据融合与重排序：Manning, Christopher D.; Raghavan, Prabhakar; Schütze, Hinrich. Introduction to Information Retrieval. 2008.
- 双向不对称关系建模启发：IEEE Xplore Document 11195182。
- claude-code-best/claude-code 的分层结构设计。
- 类脑社区 XXX 大佬的 SP·数据库
@10.1版本填表格式设计。
- RT15548/LittleWhiteBox
- B 站视频：[魔禁]我做了个魔法禁书目录人物关系图谱 https://www.bilibili.com/video/BV138QzBoEWx/?spm_id_from=333.1007.top_right_bar_window_default_collection.content.click&vd_source=484d2aae3b201d64e298d83159ed39c7
(回到顶部)