AI辅助网文创作理论研究笔记（五）：测试环境的搭建和一些问题的讨论

前段时间一直在做另一个MCP数学插件和有限元的AI插件。导致AI写文的项目进展缓慢，不过总算折腾完了。原本想着等这些项目都填完了坑，但可惜实在吃尽当光，找好随便找了个保安工作，虽然一个月只有两三千，但好在比较清闲，可以一边工作一边搞这些。所以这个项目大概率会恢复两三天一更吧？

建了一个库，笔记和skill可在里面查找，目前还没测试，只是又把整个理论完善了一下，做了一些简单的可行性分析，凌晨三点了，我还要去跑一下那几个skill看看效果，笔记5里面很多都是头脑风暴，主要在和AI讨论，也没有细改，肯定有很多谬误。

https://github.com/sanshanjianke/ai-webnovel-workflow

然后我把笔记5.md放出来，下面就是笔记5.md的内容了。

L3L4层向量数据库设计方案

L3 叙事层：映射关系库

核心功能：将网文"效果指令"翻译为叙事学"技术指令"

数据结构建议：

复制代码

{
  "效果标签": "装逼打脸-压抑阶段",
  "叙事指令": {
    "视角": "内聚焦（反派/路人视角）",
    "节奏": "慢速叙事（扩述/场景）",
    "话语模式": "大量对话+环境描写"
  },
  "理由": "通过无知者的傲慢视角，制造信息差",
  "参考片段": ["..."],
  "关联网文概念": ["欲扬先抑", "期待感悬置"]
}

数据来源：

从经典网文/名著中手工标注"效果-技法"对照表
每条数据需包含：理论术语 + 定义 + 网文应用场景 + 经典范文片段

L4 渲染层：微观技法库

核心功能：提供具体写作范例

数据结构建议：

复制代码

{
  "技法标签": ["外聚焦", "动作描写", "短句"],
  "风格": "古龙式冷硬",
  "参考文本": "光头男人敲了敲桌子...",
  "来源": "古龙《流星蝴蝶剑》",
  "适用场景": "打脸高潮、战斗爆发"
}

数据来源：

收集名家片段（古龙、海明威等）
按视角+节奏+话语模式多维度打标签

实施建议

优先级：先搞L3映射库，它是整个系统的"翻译器"，瓶颈最大
冷启动：用笔记1中的表格作为初始种子数据，约50-100条核心映射关系
渐进迭代：在实际使用中不断补充"效果->技法"的映射条目

示例：拍卖会打脸场景拆解

第一步：确定功能单位

铺垫功能：

反派炫耀宝物
众人吹捧
反派嘲讽主角穷酸
主角沉默/被轻视

高潮功能：

主角亮出极品物品
全场震撼
拍卖师失态
反派脸色难看

收尾功能：

成交天价
主角淡然
反派失势

第二步：组合成序列

序列	功能链	情绪曲线
铺垫序列	反派炫宝→众人捧→嘲讽主角→主角沉默	压抑
反转序列	主角亮宝→全场惊→拍卖师喊价→反派懵	爆发
收尾序列	天价成交→主角淡然→反派失声→众人膜拜	余韵

第三步：组合成情节

采用嵌入结构：

复制代码

主线：拍卖会（序列1→2→3循环）
  └─ 嵌入本次打脸情节
      └─ 内部：铺垫→反转→收尾

第四步：细化到写作指令（第三层）

序列	视角	节奏	话语模式
铺垫	反派内聚焦（让读者感受其傲慢）	慢速扩述	大量对话+心理描写
反转	外聚焦（客观呈现震撼场面）	中速等述	动作+环境描写为主
收尾	主角内聚焦（显示其淡然）	快速概述	简短对话+留白

L1 种子层改进建议

L1输出的故事愿景文档可增加以下要素（由作者自行填写）：

一句话故事简介：用一句话概括故事核心冲突
类型标签：明确类型定位（如 #玄幻 #系统文 #种田文）
目标平台：起点/晋江/番茄/飞卢等，不同平台策略不同
核心爽点：故事给读者的核心体验（如"工业建设"、"降维打击"、"打脸复仇"）
开篇钩子：第1章必须成立的冲突/事件
热点/潮流元素：时下热点（AI工具/游戏/社会事件）及融合方式，评估时效性

示例：《1958我给国家造电脑》

Logline：2030年被AI淘汰的失业大专程序员，带着工作室穿越到1958年
类型标签：#工业文 #穿越 #科技强国
目标平台：起点
核心爽点：技术降维打击 + 工业建设 + 国家崛起的自豪感
热点元素：DeepSeek（当下最火的国产AI），融合为金手指------主角带着运行中的DeepSeek服务器穿越，1958年的算力根本跑不动，但模型本身可以作为"超级大脑"辅助决策

向量数据库构建方案

命名区分

为避免混淆，本文档使用以下命名区分：

创作模型	数据构建流程
L1 种子层	数据海（输入）
L2 架构层	第一道过滤
L3 叙事层	第二道过滤
L4 渲染层	第三道过滤
-	向量数据库（输出）

核心区别：

创作模型：从创意到正文的生成流程
数据构建：从数据海到向量数据库的处理流程

设计思路：自顶向下

先确定向量数据库最终需要什么格式，然后反向推导每一道过滤需要做什么。

与创作模型的对应关系

创作模型	需要的数据库	数据来源	当前状态
L2 架构层	爽点公式、编辑经验、人物设计经验、序列-功能设计经验	❌ 无法从文本提取	暂时搁置
L3 叙事层	效果标签 → 叙事指令 + 参考片段	✅ 第二道过滤 + 第三道过滤	可行
L4 渲染层	技法标签 + 参考文本	✅ 第二道过滤 + 第三道过滤	可行

数据流向：

复制代码

数据海 → 第一道过滤 → 第二道过滤 → 第三道过滤 → 向量数据库
                                                        ↓
                                         ┌──────────────┴──────────────┐
                                         ↓                             ↓
                                    L3映射关系库                  L4微观技法库
                                  （供创作模型L3调用）           （供创作模型L4调用）

结论：L2数据库暂不通过本流程构建，三道过滤可为L3、L4提供数据支撑。

输入：数据海

内容：原始小说库（txt格式）规模：400G - 100G 状态：未经处理的原始文本

说明：数据海是要丢进Dify/LangChain处理的原始数据，作为整个流程的输入。

第一道过滤：质量筛选

Agent：

质量评估师：筛选文笔上佳、特点鲜明的作品
标签标注师：给作品打上多个标签（非互斥）

筛选标准：

文笔质量
特点鲜明度（最能代表某种风格/套路）
符合理论模型

标签类型（可叠加）：

类型标签：#玄幻 #都市 #系统 #无限流 #种田 #历史等
套路标签：#退婚流 #签到流 #苟道流 #迪化流等
风格标签：#轻松 #暗黑 #热血 #搞笑等
平台标签：#起点风 #飞卢风 #番茄风等

规模：从数据海筛选至约50G - 20G 输出：精选书单 + 多维标签

第二道过滤：拆分方案分析

当前设计：一个层同时生成L3映射数据（效果→叙事指令）和L4技法数据（叙事指令→正文）。

是否拆分成并行或串行的两层？分析如下：

方案A：并行

复制代码

第一道过滤输出
       ↓
┌──────┴──────┐
↓             ↓
L3数据生成    L4数据生成
(效果→叙事)   (叙事→正文)
↓             ↓
质检A         质检B
       ↓
┌──────┴──────┐
     汇总
       ↓
   向量数据库

优点：

速度快，可并行处理
两边独立，互不阻塞
可分配给不同Agent同时工作

缺点：

重复劳动：两边都要读取同一原文
一致性风险：L3标注"外聚焦+短句"，L4摘的片段可能不符合
数据可能错位：效果标签与正文片段对应不上
质检复杂：需要额外步骤检验两边数据是否匹配

适用场景：

数据量大、追求速度
有足够的计算资源并行处理
可容忍一定程度的数据不一致

潜在问题：

需要在汇总时做对齐检验
如果不一致，需要人工或AI回溯修正

方案B：串行

复制代码

第一道过滤输出
       ↓
L3数据生成（效果→叙事指令）
       ↓
质检A：检验叙事指令是否合理
       ↓
L4数据生成（根据叙事指令摘取对应正文）
       ↓
质检B：检验正文是否符合叙事指令
       ↓
   向量数据库

优点：

数据一致性强：L4根据L3的标注去摘取，不会错位
不重复劳动：原文只读一遍
逻辑清晰：符合创作模型的流程（L3先出叙事指令，L4再写正文）
质检更简单：每一步都可验证

缺点：

速度慢，需串行等待
L4依赖L3质量：L3标注错误会传导到L4
如果L3返工，L4也要重新执行

适用场景：

数据质量优先
需要高一致性的数据
资源有限，无法并行

潜在问题：

L3质检通过后发现L4无法找到对应正文，需要回溯
可以在L3阶段就预判L4是否可行（如：这个叙事指令是否有现成范例？）

对比总结

维度	并行	串行
速度	接近（流水线式）	接近（流水线式）
一致性	需要事后对齐	天然一致
专注度	各自专注领域	L4处理L3产出
工作内容	独立完整	有上下游依赖
灵活性	高	低

关键洞察

速度问题：在Dify流水线架构下，串行和并行速度应该接近，除非两者步调严重不一致。速度不是核心考量。

并行的真正优势：

各自专注领域：L3专注序列-功能与视角、引言等叙事符号处理；L4专注将叙事指令转为正文
不需要"吃上面传下来的"：两边独立从原文提取，各取所需
L3产出可能不带正文：L3只负责叙事指令，正文由L4单独处理

串行的真正问题：

L3产出传给L4，L4只能处理"剩下的"
如果L3产出不带正文，L4还需要回溯原文
灵活性低，L4被L3的产出限制

当前倾向

并行方案更合理，理由：

L3和L4工作内容不同，各自专注更高效
L3产出叙事指令（可能不含正文），L4单独处理正文
流水线架构下速度差异不大

但具体分工边界（L3是否包含参考片段）仍需深入思考。

第三道过滤：检验

Agent（多Agent交叉检验）：

一致性检验师：检验叙事符号与正文是否匹配
完整性检验师：检验数据格式是否完整
质量检验师：检验正文片段质量是否达标

检验标准：

叙事符号标注是否准确（视角、节奏、话语模式与正文是否对应）
正文片段是否具有代表性
数据格式是否完整

输出：最终数据集（通过质检的清洗数据）

输出：向量数据库

任务：将最终数据集转化为向量数据库

输出：

L3映射关系库：效果标签 → 叙事指令 + 参考片段
L4微观技法库：技法标签 + 参考文本

技术实现：Dify / LangChain + 向量数据库（如Milvus/Chroma）

数据库架构讨论

方案一：分开两个数据库

优点：

查询方向清晰：L3查映射库（效果→叙事指令），L4查技法库（叙事指令→正文）
数据结构各取所需：映射库偏结构化规则，技法库偏文本片段
索引更精准，互不干扰
维护独立，互不影响

缺点：

需要维护两套索引
跨库查询不便

实现方式：

复制代码

数据库系统A：L3映射关系库
数据库系统B：L4微观技法库

方案二：合并一个数据库

优点：

统一管理，部署简单
跨层级查询方便（如直接从效果查到正文）
只需维护一套索引

缺点：

数据结构需要统一，难以兼顾结构化规则和文本片段
查询逻辑复杂，需要区分数据类型
可能互相干扰，影响精准度

实现方式：

复制代码

单一数据库
├── type: mapping    # L3映射数据
└── type: technique  # L4技法数据

方案三：同一系统，分collection（折中）

优点：

管理方便（一个系统）
逻辑清晰（两个collection）
查询互不干扰

实现方式：

复制代码

Milvus/Chroma
├── collection: l3_mapping    # 映射关系库
│   └── 查询：效果标签 → 叙事指令
└── collection: l4_technique  # 微观技法库
    └── 查询：叙事指令 → 正文片段

当前状态：待定，后续根据实际使用情况决定。

数据流向总览

复制代码

┌─────────────────────────────────────────────────────────┐
│ 数据海：400G-100G txt小说                                 │
│ （原始数据，作为流程输入）                                  │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 第一道过滤：质量筛选 + 标签标注：50G-20G                   │
│ （质量评估师 + 标签标注师）                                │
│ 输出：精选书单 + 多维标签                                  │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 第二道过滤：标签标注 + 文本摘取：10G-5G                    │
│ （序列识别师 + 叙事标注师 + 片段提取师）                    │
│ 输出：带叙事符号的正文片段数据集                            │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 第三道过滤：检验                                          │
│ （一致性检验师 + 完整性检验师 + 质量检验师）               │
│ 输出：最终数据集                                          │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ 向量数据库（输出）                                         │
│ L3映射关系库 + L4微观技法库                                │
└─────────────────────────────────────────────────────────┘

每层保留：所有中间数据都保留，形成数据仓库，便于日后使用。

L2数据库困境（待解决）

创作模型的L2需要以下知识：

爽点公式（压抑-释放、期待感悬置、黄金三章等）
网文编辑经验
人物设计经验（行动元分配、人设构建）
序列-功能设计经验

问题：这些是"方法论"层面的知识，无法像视角、节奏那样从网文文本中直接提取。

可能来源：

网文理论文章/教程（龙空、知乎、公众号）
写作指南书籍（《救猫咪》《故事》等剧作法）
编辑/作者访谈和经验总结
人工构建：将资深作者经验显性化

当前策略：暂时搁置，优先完成L3、L4数据库。

待细化问题

标签体系：需要与创作模型的标签体系对齐
Agent设计：每个Agent的具体提示词和检验标准
工具选择：Dify vs LangChain，或混合使用
质量控制：第三道过滤（检验）的具体流程

RAG困境与领域知识注入

RAG vs 微调的核心矛盾

方案	优点	缺点
RAG	低成本、可更新、无需训练	占上下文、分散注意力、检索噪音、知识"外挂"不内化
微调	知识内化、推理更快、无上下文限制	高成本、知识冻结、需重新训练才能更新

RAG的具体困境

1. 上下文挤占

检索到的文本片段占用context窗口，留给创作的空间变少。

示例：

模型上下文：32K
检索片段：5K（10个范例）
剩余创作空间：27K → 实际可能更少（系统提示词+历史对话）

2. 注意力分散

模型要在"检索到的参考文本"和"当前任务"之间切换，影响生成质量。

现象：

生成的文本有"拼接感"
风格不一致，时而像参考文本，时而偏离
模型"被带偏"，模仿参考文本而非理解其原理

3. 检索噪音

不相关的片段被检索进来，干扰模型判断。

原因：

向量相似度不等于语义相关性
粗略的标签匹配可能引入噪音
检索系统本身的不完美

4. 知识外挂

模型"知道"有知识库可查，但不会"内化"这些知识，每次都要检索。

问题：

无法形成"直觉"式的写作能力
复杂推理时难以灵活运用
依赖检索质量，不稳定

微调的问题

1. 资源成本高

全量微调需要大量GPU资源。

2. 知识冻结

微调后知识固定，更新需要重新训练。

3. 灾难性遗忘

可能遗忘原有能力（如通用推理能力）。

LoRA/QLoRA：折中方案

LoRA（Low-Rank Adaptation）

原理：只训练低秩矩阵，冻结原模型参数。

优点：

参数量小（约1%），成本低
可插拔，多个LoRA可切换
不破坏原模型能力

缺点：

知识注入深度有限
复杂能力难以习得

QLoRA（Quantized LoRA）

原理：4bit量化 + LoRA。

优点：

更低显存需求
单卡可微调大模型
性能接近LoRA

缺点：

量化可能损失精度
某些任务效果下降

领域知识注入策略

知识类型与适配方案

知识类型	适合RAG	适合微调	理由
叙事学概念（视角、节奏定义）	✅	❌	定义性知识，检索即可，不值得微调
写作范例片段	✅	❌	参考性质，微调易过拟合
网文爽点公式	⚠️	✅	需要理解运用，可内化成"直觉"
风格/语感	❌	✅	RAG难以传递风格，必须微调
人物行为逻辑	⚠️	✅	需要推理能力，微调更佳
序列-功能设计	⚠️	✅	规律性知识，可内化

混合策略建议

方案：微调基础能力 + RAG补充具体知识

复制代码

┌─────────────────────────────────────────────────────────┐
│ 基础模型（通用能力）                                      │
│ + LoRA（网文写作风格/语感/爽点直觉）                      │
└─────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────┐
│ RAG（具体知识补充）                                       │
│ - 叙事学概念定义                                          │
│ - 写作范例片段                                            │
│ - 映射关系查询                                            │
└─────────────────────────────────────────────────────────┘

分工：

LoRA负责：风格、语感、网文"味儿"、爽点直觉
RAG负责：具体概念、范例、规则查询

微调成本估算

案例：Tifa-DeepSexV2-7b-MGRPO

基础模型：Qwen2.5-7B（7B参数）

训练方法（四阶段）：

增量预训练：注入0.1T Token小说
SFT冷启动：学习思维链
MGRPO：改进的GRPO强化学习
DPO：防重复、增强安全性

训练资源：

项目	规格
设备	2×8 H100 GPU集群（16张H100）
预计时长	3000 H100小时
当前进度	7%已有效果
数据量	0.1T小说 + 10万条SFT

重要说明 ：3000 H100小时是完整四阶段训练，包含增量预训练、SFT、强化学习、DPO。这与简单的LoRA微调成本完全不同。

成本对比：

训练类型	7B模型成本估算
增量预训练（注入大量知识）	极高（需处理海量Token）
完整四阶段训练（如Tifa）	~3000 H100小时 ≈ 6万-9万元
SFT监督微调	中等
LoRA微调	低（单卡可完成）
QLoRA微调	极低（消费级显卡）

不同规模模型的微调成本

7B模型（如Qwen2.5-7B、GLM-4-9B）

方法	显存需求	单卡可否	预估成本
全量微调	~60GB	❌ 需多卡	高（需集群）
LoRA	~16GB	✅ 单卡（A10/3090）	中
QLoRA(4bit)	~6GB	✅ 单卡（3060/4060）	低

个人可承担：QLoRA微调7B模型，单张消费级显卡即可。

70B模型（如Qwen2.5-72B）

方法	显存需求	需要卡数
QLoRA(4bit)	~40GB	1张A100/H100
LoRA	~140GB	2-4张A100
全量微调	~500GB+	需集群

小团队可承担：QLoRA微调70B，租用云端A100可完成。

大规模MoE模型（当前主流）

模型	总参数	激活参数	架构	QLoRA显存估算
Qwen3.5-397B-A17B	397B	17B	MoE	~240GB（约4-6张H100）
DeepSeek-V3	685B	37B	MoE	~400GB（约8张H100）
GLM-5	754B	-	MoE	~450GB（约8-10张H100）

说明：现代大规模模型多采用MoE（Mixture of Experts）架构，激活参数远小于总参数。微调时主要处理激活部分，但存储仍需考虑总参数。

个人/小团队可行性：

Qwen3.5-397B：小团队勉强可行（租用云端集群）
DeepSeek-V3 / GLM-5：需专业算力集群，个人基本不可行

成本参考（AutoDL租用价格）

GPU型号	显存	价格
RTX PRO 6000	96GB	~7.97元/小时
H800	80GB	~9.35元/小时

训练时间估算

增量预训练（注入知识的主要成本）

关键参数：

Token处理速度：单卡约5000-10000 tokens/秒（取决于模型大小和硬件）
数据量：需要注入多少Token

估算公式：

复制代码

训练时间 = 总Token数 / (处理速度 × GPU数量)

不同数据量的预训练时间（7B模型，单张H800）

数据量	Token数	预估时间（单卡）	成本
小规模	1B	~30-60小时	~300-600元
中规模	10B	~300-600小时	~3000-6000元
大规模	100B（0.1T）	~3000-6000小时	~30000-60000元
超大规模	1T	~30000-60000小时	~30-60万元

多卡加速：

4卡并行：时间缩短至1/3-1/4
8卡并行：时间缩短至1/6-1/8

Tifa案例重新计算

数据量：0.1T Token = 100B Token

配置：16张H100/H800

计算：

单卡处理速度：假设8000 tokens/秒
16卡并行速度：约100000 tokens/秒
训练时间：100B / 100000 = 1M秒 ≈ 280小时

实际Tifa用了3000小时的原因：

包含4个阶段（预训练+SFT+MGRPO+DPO）
增量预训练可能用了更多数据或更多epoch
MGRPO强化学习迭代消耗大量时间
调参、测试、失败重试

修正后的成本估算：

训练阶段	数据量	配置	时间	成本
增量预训练（小）	10B Token	4张H800	~100小时	~3700元
增量预训练（中）	50B Token	8张H800	~170小时	~13000元
增量预训练（大）	100B Token	16张H800	~280小时	~42000元
SFT	10万条	4张H800	~20小时	~750元
DPO/RLHF	-	4张H800	~50小时	~1900元
完整训练（估算）	100B+	16张H800	~500-1000小时	~7.5-15万元

各训练类型的成本对比（修正）

训练类型	目的	7B模型成本	适用场景
QLoRA微调	调整风格	~100元	个人
LoRA微调	更深度调整	~500-1000元	个人
SFT监督微调	学习任务	~1000-3000元	小团队
增量预训练（小）	注入知识	~4000-10000元	小团队
增量预训练（中）	深度注入	~1-2万元	专业团队
增量预训练（大）	完整领域化	~4-6万元	专业团队
完整训练（四阶段）	领域特化	~7-15万元	专业团队

核心洞察：

QLoRA/LoRA微调：成本低（百元级），但只调整风格，不注入新知识
增量预训练：是注入知识的主要方式，成本取决于数据量
数据量是关键：10B Token（约500-1000本小说）需要~4000元；100B Token需要~4万元

当前建议

短期方案（个人，预算~千元）

优先RAG：先构建向量数据库，验证知识注入效果
QLoRA微调7B：注入风格/语感（成本~百元，时间~10小时）
混合使用：微调模型 + RAG补充

中期方案（小团队，预算~万元）

数据积累：整理高质量网文语料（目标10B Token）
LoRA微调70B：成本~千元，效果更好
小规模增量预训练：注入10B Token知识（成本~4000-10000元，时间~100小时）

长期方案（专业团队，预算~5-15万元）

大规模增量预训练：注入50-100B Token网文语料（成本~4-6万元）
SFT+DPO：监督微调+偏好对齐（成本~5000元）
强化学习：类似MGRPO，让模型学会自我评估（成本~1-2万元）
完整训练：四阶段训练，打造网文写作专用模型（总成本~7-15万元）

不同训练类型的成本对比

训练类型	目的	7B模型成本	时间	适用场景
QLoRA微调	调整风格/行为	~100元	~10小时	个人
LoRA微调	更深度调整	~500-1000元	~50小时	个人
SFT监督微调	学习特定任务	~1000-3000元	~20小时	小团队
DPO/RLHF	对齐人类偏好	~2000元	~50小时	需要质量
增量预训练（小）	注入10B Token	~4000-10000元	~100小时	小团队
增量预训练（中）	注入50B Token	~1-2万元	~200小时	专业团队
增量预训练（大）	注入100B Token	~4-6万元	~300小时	专业团队
完整训练	领域特化模型	~7-15万元	~500-1000小时	专业团队

核心洞察：

如果只是想调整模型的写作风格，LoRA足够，成本很低（千元内）
如果要注入大量领域知识，需要增量预训练，成本取决于数据量
10B Token ≈ 500-1000本小说，成本约4000-10000元
完整训练（如Tifa四阶段）约7-15万元，需要专业团队

待解决的问题

数据集构建：微调需要什么样的数据格式？
效果评估：如何量化评估微调效果？
知识边界：哪些知识必须微调，哪些用RAG就够了？
成本控制：如何在有限预算下最大化效果？