基于LLM的长文本生成工程实践：分治策略与向量记忆系统

1. 项目概述与核心价值最近在折腾AI内容生成的朋友可能都遇到过这样一个痛点让大模型写个几百字的短文、邮件或者代码片段效果还不错但一旦让它生成上万字甚至几十万字的长篇内容比如小说、剧本、报告或者系列教程结果往往就“崩”了。要么是写到后面人物性格突变、情节前后矛盾要么是世界观设定混乱甚至直接开始胡言乱语重复啰嗦。这背后的核心问题就是大语言模型LLM普遍存在的“上下文窗口”限制和“长程依赖”能力不足。今天要聊的这个项目MaoXiaoYuZ/Long-Novel-GPT就是针对这个“长篇内容生成”难题的一个非常精巧的工程化解决方案。它不是一个全新的底层模型而是一个基于现有强大模型如GPT系列构建的“脚手架”或“工作流引擎”。简单来说它的核心思想是“化整为零分而治之”。你不是要写一部30万字的小说吗直接扔给GPT一个30万字的生成指令它肯定办不到。但如果你把任务拆解成先写一个5000字的大纲然后根据大纲把小说分成30个章节接着为每个章节生成详细的情节梗概最后再逐段、逐场景地填充具体内容并在每一步都让模型“回顾”之前的关键信息如人物设定、核心矛盾、伏笔那么生成一部结构完整、逻辑自洽的长篇作品就成为了可能。这个项目的价值远不止于“写小说”。任何需要长文本、强逻辑、多步骤连贯输出的场景比如撰写长篇行业分析报告、创作系列视频脚本、开发大型项目的技术文档、甚至是进行多轮深度对话的AI角色扮演都可以从这个项目的设计思路中汲取灵感。它本质上是一套管理复杂AI生成任务状态、维护长期记忆、并实现可控、高质量输出的方法论和工具集。对于内容创作者、产品经理、AI应用开发者来说理解并掌握这套方法意味着你能将大模型的潜力从“段落级”释放到“作品级”真正用AI来辅助完成那些有深度、有规模的创造性工作。2. 核心架构与工作流设计2.1 分治策略如何“切割”一个宏大的创作任务Long-Novel-GPT的核心在于其任务分解策略。这听起来简单但做起来需要非常精细的设计。你不能简单地把10万字平均切成100份每份1000字让模型去写。那样生成的内容必然是割裂的。2.1.1 层级式任务分解项目采用了一种典型的“自上而下逐层细化”的分解方法顶层设计Outline首先引导模型生成一个高度概括的故事大纲。这个大纲通常只有几百到一千字但必须明确故事的核心主题、主要人物、故事发生的世界背景、以及起承转合的主要阶段如开端、发展、高潮、结局。这一步的关键是“定调”和“定框”为后续所有创作划定边界。章节规划Chapter Planning基于大纲将故事分解为若干个逻辑章节。每个章节需要定义其核心目标例如引入反派、制造第一个冲突、揭示关键线索、发生的主要场景、以及需要推进的人物关系。这一步的输出是一个章节列表每个章节附带一段简要描述。场景/段落细化Scene/Paragraph Detailing针对每一个章节进一步分解为更小的创作单元比如一个个具体的场景例如“咖啡馆初遇”、“实验室爆炸逃亡”。为每个场景定义POV视点人物、核心冲突、情感基调、以及必须出现的关键信息如某个伏笔的揭示。内容生成Content Generation最后才是针对每个最小的场景或段落生成具体的叙述性文字、对话和描写。这是模型最擅长的“填空”工作。2.1.2 状态管理与上下文传递分解只是第一步更关键的是如何在生成后续内容时让模型“记住”之前的所有重要设定。这就是项目的状态管理模块。它通常会维护一个动态的“上下文摘要”或“关键信息库”包括人物档案姓名、外貌、性格、背景、目标、与其他角色的关系、以及截至当前章节的成长与变化。世界观设定重要的地点、组织、规则魔法、科技、历史事件等。情节线索与伏笔已经埋下的伏笔、待解决的悬念、未兑现的承诺。当前章节摘要刚刚写完的内容的简短总结确保下一段能无缝衔接。在生成每一个新的小段落时系统不会把之前所有的文本都塞进模型的上下文窗口那会很快耗尽额度而是智能地从这个“信息库”中提取与当前场景最相关的部分作为“前情提要”或“创作指引”提供给模型。这就像是一个尽职的编剧助理在作者写每一场戏之前都把相关的角色卡和剧情笔记递过来。2.2 提示工程驱动模型进行“结构化思考”有了好的任务分解和状态管理还需要通过精心设计的提示词Prompt来引导模型按照我们的预期工作。Long-Novel-GPT的提示工程是其灵魂所在。2.2.1 系统提示词System Prompt的设定系统提示词定义了模型的“角色”和“行为准则”。对于长篇小说生成一个强大的系统提示词可能如下所示你是一位专业的畅销小说作家擅长创作结构严谨、人物生动、情节引人入胜的长篇故事。你遵循以下核心创作原则 1. 一致性优先所有产出必须严格遵循已设定的人物性格、世界观规则和情节逻辑不得出现前后矛盾。 2. 展示而非讲述多用具体的动作、对话和环境描写来展现情节和人物情感避免大段的抽象叙述。 3. 节奏控制在紧张的情节中加快叙事节奏在情感或铺垫场景中适当放缓张弛有度。 4. 伏笔管理你有责任记住并适时回收之前埋下的所有伏笔。这个系统提示词为模型奠定了专业的创作基调和不可违背的规则。2.2.2 分步骤的用户提示词User Prompt针对任务分解的每一个层级都需要设计特定的用户提示词。例如在“章节规划”阶段提示词可能是基于以下故事大纲和我们已经完成的前三章请规划接下来的两章第四章和第五章。 【故事大纲】此处插入大纲 【已完成章节摘要】此处插入前三章摘要 【关键人物状态】此处插入最新人物档案 请为每一章提供 1. 章节标题暂定 2. 本章核心目标1-2句话 3. 主要场景列表每个场景注明地点、参与人物、核心事件 4. 本章需要埋下的新伏笔或需要回收的旧伏笔如果有。 请确保新章节能自然承接上文并推动主线情节向大纲中的“发展”阶段迈进。而在最终的“内容生成”阶段提示词则会非常具体现在开始撰写【第四章 - 第二场景深夜图书馆的密谈】的具体内容。 【场景概要】主角张三在图书馆闭馆后潜入寻找一本古籍却意外遇见了神秘的管理员李四。李四似乎知道张三的目的并暗示古籍中藏有更大的秘密。 【参与人物】张三好奇、谨慎、李四神秘、博学、略带警告语气 【情感基调】悬疑、紧张、带有信息揭示的震撼。 【前情衔接】上一场景中张三从导师那里得知了古籍的线索。 【必须包含的元素】 - 对图书馆深夜环境的细致描写突出寂静和压迫感。 - 张三寻找古籍的具体动作和心理活动。 - 李四的突然出现方式及其非典型的对话风格。 - 对话中必须暗示“古老的封印正在松动”这一核心设定。 - 场景结束时李四交给张三一把古老的铜钥匙。 请生成约800字的叙事段落重点描写对话和氛围。这种高度结构化的提示将开放的创作任务转变为了一个“条件作文”极大地提高了输出的可控性和质量。3. 关键技术实现与工具链3.1 模型选择与API调用策略Long-Novel-GPT项目通常不限定于某一个模型但其设计对模型能力有明确要求。3.1.1 模型能力要求强大的指令遵循能力必须能精确理解并执行复杂、多层次的提示词指令。优秀的角色扮演与风格一致性能在长篇生成中保持统一的叙事口吻和人物 voice。足够长的上下文窗口虽然项目通过分治策略降低了单次请求的上下文长度要求但模型自身拥有8K、16K、32K甚至更长的上下文窗口意味着单次能处理更复杂的“信息库”和更长的“前情提要”效果会更好。稳定的输出在温度Temperature等参数设置下输出应相对稳定避免过于天马行空偏离主线。因此像 GPT-4、Claude 3 系列等顶尖模型是首选。对于一些对成本更敏感或需要本地部署的场景开源的 Llama 3 70B、Qwen 2.5 72B 等模型在经过特定微调后也能胜任部分工作。3.1.2 智能的API调用与成本控制长篇生成意味着海量的API调用。一个成熟的实现必须考虑成本优化异步与批处理非顺序依赖的生成任务如为不同章节规划场景可以并行发起API请求大幅缩短总耗时。缓存机制对于“信息库”中不常变动的部分如固定的人物基础设定、世界观规则其对应的提示词片段和模型响应可以被缓存。下次需要相同信息时直接读取缓存避免重复计算和付费。输出长度控制在提示词中明确要求输出字数范围如“约500字”并设置API的max_tokens参数避免模型生成冗长无关的内容浪费token。模型分级使用并非所有步骤都需要最强大的模型。例如“内容生成”需要最强的创造力可能用GPT-4而“提取当前段落摘要”这种总结性任务用更便宜、更快的模型如GPT-3.5 Turbo可能就足够了。3.2 记忆系统与向量数据库的应用这是实现“长程依赖”和“状态管理”的技术核心。单纯靠提示词传递所有信息是不现实的。3.2.1 为什么需要向量数据库在生成第200个段落时系统需要知道第50个段落里埋下的一个关于配角身世的伏笔。我们不可能把前199个段落都放进提示词。这时就需要一个“记忆系统”来快速检索相关信息。向量数据库如 Pinecone, Weaviate, Qdrant或本地运行的 Chroma完美解决了这个问题。它的工作原理是嵌入Embedding将每一段生成的文本或从中提取的关键信息如“A人物在B地点对C说了D话”通过一个嵌入模型如 OpenAI 的text-embedding-3-small转换为一个高维度的向量一组数字。这个向量包含了这段文本的语义信息。存储与索引将这个向量和对应的原始文本或元数据如所属章节、人物、事件类型一起存入向量数据库。检索Retrieval当需要为当前场景寻找相关信息时将当前场景的描述或问题如“查找所有与‘古老封印’相关的对话”也转换为向量然后在向量数据库中搜索与之“语义最相似”的向量。相似度通常由余弦相似度等算法衡量。3.2.2 在项目中的具体工作流持续索引每当完成一个段落或场景的生成系统会自动提取其中的关键实体人物、地点、物品和事件生成一段摘要并将其转换为向量存入数据库。动态检索在开始生成一个新段落前系统根据当前场景的上下文构造一个检索查询例如“检索与‘主角张三’、‘恐惧情绪’、‘实验室’相关的所有过往片段”。向量数据库返回最相关的几个历史片段。上下文构建将这些检索到的历史片段与当前的人物状态、章节目标等信息一起组合成当前生成任务的“前情提要”或“创作指引”送入大模型的提示词中。这样模型在创作每一个新段落时都仿佛有一个完美的“记忆”能精准地呼应前文保持极强的一致性。这比单纯让模型“努力记住”要可靠和高效得多。3.3 项目结构与代码组织浅析虽然我们无法看到MaoXiaoYuZ/Long-Novel-GPT的全部源码但可以推断一个典型的工程化实现会包含以下模块long_novel_gpt/ ├── core/ │ ├── orchestrator.py # 总调度器控制整个“大纲-章节-场景-内容”的工作流 │ ├── state_manager.py # 状态管理维护人物、世界观、情节线索的“信息库” │ └── prompt_templates/ # 存放各个层级大纲、章节、场景的提示词模板 ├── memory/ │ ├── vector_store.py # 封装向量数据库的客户端操作存储、检索 │ ├── embedder.py # 调用嵌入模型生成向量 │ └── chunking_strategy.py # 定义如何将长文本切分成块以便索引按段落、按场景等 ├── generators/ │ ├── outline_generator.py # 大纲生成器 │ ├── chapter_planner.py # 章节规划器 │ └── content_generator.py # 内容生成器调用LLM API的核心模块 ├── utils/ │ ├── api_client.py # 封装LLM API调用处理错误重试、频率限制 │ ├── text_processor.py # 文本清洗、摘要提取、关键信息抽取 │ └── config.py # 配置文件API密钥、模型参数、路径等 └── main.py # 程序入口解析参数启动工作流这种模块化设计使得系统易于维护和扩展。例如你可以很方便地更换底层的LLM提供商从OpenAI换成Anthropic或者更换向量数据库从Pinecone换成Chroma而无需重写核心业务逻辑。4. 实操从零开始生成一部短篇故事为了让大家有更直观的感受我们抛开复杂的项目结构用一个极度简化的Python脚本来演示核心流程。假设我们使用OpenAI API和Chroma向量数据库。4.1 环境准备与初始化# 安装必要库 pip install openai chromadb tiktoken# config.py import os from dotenv import load_dotenv load_dotenv() OPENAI_API_KEY os.getenv(OPENAI_API_KEY) EMBEDDING_MODEL text-embedding-3-small LLM_MODEL gpt-4-turbo # 或 gpt-3.5-turbo 用于测试4.2 构建记忆系统# memory_system.py import chromadb from openai import OpenAI import uuid client OpenAI(api_keyOPENAI_API_KEY) chroma_client chromadb.PersistentClient(path./chroma_db) collection chroma_client.get_or_create_collection(namenovel_memory) def get_embedding(text): 获取文本的向量表示 response client.embeddings.create(modelEMBEDDING_MODEL, inputtext) return response.data[0].embedding def store_memory(content, metadata): 存储一段记忆文本内容及其元数据 embedding get_embedding(content) id str(uuid.uuid4()) collection.add( ids[id], embeddings[embedding], documents[content], metadatas[metadata] ) print(f已存储记忆: {metadata}) def search_memories(query, n_results3): 根据查询检索相关记忆 query_embedding get_embedding(query) results collection.query( query_embeddings[query_embedding], n_resultsn_results ) retrieved [] if results[documents]: for doc, meta in zip(results[documents][0], results[metadatas][0]): retrieved.append(f[{meta.get(type, 未知)}] {doc}) return retrieved4.3 核心生成与工作流控制# novel_generator.py from openai import OpenAI from memory_system import store_memory, search_memories import json llm_client OpenAI(api_keyOPENAI_API_KEY) def call_llm(prompt, system_prompt你是一个有帮助的助手。): 调用LLM生成内容 try: response llm_client.chat.completions.create( modelLLM_MODEL, messages[ {role: system, content: system_prompt}, {role: user, content: prompt} ], temperature0.7, max_tokens1500 ) return response.choices[0].message.content.strip() except Exception as e: print(fAPI调用失败: {e}) return None def generate_outline(theme): 生成故事大纲 system_prompt 你是一位科幻小说作家擅长构建宏大的世界观和曲折的情节。 user_prompt f请基于以下主题创作一个短篇科幻小说的故事大纲约300字。 主题{theme} 大纲需要包含 1. 核心冲突 2. 主要人物至少2名及其简要设定 3. 故事的三幕式结构开端、发展、高潮、结局 4. 一个意想不到的转折点。 outline call_llm(user_prompt, system_prompt) if outline: # 存储大纲到记忆库 store_memory(outline, {type: outline, theme: theme}) return outline def generate_chapter(outline, chapter_num, previous_chapter_summary): 基于大纲和上文生成具体章节 # 检索相关记忆为生成提供上下文 relevant_memories search_memories(f大纲和人物设定 {outline[:100]}, n_results2) context \n.join(relevant_memories) system_prompt 你是一位科幻小说作家正在根据大纲创作具体章节。请保持风格一致推进情节。 user_prompt f 【故事大纲】 {outline} 【相关前情信息】 {context} 【上一章摘要】 {previous_chapter_summary if previous_chapter_summary else 这是第一章没有上文。} 现在请创作小说的第{chapter_num}章。 要求 1. 章节标题。 2. 约1000字的正文内容需包含场景描写、人物对话和情节推进。 3. 在本章中需要至少呼应或铺垫一个大纲中提到的元素。 请直接开始撰写章节内容。 chapter_content call_llm(user_prompt, system_prompt) if chapter_content: # 存储本章内容到记忆库 store_memory(chapter_content, {type: chapter, number: chapter_num, outline_theme: outline[:50]}) # 尝试提取本章摘要用于下一章生成 summary_prompt f请用100字以内总结以下章节的核心情节和人物进展\n\n{chapter_content} chapter_summary call_llm(summary_prompt, 你是一个摘要提取工具。) store_memory(chapter_summary, {type: chapter_summary, for_chapter: chapter_num}) return chapter_content, chapter_summary return None, None # 主工作流 def main(): theme 人类发现了一颗被遗弃的外星飞船里面只有一个不断重复着警告信息的人工智能。 print(f主题: {theme}) print(*50) # 1. 生成大纲 print(步骤1: 生成故事大纲...) outline generate_outline(theme) print(f大纲生成完毕:\n{outline}\n) # 2. 生成第一章 print(步骤2: 生成第一章...) chapter1, summary1 generate_chapter(outline, chapter_num1) print(f第一章:\n{chapter1}\n) # 3. 生成第二章传入第一章摘要 print(步骤3: 生成第二章...) chapter2, summary2 generate_chapter(outline, chapter_num2, previous_chapter_summarysummary1) print(f第二章:\n{chapter2}\n) print(短篇故事生成演示完成) # 在实际项目中这里会循环生成更多章节并可能加入更复杂的情节树管理、分支选择等。 if __name__ __main__: main()这个简化示例展示了核心循环生成 - 存储记忆 - 检索相关记忆 - 基于增强的上下文再次生成。在实际的Long-Novel-GPT项目中流程会更加复杂包括对生成质量的评估、情节分支的选择、风格一致性的校验等。5. 常见问题、挑战与优化策略在实际操作中即使有了完善的框架也会遇到各种问题。以下是一些典型挑战及应对思路。5.1 内容质量漂移与一致性维护问题即使有记忆系统生成到中后期人物对话风格可能变得平淡情节可能偏离大纲或出现细微的矛盾如人物眼睛颜色前后不一致。解决策略定期“一致性检查”每生成一定字数如5000字或几个章节后启动一个校验步骤。用一个专门的提示词让模型自查当前内容与人物档案、核心设定是否存在矛盾并输出修正建议。强化关键信息的重复曝光在提示词中不仅通过记忆系统检索还可以将最核心的“宪法级”设定如主角的核心目标、世界观基本法则固定在每一次内容生成的提示词头部确保模型永不遗忘。使用更细致的“属性-值”对管理对于人物的外貌、关键物品的属性等不仅存储为文本片段更可以结构化存储如{人物: 张三, 属性: 眼睛颜色, 值: 深褐色}。在生成涉及该人物的描写时系统可以主动将这些结构化信息插入提示词。5.2 成本与性能的平衡问题使用GPT-4生成数十万字的小说API费用可能高达数百美元。同时串行生成耗时极长。解决策略混合模型策略如前所述将任务分层。用GPT-4做顶层设计大纲、关键情节转折和最终润色用更便宜的模型如GPT-3.5 Turbo、Claude Haiku完成填充性、描述性的内容生成。本地模型兜底对于非核心的、描述性的段落可以尝试调用本地部署的高质量开源模型如Qwen2.5 72B的量化版虽然单次生成慢但无费用适合作为备选或用于批量生成草稿。异步与并行化章节之间如果没有强依赖可以并行生成。场景之间也可以部分并行。这需要更复杂的任务依赖图调度但能极大缩短“挂机”时间。5.3 创意枯竭与情节重复问题模型可能会陷入套路反复使用相似的桥段或对话模式导致故事乏味。解决策略引入随机性与多样性在提示词中明确要求“避免常见的XX桥段”、“尝试从YY角度进行描写”。适当调整生成时的temperature参数如从0.7提升到0.9增加随机性。但要注意过高会导致逻辑混乱。外部灵感注入在规划章节或场景时可以从一个外部“灵感库”中随机抽取一些元素如“意外的访客”、“失效的装备”、“古老的谚语”作为约束条件加入提示词强迫模型跳出固有思维。多模型“辩论”或“投票”对于一个关键情节点的走向可以同时让两个不同的模型或同一模型用不同参数生成多个方案然后由一个“评审”模型或简单规则如哪个方案更符合人物性格来选择最佳的一个。5.4 可控性与作者意图的贯彻问题最终生成的故事可能和作者最初的宏大构想有出入感觉被AI“带偏了”。解决策略人机交互循环Human-in-the-loop这是最重要的策略。系统不应是全自动的而应在关键节点如大纲确认、章节规划、重大转折点暂停将AI的产出呈现给用户由用户进行选择、编辑或提供明确的方向性指令。用户的一次简单反馈如“这个反派动机不够让他更偏执一些”可以极大地修正后续生成的方向。细粒度的“禁止”与“鼓励”列表在系统提示词或项目配置中维护一个“禁止事项”列表如禁止使用“突然”、“莫名其妙地”来转折禁止人物说教式长篇大论和一个“鼓励事项”列表如鼓励使用五感描写鼓励对话推动情节。在每次生成前动态地将相关条目插入提示词。实操心得不要追求一次性生成完美无缺的百万字巨著。将Long-Novel-GPT这类工具视为一个“超级写作助手”或“创意碰撞伙伴”。它的价值在于快速产出高质量的初稿、拓展作者的思路、以及完成那些繁琐的、保持一致性的细节描写。最理想的工作流是作者负责最核心的创意、世界观和人物设定输入AI负责根据这些“种子”生长出丰富的枝叶草稿最后由作者进行修剪、塑形和注入灵魂编辑和修订。这个过程本身就是一种充满惊喜的共创。