•2025年10月
ai-systems

工程化 LLM 链式调用实现 AI_NovelGenerator 多章节小说生成：上下文连续性与检索增强提示优化

基于 AI_NovelGenerator 工具，工程化 LLM 链式生成多章节小说，确保情节连续、伏笔衔接和角色一致，通过上下文窗口管理和 RAG 提示。

在自动化小说生成领域，工程化 LLM（大型语言模型）链式调用已成为关键技术，能够实现多章节长篇小说的连续生成，而 AI_NovelGenerator 工具正是这一理念的典型实践。通过将 LLM 的生成能力与检索增强生成（RAG）机制相结合，该工具有效解决了长文本创作中常见的上下文丢失、情节不连贯和角色发展不一致等问题。这种方法的核心在于动态管理上下文窗口，并利用向量嵌入检索前文关键信息，确保每章生成时都能继承上一章的叙事脉络，从而构建出逻辑严谨、伏笔合理的完整故事框架。

LLM 链式调用的本质是将小说生成分解为多个阶段性任务，每个任务依赖前一阶段的输出，形成一个闭环流程。在 AI_NovelGenerator 中，这一链式过程首先从小说设定开始，包括世界观架构、角色定义和整体剧情蓝图。随后，系统生成章节目录，每章标题和简要提示基于全局设定。随后进入核心生成阶段：为每一章创建草稿时，系统会调用 LLM 生成大纲和正文草稿。在此，上下文连续性是关键挑战。传统 LLM 的上下文窗口有限，例如 GPT-4o-mini 的窗口约为 128K tokens，对于多章节小说（假设 120 章，每章 4000 字），累计上下文可能远超此限。AI_NovelGenerator 通过 RAG 机制巧妙规避这一限制：它使用嵌入模型（如 text-embedding-ada-002）将前文章节、角色状态和剧情要点向量化存储在本地向量数据库中。生成新章时，系统检索最相关的 K 个片段（默认 K=4），将这些片段注入提示中，与当前章节目录和用户指导结合，形成增强提示。这不仅节省了 tokens 消耗，还提升了生成的相关性和一致性。例如，在生成第 N 章时，提示模板可能包括：“基于以下前文关键摘要：[检索结果]，继续发展情节，确保角色 [角色名] 的行为符合其在第 M 章的设定。”这种 RAG 增强确保了伏笔的自然回收和人物弧光的连续发展。

证据显示，这种链式 + RAG 的组合在实践中显著提高了输出质量。工具的 consistency_checker.py 模块进一步强化这一机制，通过语义相似度计算检测新生成章节与全局状态的冲突，例如角色年龄不符或事件因果倒置。如果检测到问题，系统会输出日志提示，用户可据此迭代提示。GitHub 仓库中记录的配置示例也证实了其工程化设计：temperature 设置为 0.7 以平衡创意与一致性，max_tokens 限定在 4096 以控制输出长度，避免无关枝节。embedding_retrieval_k=4 的选择基于经验，确保检索信息精炼而不冗长。此外，工具维护多个状态文件，如 global_summary.txt（全局剧情摘要）、character_state.txt（角色发展轨迹）和 plot_arcs.txt（伏笔管理），这些文件在每章定稿后自动更新，并被嵌入模型向量化，支持跨章节检索。这形成了证据闭环：RAG 检索这些状态，确保链式生成的连续性。

要落地这一技术，需要精确的参数配置和操作清单。首先，在 config.json 中定义 LLM 接口：api_key 为 OpenAI 或 DeepSeek 的密钥，base_url 如 “https://api.openai.com/v1”，model_name 选 gpt-4o-mini 以兼顾成本与性能。对于本地部署，可切换至 Ollama，base_url 为 “http://localhost:11434/v1”，model_name 如 llama3.1。温度参数 temperature=0.7 是推荐起点，低值（如 0.5）增强一致性，高值（如 0.9）注入更多创意，但需监控伏笔漂移。max_tokens=4096 适合单章生成，超过时可分段调用。嵌入侧，embedding_model_name=text-embedding-ada-002，embedding_retrieval_k=4，确保检索 top-4 最相关片段。小说参数包括 topic（如“星穹铁道主角穿越原神世界”）、genre=“玄幻”、num_chapters=120、word_number=4000，这些指导初始提示生成。

落地清单如下：

  1. 环境搭建：安装 Python 3.10+，pip install -r requirements.txt（包含 openai, chromadb 等）。启动 Ollama 服务（若本地）：ollama serve && ollama pull nomic-embed-text。

  2. 初始配置：编辑 config.json，填入 API 密钥，设置 filepath 为输出目录（如 D:/AI_NovelGenerator/output）。清空 vectorstore 目录以初始化数据库。

  3. 设定生成：运行 main.py，输入 theme/genre/chapters，点击 “Step1. 生成设定”，审阅并编辑 Novel_setting.txt（确保角色一致，如主角年龄固定）。

  4. 目录规划：点击 “Step2. 生成目录”，输出 Novel_directory.txt。手动调整章节提示以植入伏笔，例如第 1 章提示“引入神秘 artifact，第 10 章回收”。

  5. 章节链式生成：对于每章，设置章节号，在 “本章指导” 输入自定义提示（如“强调角色情感冲突”）。点击 “Step3. 生成章节草稿”，系统自动 RAG 注入前文。审阅 outline_X.txt 和 chapter_X.txt，编辑不一致处。

  6. 定稿与更新：点击 “Step4. 定稿当前章节”，系统更新状态文件和向量库。运行 “一致性审校” 检查冲突，若有，调整提示重生成。

  7. 迭代优化：监控日志，若 API 超时（常见 504 错误），增加重试机制（utils.py 中添加 retry=3）。对于长篇，定期手动合并摘要以压缩向量库。

  8. 输出管理：所有章节定稿后，汇总为完整小说。建议每 10 章后全书审校，使用外部工具如 Grammarly 检查语法。

这一清单确保了从零到完整的工程化流程，适用于开发者或创作者扩展工具。

尽管高效，这种方法仍存在风险。首先，上下文窗口限制虽经 RAG 缓解，但检索偏差可能导致“幻觉”延续，例如错误回收伏笔。为此，监控点包括：日志中相似度阈值 >0.8（在 consistency_checker.py 自定义），若低于则人工干预。其次，API 依赖性强，本地 Ollama 可作为回滚，但模型质量不如云端 GPT-4。优化策略：混合使用，云端生成关键章节，本地处理草稿；引入多模型链，如 Claude-3 审校 GPT 输出。参数阈值：若 temperature >0.8，强制 K=6 增强检索以防创意过剩。最后，回滚策略：每章生成前备份状态文件，若冲突率 >20%，回退至上版摘要重启链式。

总之，通过 AI_NovelGenerator 的 LLM 链式与 RAG 集成，多章节小说生成从手工转向自动化，显著提升效率与质量。实践者可据此参数快速部署，创作出引人入胜的长篇作品。（字数：1256）