在线、近线、离线

1. online部分的主要任务是进行用户请求的实时处理，模型的在线服务。在线部分需要更快地响应最近的事件和用户交互，因此对于延迟的要求比较苛刻，一般都要求在100ms以内完成所有处理，这会限制所用算法的复杂性和可处理的数据量。正是online部分极高的响应延迟要求和相比离线、近线较弱的数据处理能力，要求online部分采用不同的高效的model serving方法去支持个性化推荐服务。
2. 基于数据消息队列，利用一些流计算平台进行数据的准实时处理。它居于离线和在线之间，既可以以分钟级别甚至秒级的延时来准实时地处理数据，也有一定的数据批量处理能力。nearline可以说是近几年大数据架构发展的重中之重了。当时Netflix开发了自己的流处理框架Manhattan，但现在已经是Flink一统天下的时候，Netflix内部的Flink平台每天会运行上千个不同的流处理任务。涵盖了特征实时计算、数据监控、BI、模型实时训练等等。越来越多的offline任务被替代，也许Kappa架构彻底替代Lambda架构的日子不太远了。
3. 存储离线数据，利用大数据查询工具进行数据查询和处理，离线模型训练。离线部分对于数据数量和算法复杂度限制很少，以批量方式完成数据处理，但是数据处理的实时性非常差，无法做到数据和模型的即使更新。

   介绍下论文

   OLIVER: A Jointly Learning Framework for Guided Abstractive Text Summarization
   生成式摘要较抽取式 更灵活、通顺，但很难控制，关键信息缺失。
   previous work：使用document关键信息作为guidance signal
   有两个可以提升的点：

• 增强guidance signal 和 source document之间的交互
• 优化document的表征空间

CPT和BART：LCSTS和Reddit-TIFU
全量数据；小样本。

实验：

• 全量
• 消融
• 小样本
• 人工评估

Limitation：

• 模板搜寻
• 对比学习负样本