DramaClaw功能详解①小说解析与故事图谱——角色、关系、时间线是怎么建出来的【免费下载链接】dramaclawA general-purpose AIGC video engine: script to finished film in one pipeline — dramas, ads, product videos, otome games, and more. | 通用 AIGC 视频引擎 —— 从剧本到成片一条流水线漫剧、广告、电商、乙游皆可项目地址: https://gitcode.com/gh_mirrors/dr/dramaclawDramaClaw 是一款通用 AIGC 视频引擎它的核心能力之一就是把一部小说自动解析成结构化的故事图谱角色表、人物关系、事件时间线都建在解析阶段就准备好后续的分集规划、角色定妆、分镜生成全部建立在这份故事骨架之上。本文带你从源码角度看清这套 小说解析 与 知识图谱 构建机制是怎么工作的。官方文档把这个流程画得很清楚整个引擎分INGEST摄取→ PLAN规划→ PRODUCE生产→ DELIVER交付四大段。其中第 3 步 Parse ingest解析导入和第 5 步 Extract characters抽取角色就是本文的主角。更完整的系统架构可以看官方文档 docs/zh/concepts/architecture.md。 第一步导入小说先做确定性切分很多 AI 视频工具的通病是把整本小说一股脑丢给大模型又慢又不稳。DramaClaw 的做法完全不同绝不让模型一次性吞下全书。在 src/novelvideo/story_analysis.py 中引擎会沿着文本自己已有的边界来切分剧本格式按场景头切小说格式按章节标记切找不到标记时退化为 6000 字符的固定窗口保留 200 字重叠切完还要做两件事拆大块单章太长就继续切合并小块连续短片段打包到 3000 字左右——因为一次模型调用不管传 300 字还是 3000 字耗时都差不多打包能显著省时间更关键的是每个片段都记录自己在原文中的字符偏移量。这个看似不起眼的细节是后面防编造机制的根基。导入阶段的核心逻辑在 src/novelvideo/structured_ingest.py校验上传 → 持久化原文 → 记录一份确定性的分析计划chunk 计划。如果同一份原文重新导入已完成的分析结果会直接复用不用重新烧 token。️ 第二步角色提取——模型必须引用原文作证角色是怎么找出来的核心实现在 src/novelvideo/structured_extraction.py。这里有一套非常有意思的证据验证机制模型只允许根据当前片段判断不许推测片段之外的信息每个被提取的角色必须附带至少一条evidence.quote——一句逐字来自原文的引文引文在该片段的原文中找不到候选直接丢弃原文里从未出现过的名字直接丢弃 一句话总结模型没有把编造的角色送进角色表的任何路径。除了防编造还有一整套保守合并规则处理同一个人在书里叫很多名字的问题场景处理方式林默又名小默这类原文明确的别名✅ 自动合并校长吴显德 / 吴显德这类头衔姓名✅ 合并TITLE_TOKENS 白名单母亲、医生、少爷这类泛称❌ 永不合并两章里的母亲可能是两个不同的人拿不准的两个名字❌ 宁可不合并分别保留这个设计背后是一个很朴素的判断角色名同时是数据库主键、接口标识符、素材目录名合并错了很难改拆分错了很容易改所以规则只合并文本里明说的模棱两可的宁可留两个候选最后再交给一次裁决调用确认。角色构建的完整编排逻辑含断点续跑、复用缓存在 src/novelvideo/structured_builders.py。️ 第三步关系与时间线——知识图谱双轨制DramaClaw 内部有两条长期并存的解析轨道选择逻辑在 src/novelvideo/knowledge_pipeline.py轨道一cognee_legacy知识图谱轨老项目走这条轨道。原文由 Cognee 构建知识图谱角色、剧集、场景、道具等数据落 SQLite。图谱里存的不只是谁是谁还包括关系变化两个人物之间的攻防关系如何随剧情演变事件时间线带地点、时间标记、参与角色、因果链的事件序列事件提取器在 src/novelvideo/cognee/event_extractor.py每个事件被定义为一个完整的叙事单位一次对话、一个场景、一个动作序列并标注地点、时间标记和前置事件的因果关系。分集规划的智能体src/novelvideo/agents/episode_planner.py会调用一组图谱检索工具来规划剧集比如按时间搜事件、搜主要角色间的关系变化、搜章节摘要——时间线和关系数据正是从这里被消费掉的。轨道二structured_v1结构化抽取轨新项目的默认轨道确定性、直接从原文抽进 SQLite不经过嵌入模型、不建向量索引、不查图谱。角色在整部作品范围内发现剧本格式的场景靠场景头一次性发现解说剧的场景则在分集规划时按需生成。两条轨道在项目创建时选定、终身不迁移——这是官方写明的架构约束保证老项目的行为永不变化。 图谱不是黑盒可视化预览建出来的图谱能不能直接看到能。前端有专门的图谱可视化组件 frontend/src/components/ingest/KnowledgeGraphVisualization.tsx导入完成后在页面上直接看到节点和关系后端为 API 准备了持久化的有界预览src/novelvideo/graph_preview.py图谱构建成功后物化一份graph-preview.json侧车文件前端渲染时不必去打开重量级的图谱数据库这样角色、关系、时间线对用户来说是完全透明的哪里抽错了能看见也方便人工介入修正。 小结这套机制对新手意味着什么你关心的问题DramaClaw 的答案AI 会不会编造不存在的角色不会——每个角色必须有原文逐字引文作证校长和李校长会被当成两人吗会按规则合并泛称则保持独立候选十万字的小说会不会一次塞爆模型不会——按场景/章节确定性切分 小块打包分析中断了要重跑吗不用——每个片段的完成状态都有记录可断点续跑时间线和关系数据存哪图谱轨存 Cognee 知识图谱结构轨直接进 SQLite可以说从小说到成片这条流水线能不能跑得稳七分靠的就是这个解析地基。下一篇我们接着看 PLAN 阶段分集规划、角色定妆照Character portraits和身份方案是怎么基于这份故事骨架生成出来的。延伸阅读完整架构说明docs/zh/concepts/architecture.md功能特性总览docs/zh/concepts/features.md快速上手docs/zh/getting-started/quickstart.md结构化抽取源码src/novelvideo/structured_extraction.py知识图谱管道源码src/novelvideo/cognee/【免费下载链接】dramaclawA general-purpose AIGC video engine: script to finished film in one pipeline — dramas, ads, product videos, otome games, and more. | 通用 AIGC 视频引擎 —— 从剧本到成片一条流水线漫剧、广告、电商、乙游皆可项目地址: https://gitcode.com/gh_mirrors/dr/dramaclaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考