雷锋网 AI 科技评论消息，近日，Stuart Axelbrooke 在 Kaggle 平台上公布了 Twitter 客户支持数据集公布，这个数据集包括来自大企业的超百万条推文与回复，大家可以利用这个数据集做很多有意思的工作。数据集的具体信息如下所示，编辑整理如下：
Twitter 客户支持数据集（Customer Support）是一个庞大的推文与回复语料库，这个数据集比较现代化，有助于自然语言理解和会话模型的创新，也对客户支持实践与影响效果的相关研究有所帮助。
背景
自然语言处理（NLP）目前仍然需要密集的编码方式，NLP 中的创新加速了对数据的理解，但是驱动这一创新的数据集与现在真正使用的语言不太匹配。
Twitter 客户支持数据集里有 Twitter 上大量的用户和公司的客户支持中心之间的对话语料库，这个语料库的语言主要是英文，比起其他会话文本数据集有三个主要优势:
聚焦——这个数据集里的数据主要是用户联系客户支持中心来解决特定的问题的对话，他们讨论的问题类型相对来说较少，当与 reddit 语料库（reddit Corpus）等不受约束的对话数据集相比，这种情况更甚。
自然——这个数据集里的用户覆盖面要比 Ubuntu 对话语料库（Ubuntu Dialogue Corpus）更广。比起 Cornell 电影对话语料库（Cornell Movie Dialogs Corpus），这个数据集中有更多更自然和更常用的输入文本。
简洁——由于 Twitter 上对话的简洁性，客户支持中心会回复得更自然，关于问题和解决方案的描述都会会有过多废话，这也便于利用循环网络，可以使得信息的限制相对较低。
有意思的问题
这个数据集的大小和覆盖范围激发了许多有意思的问题:
我们能预测公司客户支持中心的回答吗?考虑到每个公司处理的问题都是在某个范围内，答案看起来是肯定的！
用户的请求会过时吗?最好的公司反应速度有多快，与最糟糕的公司相比呢？
在局部聚类（topical clustering）时，能学习到高质量的稠密嵌入（dense embedding）或相似性表现吗?
语气是如何影响客户支持中心与用户的对话的?说对不起有用吗?
内容
数据集是 CSV 格式，每一行为一条推文。对列的描述如下所示，每段对话至少包含一条用户请求和一条公司回复。可以用 inbound 字段来计算哪个用户 ID 是公司用户 ID。
tweet_id
推文 ID，匿名，每条推文只有一个此类 ID，response_tweet_id 和 in_response_to_tweet_id 中有引用到这个 ID。
author_id
用户 ID，匿名，每个用户只有一个此类 ID，数据集中的@被与用户相关的用户 ID 替换掉了。
inbound
用户的请求推文是否被那些在推特上进行客户支持的公司“归档（inbound）”。该特征在训练会话模型时的数据重组阶段非常有用。
created_at
发推文的日期和时间
text
推文内容。电话号码和电子邮箱等敏感信息用__email__等类似句段来掩盖。
response_tweet_id
与请求推文相关的回复推文 ID，用逗号隔开。
in_response_to_tweet_id
该条推文所回复的推文 ID（如果存在）
数据集下载地址：https://www.kaggle.com/soaxelbrooke/customer-support-on-twitter
via：Kaggle
相关文章
