基于大语言模型与RAG的AI小说生成：从技术原理到工程实践

1. 项目概述当AI开始“阅读”与“创作”最近在内容创作和小说爱好者圈子里一个名为“auto-novel”的项目引起了我的注意。简单来说这是一个利用人工智能技术实现从“阅读”现有小说到“模仿创作”新内容的自动化工具。它的核心目标是尝试让机器理解人类讲故事的模式、风格和结构并在此基础上生成具备可读性、连贯性甚至带有特定作者风格的新文本。这听起来有点像高级版的“文本生成器”但实际要复杂得多。传统的填充式生成器往往产出的是语法正确但逻辑混乱的“文字垃圾”。而“auto-novel”这类项目其野心在于让AI真正“吃透”一部或多部作品学习其中的角色关系、情节推进、对话风格和世界观设定然后像一个真正的学徒作者那样进行“同人创作”或“风格续写”。它解决的痛点非常明确对于内容创作者、游戏剧情策划、甚至是单纯想获得灵感的写作者它提供了一个强大的“灵感引擎”和“初稿生成器”能够快速突破创作瓶颈探索故事发展的多种可能性。这个项目适合几类人一是对AI辅助创作感兴趣的技术爱好者想了解自然语言处理NLP在创意领域的应用边界二是网文作者或内容生产者希望借助工具提高大纲构思或日常更新的效率三是研究者或学生希望探究当前生成式AI在长文本、结构化叙事上的能力与局限。接下来我将深入拆解这个项目的核心思路、技术实现以及在实际操作中会遇到的各种“坑”。2. 核心思路与技术选型解析2.1 从“模仿学习”到“可控生成”的设计哲学“auto-novel”项目的根本思路并非无中生有而是建立在“模仿学习”的基础上。它的工作流程可以抽象为输入原始文本- 理解与分析 - 建模 - 可控生成 - 输出新文本。这里的“可控”是关键区别于完全天马行空的生成它要求生成的内容在风格、设定或情节上与原作保持一致性。为了实现这一点项目在技术选型上通常会围绕以下几个核心模块展开文本预处理与特征提取模块这是第一步也是地基。程序需要读取小说文本通常是TXT或EPUB格式进行清洗去除乱码、广告、分章、分段。更高级的会进行命名实体识别NER自动标出人名、地名、组织名进行词性标注和依存句法分析理解句子结构甚至进行情感分析标注每段文字的情绪基调。这些提取出的“特征”构成了AI理解这部小说的“词典”和“语法书”。模型训练与微调模块这是核心引擎。早期的方法可能基于统计语言模型如N-gram但效果有限。目前的主流是使用预训练的大语言模型LLM进行微调。例如选用开源的、在大量文本上预训练过的模型如GPT-2、Bloom、LLaMA的某些版本然后用特定作者或特定类型的小说全集作为训练数据对模型进行有监督的微调。这个过程相当于让一个“通才”AI变成专精于“武侠小说”或“某位作家文风”的“专家”AI。微调的目标是让模型内部参数适应目标领域的概率分布。提示工程与生成控制模块这是方向盘。直接让微调后的模型自由生成很容易跑偏。因此需要设计精巧的“提示词”Prompt。例如提示词可能包括“请以[作者X]的风格续写以下片段”[上文片段]“要求新角色[角色名]登场并发生一场冲突。” 更复杂的控制会引入“大纲”或“关键事件序列”作为约束引导生成过程沿着预设的故事线发展。这个模块决定了生成内容的相关性和可控性。后处理与连贯性保障模块这是质检员。生成的文本可能存在前后矛盾如角色头发颜色改变、重复啰嗦、或与已知设定冲突的问题。这个模块可能包含简单的规则检查如禁止连续出现三个相同的形容词也可能引入另一个小的判别模型对生成段落的连贯性和一致性进行打分和筛选。注意技术选型上完全从零训练一个小说生成模型需要海量数据和算力对于个人或小团队不现实。因此基于预训练模型进行微调Fine-tuning或使用提示词工程Prompt Engineering结合检索增强生成RAG是更务实的选择。选择哪个预训练基底模型取决于你的目标追求高质量和可控性可能选择参数量较大的模型进行LoRA等高效微调追求快速响应和本地部署则可能选择参数量较小的模型。2.2 关键组件与依赖库的选择基于上述思路一个典型的“auto-novel”项目可能会依赖以下技术栈编程语言Python是绝对主流因其在AI和数据科学生态中的绝对优势。核心NLP/深度学习框架Transformers (Hugging Face)这是核心中的核心。它提供了数以千计的开源预训练模型如GPT-2、GPT-Neo、BLOOM、LLaMA的简易加载和调用接口以及完整的微调工具链。PyTorch / TensorFlow底层深度学习框架。Hugging Face库通常基于PyTorch也有TensorFlow版本。目前社区活跃度和易用性上PyTorch更胜一筹。LangChain如果你希望构建更复杂的、基于检索或拥有长期记忆的生成流程LangChain是一个强大的框架。它可以帮你轻松管理提示模板、连接向量数据库用于检索相似片段、组织多步链式调用。文本处理与数据工具NLTK / spaCy用于基础的文本清洗、分词、词性标注和命名实体识别。spaCy的工业级性能和准确性通常更好。Jieba (中文)/Konlpy (韩文)等针对特定语言的分词工具。Pandas用于处理和清洗结构化的文本数据如将小说按章节整理成表格。向量数据库可选但推荐用于实现RAG。当你想让AI在生成时参考原作的具体段落时需要将原作切片成片段编码成向量存入如ChromaDB、FAISSFacebook开源的快速相似性搜索库或Qdrant中。生成时先根据当前上下文检索出最相关的原文片段将其作为额外上下文喂给模型能极大提升生成内容的相关性和事实一致性。开发与部署工具Jupyter Notebook / VSCode用于实验和开发。Gradio / Streamlit快速构建一个Web界面让用户输入提示词、选择风格并实时看到生成结果非常适合演示和交互。选择这些组件的原因在于它们共同构成了一个从数据准备、模型训练/调用到应用部署的完整、成熟且社区支持强大的开源生态链。个人开发者可以站在巨人的肩膀上专注于业务逻辑即如何更好地理解和控制故事生成而非重复造轮子。3. 实操构建从零搭建一个简易的AI小说生成器3.1 环境准备与数据收集假设我们想做一个生成“武侠风格”片段的工具。第一步是搭建环境。# 创建虚拟环境推荐 python -m venv novel_ai_env source novel_ai_env/bin/activate # Linux/Mac # novel_ai_env\Scripts\activate # Windows # 安装核心依赖 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 # 根据你的CUDA版本调整 pip install transformers datasets accelerate pip install langchain langchain-community pip install sentence-transformers # 用于将文本转换为向量 pip install chromadb # 轻量级向量数据库 pip install gradio # 用于构建Web UI pip install jieba # 中文分词数据收集是质量的关键。你需要找到一个可靠的、版权允许的武侠小说文本源。理想情况是收集多位作家的多部作品这样模型学到的不是某个作者的 idiosyncrasies特殊癖好而是武侠这一体裁的通用模式。将小说保存为纯文本文件.txt每部小说一个文件并确保编码为UTF-8。3.2 数据预处理与向量库构建数据不能直接扔给模型。我们需要进行清洗和结构化。import os import re import jieba from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import Chroma # 1. 读取和清洗单个小说文件 def clean_novel_text(file_path): with open(file_path, r, encodingutf-8) as f: text f.read() # 去除无用的出版信息、网址、特殊字符 text re.sub(r[^\u4e00-\u9fff。“”‘’\-\—\…\\\《\》\、\n\r\s\w], , text) # 合并过多的空白行 text re.sub(r\n\s*\n, \n\n, text) return text # 2. 分割文本。长篇小说需要切成小块以便模型处理和后续检索。 text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 每个片段的字符数可根据模型上下文长度调整 chunk_overlap50, # 片段间重叠字符保持连贯性 separators[\n\n, \n, 。, , , , , 、, ] ) all_splits [] novels_dir ./武侠小说合集 for filename in os.listdir(novels_dir): if filename.endswith(.txt): path os.path.join(novels_dir, filename) raw_text clean_novel_text(path) splits text_splitter.split_text(raw_text) all_splits.extend(splits) print(f共获得 {len(all_splits)} 个文本片段。) # 3. 构建向量数据库用于RAG embeddings HuggingFaceEmbeddings(model_namesentence-transformers/paraphrase-multilingual-MiniLM-L12-v2) vectorstore Chroma.from_texts(textsall_splits, embeddingembeddings, persist_directory./chroma_db) vectorstore.persist() print(向量数据库构建完成。)这段代码完成了从原始文本到可检索知识库的转换。chunk_size的选择至关重要太小会失去上下文太大会超出模型处理能力并降低检索精度。500-1000字对于中文段落是一个常见的起始值。3.3 模型加载与提示词设计我们不从头训练而是使用一个预训练的中文模型并通过提示词来引导它。这里以使用ChatGLM系列或Qwen通义千问的本地化版本为例它们对中文支持良好。我们使用transformers库加载模型并结合LangChain进行调用。from langchain.llms import HuggingFacePipeline from transformers import AutoTokenizer, AutoModelForCausalLM, pipeline, GenerationConfig model_name THUDM/chatglm3-6b # 举例确保你有权使用并下载了模型 tokenizer AutoTokenizer.from_pretrained(model_name, trust_remote_codeTrue) model AutoModelForCausalLM.from_pretrained(model_name, trust_remote_codeTrue, device_mapauto, torch_dtypetorch.float16) # 创建文本生成管道 generation_config GenerationConfig( max_new_tokens300, # 生成的最大长度 temperature0.7, # 创造性越低越保守越高越随机 top_p0.9, # 核采样控制候选词集合 do_sampleTrue, repetition_penalty1.1, # 重复惩罚 ) pipe pipeline( text-generation, modelmodel, tokenizertokenizer, generation_configgeneration_config ) llm HuggingFacePipeline(pipelinepipe) # 设计一个包含检索增强的提示词模板 from langchain.prompts import PromptTemplate from langchain.chains import RetrievalQA template 你是一个精通武侠小说创作的助手。请根据以下提供的相关背景资料和用户的问题以古典武侠的风格进行创作。 相关背景资料 {context} 用户请求{question} 请用中文进行创作保持语言精炼情节紧凑符合武侠世界的逻辑。直接开始你的创作不要解释。 PROMPT PromptTemplate(templatetemplate, input_variables[context, question]) # 将向量数据库转换为检索器 retriever vectorstore.as_retriever(search_kwargs{k: 3}) # 检索最相关的3个片段 # 创建检索增强生成链 qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, # 将检索到的所有文档“塞”进提示词 retrieverretriever, chain_type_kwargs{prompt: PROMPT}, return_source_documentsTrue )这个模板是关键。{context}会被自动替换为从向量库中检索到的、与用户问题最相关的原文片段。这相当于给了AI一个“参考资料”让它生成的对话、招式名称、地理环境不至于完全脱离武侠的语境。temperature和top_p是控制生成“创意度”的核心参数需要根据生成结果反复调整。3.4 构建交互界面与测试生成最后我们用一个简单的Web界面来包装它方便测试。import gradio as gr def generate_story(prompt_input): # 调用我们上面创建的RAG链 result qa_chain({query: prompt_input}) generated_text result[result] # 可以简单后处理比如去除可能出现的重复句首 lines generated_text.split(\n) seen set() unique_lines [] for line in lines: if line not in seen: seen.add(line) unique_lines.append(line) else: break # 遇到重复即停止防止循环 return \n.join(unique_lines[:10]) # 返回前10行 # 创建Gradio界面 demo gr.Interface( fngenerate_story, inputsgr.Textbox(lines3, placeholder请输入你的武侠故事开头或指令例如月黑风高夜一位黑衣剑客独自来到破败的山神庙前... 接下来发生了什么, label创作提示), outputsgr.Textbox(lines15, labelAI生成的武侠片段), titleAI武侠小说生成器, description输入一个开头或指令AI将尝试以武侠风格续写。生成内容基于学习的武侠小说资料。 ) demo.launch(shareFalse) # 设置shareTrue可获得一个临时公网链接运行这段代码一个本地Web服务器就会启动。你可以在浏览器中输入提示比如“描写一场在竹林中的高手对决使用剑和暗器”AI会结合它从向量库中检索到的关于“竹林”、“对决”、“剑”、“暗器”的描写片段生成一段新的文字。4. 效果优化与深度控制策略4.1 生成质量的核心调参经验直接使用默认参数生成结果往往差强人意。以下几个参数是调优的关键它们直接决定了生成文本的“智商”和“情商”Temperature温度通常0.1~1.0这是控制随机性的首要参数。温度越低如0.1-0.3生成结果越确定、保守、可预测倾向于选择概率最高的词。适合需要严谨、连贯的场景比如接续一个非常具体的剧情。温度越高如0.7-1.0生成结果越随机、有创意、出人意料但同时也更容易出现语法错误或逻辑跳跃。对于需要灵感和多样性的故事开头可以尝试调高。实操心得我的经验是对于情节推进部分使用较低的温度0.3-0.5以保证连贯对于需要构思新转折点或人物对话时可以短暂切换到较高温度0.7-0.9获取灵感然后再用低温细化。Top-p核采样通常0.5~1.0这是另一种采样方法。它从累积概率超过p的最小词集合中随机选择。Top-p值越小候选词集合越小生成越集中值越大候选词集合越大生成越多样。通常与Temperature配合使用。调参组合低Temperature 低Top-p产生非常稳定但可能乏味的文本高Temperature 高Top-p则可能天马行空。一个常见的平衡点是temperature0.7, top_p0.9。Repetition penalty重复惩罚通常1.0~1.2这个参数至关重要用于惩罚已经出现过的词元token值大于1.0即可生效。对于长文本生成必须将其设置为1.1或更高否则AI极易陷入重复循环比如不断重复“他笑了笑他笑了笑他笑了笑...”。Max new tokens最大生成长度不要一次性要求生成整章。分批生成是更可靠的策略。例如每次只生成200-300个token约150-250汉字然后人工审阅将其作为新的上下文输入再生成下一段。这能有效控制叙事方向防止中期跑偏。4.2 进阶控制大纲引导与角色一致性维护要让AI写出一个完整的故事仅仅靠开头的提示词是远远不够的。我们需要更精细的控制机制。大纲引导法做法先让人工编写一个简略的故事大纲例如“第一幕主角在客栈听闻宝藏消息 - 第二幕前往黑风岭遭遇埋伏 - 第三幕反杀敌人发现藏宝图是假的 - 第四幕真正的阴谋浮现...”。实现将当前幕的标题和简要描述作为系统提示词的一部分输入给AI。在生成每一幕的具体内容时都附上该幕的标题和下一幕的标题让AI明确当前阶段的任务和下一阶段的目标。这相当于给AI一个“剧本目录”。角色卡片与状态跟踪问题AI经常忘记角色的特征如“左脸有疤”、说过的话、甚至性别。解决方案维护一个“角色状态字典”和“关键事实列表”。角色字典{“张无忌”: {“武功”: “九阳神功、乾坤大挪移”, “当前位置”: “光明顶”, “情绪”: “愤怒”}, “赵敏”: {...}}事实列表[“屠龙刀在谢逊手中” “六大派正在围攻光明顶”]在每次生成对话或涉及角色的情节时将相关角色的当前状态和关键事实以简洁的格式追加到提示词中。例如“[当前状态张无忌在光明顶大殿身中玄冥神掌寒毒未愈。已知事实六大派即将攻上山顶。] 请生成张无忌与白眉鹰王的对话”这需要额外的程序逻辑来在生成过程中更新和维护这些状态实现起来更复杂但对于中长篇生成是维持一致性的不二法门。风格注入与负面提示风格注入除了在系统提示词里说“用武侠风格”更好的方法是在微调数据或检索资料中混入大量目标风格的经典例句。或者在提示词中直接给出范例“请模仿以下文风‘剑气纵横三万里一剑光寒十九洲。只见那白衣人身影一晃便如鬼魅般欺近三尺之内。’ 来描写一场对决。”负面提示告诉AI不要做什么。在高级的生成接口中可以设置“负面提示词”例如“避免使用现代词汇”、“避免直接心理描写”、“避免情节突然跳跃到科幻”。这能有效过滤掉不想要的生成方向。5. 常见问题、陷阱与排查实录在实际操作中你会遇到各种各样的问题。下面是我踩过的一些坑和解决方案。5.1 生成内容逻辑混乱或偏离主题症状AI写着写着突然从武侠世界跳到了办公室政治或者人物行为完全不合常理。原因分析上下文长度不足模型有固定的上下文窗口如2048个token。如果你的对话历史当前提示生成内容超过了这个限制模型就会“忘记”最早的信息导致偏离。提示词不够明确或存在歧义。检索到的参考片段不相关向量检索的相似度计算可能出错喂给了AI错误的“参考资料”。排查与解决检查上下文长度计算你输入的token数。如果使用transformers的tokenizer可以用len(tokenizer.encode(your_text))来查看。确保留给生成的空间足够。精简和强化提示词采用“角色-任务-背景-要求”的清晰结构。例如“【角色】你是一位武侠小说家。【任务】续写以下情节。【背景】[清晰的故事背景]【要求】保持古风语言重点描写动作场面情节符合人物性格。”优化检索检查向量数据库的检索结果。尝试调整search_kwargs比如增加k值检索更多片段或使用MMR最大边际相关性搜索来平衡相关性与多样性。确保文本切分chunk的大小和重叠度合理。5.2 角色言行不一致与事实矛盾症状上一段说角色A受伤了下一段他就生龙活虎地打架或者角色B明明不在场却参与了对话。原因分析模型在生成长文本时没有有效的长期记忆和事实核查机制。它只对最近的上下文最敏感。解决策略主动状态管理如前所述实现一个外部的“故事状态机”。在每一轮生成后用简单的规则或另一个小型的文本分类模型从生成文本中提取关键信息如“角色A左臂受伤”更新状态字典。分段生成与人工校验不要依赖AI一次性写很长。每生成一段如300字就人工快速浏览修正明显的事实错误并将修正后的准确段落作为新的上下文输入给AI让它基于正确的事实继续。在提示词中重申关键事实在每次生成请求中都以“已知信息”的形式重复最重要的、不可违背的设定。5.3 语言风格“现代化”或“翻译腔”症状生成的古风小说里出现“好吧”、“然后他心想”、“这是一个问题”等现代口语或欧化句式。原因分析预训练模型的数据集包含大量现代网络文本和翻译作品即使微调这种底层语言风格也可能残留。解决策略数据清洗确保你的微调数据或检索库中的文本风格是纯净的。如果数据源混杂效果必然打折。强化风格提示在提示词中提供非常具体的风格范例并要求“严格模仿以下例句的词汇、句式和节奏”。后处理替换建立一个“违和词替换表”。生成后用程序自动扫描将“然后”替换为“随即”将“我想”替换为“心下思忖”等。虽然生硬但能快速改善观感。使用风格更强的基底模型如果条件允许寻找在古典文学语料上进一步预训练过的模型效果会比通用模型好得多。5.4 生成速度慢或资源占用高症状生成一段文字需要几十秒甚至几分钟GPU内存爆满。原因分析大模型推理本身计算量巨大尤其是在没有GPU或GPU显存不足的情况下。优化方案模型量化使用bitsandbytes等库对模型进行4-bit或8-bit量化可以大幅减少显存占用且精度损失对文本生成任务通常可接受。使用更小的模型权衡质量与速度。ChatGLM-6B、Qwen-7B等模型在消费级显卡如RTX 3060 12GB上可以流畅运行。Baichuan-13B可能需要更高级的显卡或进行量化。优化生成参数减少max_new_tokens使用streaming流式输出让用户先看到部分结果。考虑API服务如果本地硬件有限可以调用云端大模型的API如OpenAI GPT系列、国内各大厂的开放API。但这会引入网络延迟、成本和数据隐私考量。6. 项目扩展方向与应用场景思考一个基础的“auto-novel”项目搭建完成后有很多值得深入探索的方向它们也对应着不同的应用场景。6.1 从“续写”到“共创”交互式叙事系统当前的模式主要是“输入提示 - 输出段落”的单向生成。更高级的模式是构建一个交互式叙事系统。在这个系统里AI不仅是作者也是故事的“裁判”和“世界模拟器”。实现思路定义一套简单的“世界规则”如体力值、武力值、关系好感度。用户以“玩家”身份输入行动指令如“调查桌上的信件”、“向黑衣人拔剑”。AI不仅生成叙述性文字描述结果还根据“世界规则”更新内部状态如“拔剑触发战斗消耗体力10点黑衣人好感-50”。将更新后的状态反馈给用户并生成新的场景描述等待用户下一步指令。技术要点这需要将大语言模型与一个确定的“游戏逻辑引擎”相结合。模型负责处理自然语言输入和生成富有文采的输出逻辑引擎负责维护状态和裁决规则。这已经接近文字冒险游戏Interactive Fiction或轻度RPG的雏形。6.2 垂直领域深度定制商业文案与剧本辅助“auto-novel”的技术栈可以轻易迁移到其他需要创意文本的垂直领域。商业广告文案收集大量优秀的广告语、产品描述训练或提示AI生成符合品牌调性的文案。关键在于构建高质量、风格统一的提示词模板和示例库。短视频剧本/分镜脚本输入一个热点话题或产品要求AI生成一个包含场景、对话、动作提示的简短剧本。这里需要模型理解镜头语言和节奏感数据准备阶段就需要喂入大量的剧本格式文本。游戏任务与对话生成为开放世界游戏生成海量的、不重复的支线任务描述和NPC对话。通过约束角色身份、任务类型收集、护送、击杀、奖励等要素可以批量生成内容极大减轻游戏编剧的工作量。6.3 多模态融合为故事配图这是目前非常火热的方向。当AI生成一段故事后自动调用文生图模型如Stable Diffusion、DALL-E为关键场景生成配图。技术链路文本生成模型 - 关键场景描述提取 - 图像生成提示词优化 - 文生图模型 - 生成图片。挑战如何从一段文字中自动提取出最适合视觉化的、包含足够细节且符合图像模型理解的“提示词”是一个专门的课题称为“提示词提炼”或“反向提示工程”。这可能需要训练一个小模型学习从故事段落到高质量图像提示词的映射。构建“auto-novel”项目的整个过程是一个典型的“发现问题 - 拆解问题 - 利用现有工具组合解决 - 持续优化”的工程实践。它离替代人类作家还有极其遥远的距离但在提供灵感、突破瓶颈、快速生成草稿乃至创造新型互动体验上已经展现出巨大的潜力。最终产出的质量五分靠模型五分靠使用者的引导、约束和后期打磨。把它看作一个能力超强但需要严格指挥的“写作副手”而非全自动的“创作黑箱”才能最大程度地发挥其价值。