LiveBot

1. LiveBot: Generating Live Video Comments Based on Visual and Textual Contexts
   LiveBot code: https://github.com/lancopku/livebot
2. Response to LiveBot: Generating Live Video Comments Based
   on Visual and Textual Contexts
   OpenNMT-Livebot code: https://github.com/fireflyHunter/OpenNMT-Livebot

LiveBot是微软亚洲研究院2019的文章，2020读过，觉得蛮有趣。前段时间，因缘巧合看了Response to LiveBot [看标题时候，还没意识到是给livebot找bug]，一瞬间又想起了这篇文章。因此放在一起，记录下，便于后面工作应用。

现在很多视频网站都有弹幕功能，方便观看者进行信息交互。LiveBot，俗称弹幕机器人，是基于b站数据，根据视频帧信息及对应的弹幕信息，再生产新弹幕的模型。

LiveBot 4种文本生成任务

图示四种文本生成任务：

1. image captioning：图文描述，输入视觉信息，输出文本信息；
2. vision question answering：视觉qa问答，输入视觉信息和文本信息，输出文本信息；
3. machine translation：机器翻译，输入和输出都是文本信息；
4. live commenting：LiveBot，输入视觉信息，以及依赖视觉信息的文本信息，输出文本信息。

4和2的最大区别，就是输入文本是否依赖视觉信息，更精确的说，2的输入视觉和文本信息是对齐的，而4的文本信息不仅与当前帧信息对齐，还可能是视频帧之前or之后【比如“前方高能预警”】的信息，或者是对之前弹幕信息的再反馈【比如弹幕的battle】，从逻辑上看更加复杂。

LiveBot的主要贡献

1. 首个做弹幕机器人任务的；
2. 构建了弹幕数据Live Comment Dataset，包含2361个视频及对应的895929条评论信息；
3. 提供了2种融合视频和文本信息的模型方案，fusion RNN和unified transformer model；
4. 提出了检索式retrieval-based的评估方案。

数据构造

数据收集
基于b站的搜索排行，爬取前10页的视频结果。搜索的信息包含宠物，体育，娱乐等19个类目。经过视频去重，过滤短视频，低质视频，以及弹幕少的视频的预处理后，共得到2361个视频。

对每个视频，抓取弹幕，及弹幕出现的时间戳。经过结巴分词后，一共得到895929条【弹幕，对应视频，弹幕出现视频时间戳】信息。

如下图所示，abc为三个时间对应的视觉信息，下面列表为每个弹幕出现的视频时间。比如，48s时，有弹幕“橘猫是短腿吗”。 LiveBot 数据集案例

训练测试数据
为避免过拟合，训练和测试数据中的视频是不重叠的。

LiveBot 训练数据详情

和其他数据集对比

LiveBot 常见文本生成数据集
YouCook和TACos-M-L：厨艺领域的数据集，针对行为描述；
M-VAD和MPII-MD：电影领域的数据集。
表格中的数据集，大部分数据量不大，且都是专有领域的数据，本文收集的数据从数据量，内容多样性，复杂度上，都有优越性。

数据分析

LiveBot 弹幕相似度分析
LiveBot 弹幕长度分布

1. 弹幕文本长度都偏低，大部分都低于5个词or10个字，这个长度的中文满足用户快速传递简短的信息的需求，符合弹幕的特性；
2. 相邻弹幕的相关性分析，对每个评论，选择相邻的20条弹幕，计算他们之间的tfidf，编辑距离，以及人工打分。同时，还对不同时间间隔[小于1s,1-3s, 3-5s,5~10s,大于10s]的评论对进行相关性打分，结果显而易见，时间间隔短的[相邻弹幕]，相关性强于非相邻弹幕。

模型结构

前文提到，LiveBot的弹幕，不仅仅和视频内容有关，还可能和其他弹幕内容有关。当前的弹幕，可以是对当前帧的内容理解，也可能是对之前或者之后视频内容的理解，还可以是和其他弹幕的互动。
对上述复杂的依赖关系，文中提出2种模型架构。

基本定义

type	concept
V	视频
f	视频的一帧
t	对应帧的时间戳
C	围绕这个时间戳的评论集
I	围绕这个时间戳的帧集合

对长视频来说，如果将一整个视频和所有弹幕信息作为输入，不是很合理。因此，文中对一个视频，只输入m个帧信息，以及时间t时的n个评论作为输入。具体可表示为：
视频帧集合：，时间间隔为1s
弹幕集合：
输出弹幕token集合：
输出的弹幕，时间戳和输入时间戳相近，内容可能和视频相关，或和弹幕相关。

Model1: Fusional RNN Model

LiveBot Fusional RNN Model

Fusional RNN Model由video encoder, text encoder和comment decoder组成。

Video Encoder

m个连续帧信息经过CNN编码后，经过双向LSTM，得到视频信息。

1. 每帧经过CNN得到向量：；
2. m个帧信息视为序列，经过LSTM，得到向量：

Text Encoder

对每个弹幕进行词级别的编码，再进行句子级别的编码。

1. 对弹幕分词，经过word-level LSTM：，得到的就是该弹幕的语义信息；
2. 将所有的弹幕信息经过sentence-level LSTM后，和视频信息做attention，得到融合文本和视频信息的表达：
   
   

Comment Decoder

生成的评论和周围的弹幕及相关的视频信息可以表示为：

生成的每个词可以表示为：

Model2: Unified Transformer Model

LiveBot UTM

顾名思义，就是将之前的LSTM转换成Transformer。
同样由2个encoder和一个decoder组成。

Video Encoder

1. ；
2. 经过CNN的所有帧向量集合：
3. 

Text Encoder

1.n个弹幕拼接，结巴分词，得到词序列：
2.

Comment Decoder

生成的评论和周围的弹幕及相关的视频信息可以表示为：

每个词的概率分布可表示为：

评价指标

弹幕内容多种多样，模型的产出不能直接找到对照的候选集，因此常见的BLEU，ROUGE的评测方案就不合适了。受对话模型的评估方法启发，文中提出了一种基于log-likelihood的候选集排序方案。当模型生成的评论有很高的分数时，那么在候选集排序时，模型就能将正确的弹幕排在前列。

候选集的选择

1. Correct：对应视频真人弹幕；
2. Plausible：50个和视频标题最相似的弹幕。视频标题作为query，基于tf-idf对训练集中的评论进行cosine相似计算得到。其中30个评论非Correct的，作为Plausible。换句话说，有30个弹幕不是对应视频的弹幕，而是基于相似计算从训练集检索得到；
3. Popular：频次最高的20个弹幕，比如‘2333’，‘太棒啦’，‘哈哈哈哈哈’，这类万金油评论，被视为不正确的评论；
4. Random：除了上述3种弹幕，还随机选择其他弹幕，将候选集扩充到100个。

排序指标

1. Recall@k：topk推荐中，真人评论占比；
2. Mean Rank：真人评论排序求平均；
3. Mean Reciprocal Rank：真人评论排序倒数求平均。

真人评价指标
评分标准[1,2,3,4,5]， 越高越好。

1. Fluency：流畅度；
2. Relevance：生成的弹幕和视频的相关性；
3. Correctness：生成的弹幕是真人弹幕的置信度。

实验

Baselines

1. S3S-I：使用CNN，输入只有视觉（相邻5帧视频）信息，输出评论；
2. S2S-C：使用LSTM，输入只有弹幕（相邻5个评论）信息，输出评论；
3. S2S-IC：使用LSTM，输入包含视觉和弹幕信息，分别编码，输出评论。

结果

LiveBot 各种指标结果
对baseline模型进行评测，结果显示，联合视觉和文本信息生产的弹幕优于comment only 优于 video only。 LiveBot 真人评估结果

####################################################
2020年囫囵吞枣的看完LiveBot[1]后，留下的印象是，以后做论坛式多模态生成时，可以尝试下。虽然知道作者有公开code，草草略过就罢。前两天看到Response to LiveBot[2]，作者复现了LiveBot公开的Unified Transformer model代码，发现模型结果比LiveBot的baseline差，进而发现代码漏洞，并重建了代码。
OpenNMT-Livebot code: https://github.com/fireflyHunter/OpenNMT-Livebot
####################################################

Response to LiveBot

1. Candidate Set Ranking [Issue #1-2]
   对候选集的排序，原code通过cross-entropy进行降序，而paper中提及到好的候选集应该排在前列，意味着cross-entropy应该升序。
   这个问题在github已被其他研究人员指出[GitHub Issue]。
   修改这个排序问题后，模型得分升了一点，和[GitHub Issue]的结果接近，但仍远低于LiveBot的baselines。

2. Candidate Scores [Issue #1-3]
   候选集得分计算，原code使用的是每个token的cross-entropy的和，而不是平均。这种计算方式对短文本很友好，作者发现，重排候选集，排在前面的很多评论都只有一个词。
   原code的计算：
   
   本文：
   
   #Valids为候选集的非padding的token数量。
   更新这个问题后，模型效果接近LiveBot的baselines。

3. Construction of the Plausible Set [Issue #1-4]
   构建Plausible候选集时，原文介绍是基于视频标题进行的检索。实际发现，是根据当前的上下文评论（围绕真实评论的评论）进行的检索。
   因为原始数据和生成的数据集的映射关系原文没有提供，因此无法基于原始数据重建新的数据集，只能根据原文方案，根据视频标题重建Plausible候选集。

4. The training/Testing Set [No duplicate]
   

   数据集比较
   前文提到，LiveBot构造了含有2361个视频和895929个弹幕的数据集，且训练集和测试集是无交集的。
   实际17771个评论有5436个重叠。虽然有些常用评论可以用在不同的视频下，但有些针对视频的特殊评论，也出现在训练集和测试集了；
   另一方面，在原始数据中，通过视频标题区分视频时，发现有38个视频重复多次。
   因此，基于原始数据，去重，再重建数据集，结果如上图。

每个issuse解决后的结果如下：

每个issue解决后的复现结果