Video2Article: 蜗牛与优化段落处理（4）

前情回顾：

这其中有一部分是尚未涉及的，即如何从文本生成段落？

通常来说，在使用 ASR 服务之前，会将语音文本按照音频强度做切分，分成若干个小段，这样能提升预测的准确率。同时这种方式也就意味着，转录得到的文字，通常是碎片化的句子。如果在赶上说话者大喘气，那么文本则更加细碎。

而且，大部分情况下，得到的文本都不会有明显的标点符号。

为何需要分句分段？这取决于拿到文本后要做的事情，如果是想通过文本进行总结，那其实只要文字就够了，因为文本的 token 已经包含足够的总结所需信息量。但若是要将其转换成篇，那就必须分句分段，不然就会像看文言文一样很痛苦。

而分句分段，则需要从加标点符号开始，再根据文字的意思理解，在合适的地方去进行分割。靠规则去做这件事情是很困难的，最后还是求解于能理解文本的大语言模型。

我们可以构造一个“语篇重写”的任务，让其将一大段没有标点符号的碎片化句子，进行合理断句，并自动分段。只需要根据不同的模型写一段提示词即可。

方案从理论上是说得通的，实际的困扰发生在工程上。由于输入的文本是不定长的，越长的文本对上下文窗口的挑战就越高。基本上，这个任务依赖于把输入从头扫一遍，在其中边做处理边返回，画示意图如下：

这时候就到了真正考验模型上下文理解能力的时候了，某个模型号称上下文有 8K，并不意味着你可以给它塞进去 4K 的数据。如果针对这种特长上下文没有特殊优化的话，可能会出现突然的模型输出截断，任务性能下降等各种奇怪的情况。

虽然我相信，技术随着时间的发展，其能实际支持的上下文窗口肯定会越来越长。但出于工程上的考虑，这里还是设置了一个较小的文本输入上限（目前设定为 2K），这个文本量大约就是 5~6 分钟左右口播的内容长度。

从工程现状上看，无论如何都会对文本输入有上限要求，这就需要对原始文本进行切分。

那应该如何切分呢？理想的分割点，应该是落在段落的分割点上。但是在语篇重新任务前，仅根据规则是很难确定合适的段落分割点的（有一些启发式的方法，但此处仍考虑所有启发式方法均失效的情形）。

如果分错的话，会带来什么后果呢？其实无外乎就把一整段本来连续的话，分解成了多段而已，这其实也不会对下游任务产生什么严重影响。但是在文章很长的时候，这些“异常”的出现对于全文的理解还是会有些影响的。

此外，由于文本被截断，大语言模型在语篇重写时就可能会出现幻觉，自己脑部生成一些额外的内容。这些额外的内容再与后面正常的文段相拼接时，就可能引入一些意外的不在原文中的文本，应当尽量减少这种情况的出现。

针对幻觉情况，我使用了一个小 trick，即在提示词后方加入 “(… 未完待续)” 的字样，测试后发现能一定程度减少幻觉补全的出现。

对于更广义的分段问题，我开始使用回退的思想。

以前有个奥数题是这么出的：

井深七尺，蜗居其底。昼行三尺，夜复坠二尺。试问蜗牛几日可离井而出？

受此启发，这个方案的想法也很简单，既然自动分段的最后一段可能是残缺的，那么倒数第二段应该是完整的吧，毕竟这是更早生成的。于是我在生成的文本基础上，回退删除最后两段的内容，即可大概率保证文本分段的正确性。

灵魂画手示意图如下：

由于这个回退操作，每次都会产生 15% ~ 25% 的 token 损失。因回退而损失的 token 会加入到下次任务中，于是会产生额外的开销。所以这更多属于效果与成本之间的权衡之计。

同时，由于这个损失较大，所以在切分原始 token 时也需要同时考虑到这一点，预留空间。因此在下一个版本实现中，会将文本切分上限改为 2.5K，这样即使损失 20% 后仍然保持在 2K 附近。

上述实验是在 8K 的上下文窗口中进行的，但是有人会说比如 GPT-4 已经能支持 128K 的上下文了，可以一次性装下内容就没有必要分段了。

然而，这个 128K 的上下文其实是针对输入，输出的话，仍旧限制 4K 的 token 内容，可以参考如下官方文档。

当然，也不是没有办法突破这个限制，只需要接着对话上下文输入“continue”即可继续。但是这种做法也会加重复杂度，而且带来成本的上升。在输出上下文限制被突破以前，分段依旧是必要的。

通过这种分拆优化段落生成的方式，理论上可以应对很长上下文的情形。同时通过回退操作，可以规避一些由于分割不精准带来的语义割裂问题。在回退的具体执行过程中，还会有一个步骤，即段落文本与时间轴字幕的对齐问题。这个需求在后期生成文本后也同样存在，如果文段有时间轴范围，就可以较为轻松地在视频中进行跳转了。