任务介绍

评测任务及评价指标

1、评测任务

以单个词为答案的填空类问题、用户提问类问题。具体任务形式见下方的详细介绍。

2、评价指标

答案准确率，即只存在“对”或“错”（Exact Match）。若答案准确率相同时，交由人工对错误样例进行人工评判，赛后由评测方公开人工评测的标注结果。

3、系统要求

本次评测不限制评测系统的具体形式，可以使用模型融合（Ensemble）等方法，但参赛者需要注明，并且需要同时提交单模型的效果。若参赛团队不提交单系统的效果，将被视为无效系统，成绩将作废。

4、数据要求

本次评测以官方提供的数据为主，但并不限制训练数据的范围。需要注意的是，若参赛方使用了其他数据需要注明。对于违反违反参赛条例的参赛队伍，评测委员会有权取消该参赛队伍的评奖资格。

5、评奖方式

多系统融合、单系统混合排名，按照测试集答案准确率降序排列（2个Track分别排名）。评测委员会鼓励参赛队伍更侧重于单系统模型效果的优化（即算法本身的优化），经委员会讨论：单系统效果最好的团队将会额外获得评测方颁发的证书。

评测方向

本届评测主要由填空型问题、用户提问类问题两个评测方向组成，请见下方表格中的详细描述。

【说明】 1）在填空类任务中，训练集/开发集/测试集的格式和形式完全一致，参赛队伍只需专注于系统本身的优化，而无需考虑数据是否匹配的问题。 2）然而，在用户提问类方向上，我们并没有提供与开发集和测试集相匹配的训练数据。相比于填空类问题的评测方向，在本任务中参赛队伍需要考虑如何从填空类问题转化成用户提问类问题。 3）填空类、用户提问类任务共用同一个训练数据集合（填空型）。 4）相关数据的格式请见下方评测数据-数据格式部分。

评测数据

1、数据来源

所有数据均来源于哈工大讯飞联合实验室（HFL）收集的“儿童读物”阅读材料。

2、数据规模

3、数据格式

1）公共训练集（填空类、用户提问类）
篇章：由若干个连续的句子组成的一个文本段落，但文中缺少某一个词，标记为XXXXX
问题：缺少的词XXXXX所在的句子
答案：缺少的词XXXXX
【举例】
doc_and_query文件: 分隔符" ||| "之前的数字表示的是句子序号，XXXXX表示文中缺少的词。在本例中，前1~5行是篇章的部分，最后一行（即例中第6行）包含问题ID（用于索引）、问题句和答案。

1 ||| 工商 协进会 报告 ， 12月 消费者 信心 上升 到 78.1 ， 明显 高于 11月 的 72 。
2 ||| 另 据 《 华尔街 日报 》 报道 ， 2013年 是 1995年 以来 美国 股市 表现 最 好 的 一 年 。
3 ||| 这 一 年 里 ， 投资 美国 股市 的 明智 做法 是 追 着 “ 傻钱 ” 跑 。
4 ||| 所谓 的 “ 傻钱 ” XXXXX ， 其实 就 是 买 入 并 持有 美国 股票 这样 的 普通 组合 。
5 ||| 这个 策略 要 比 对冲 基金 和 其它 专业 投资者 使用 的 更为 复杂 的 投资 方法 效果 好 得 多 。
<qid_1> ||| 所谓 的 “ 傻钱 ” XXXXX ， 其实 就 是 买 入 并 持有 美国 股票 这样 的 普通 组合 。

answer文件: 每行包括问题的ID以及对应的答案，以" ||| "分隔符分割。

<qid_1> ||| 策略
<qid_2> ||| 新闻
...

2）填空型问题（开发集和测试集）
填空型问题的开发集、测试集和公共训练集的格式一致。
具体形式请参考公共训练集的格式说明。

3）用户提问型问题（开发集和测试集）
篇章：由若干个连续的句子组成的一个文本段落。与填空型不同的地方是，用户提问型问题的篇章是完整的。
问题：由人工提问的问题
答案：问题对应的答案（以单个词为答案）
注意：格式与填空型问题相同。
【举例】
doc_and_query文件:

1 ||| 工商 协进会 报告 ， 12月 消费者 信心 上升 到 78.1 ， 明显 高于 11月 的 72 。
2 ||| 另 据 《 华尔街 日报 》 报道 ， 2013年 是 1995年 以来 美国 股市 表现 最 好 的 一 年 。
3 ||| 这 一 年 里 ， 投资 美国 股市 的 明智 做法 是 追 着 “ 傻钱 ” 跑 。
4 ||| 所谓 的 “ 傻钱 ” 策略 ， 其实 就 是 买 入 并 持有 美国 股票 这样 的 普通 组合 。
5 ||| 这个 策略 要 比 对冲 基金 和 其它 专业 投资者 使用 的 更为 复杂 的 投资 方法 效果 好 得 多 。
<qid_1> ||| 哪 一 年 是 美国 股市 表现 最 好 的 一 年 ？

answer文件:

<qid_1> ||| 2013年
<qid_2> ||| 奥巴马
...

代码示例

以python脚本为例，所有数据（填空型、用户提问型）均可如下处理，代码仅供参考。
假设answer文件已被读入至dict变量answer_dict中（以Query_ID为key, Answer为value），且不考虑篇章中的分句信息（将所有篇章中的句子合成一个“长句”）。

import re
DATA    = []
doc     = ""
for line in data:
    line = line.strip().split(' ||| ')       # 使用分隔符进行切分
    if re.search('^<qid', line[0]) :         # 判断是否以"<qid"开头
        qid      = line[0]                   # query的索引ID，用于查找答案
        query    = line[1]                   # 问题
        answer   = answer_dict[qid]          # 用qid查找答案
        DATA.append(doc, query, qid, answer) # 添加到DATA列表中
        doc = ""
    else:                                    # 该行是篇章部分
        sent_id  = line[0]                   # 句子序号
        sent     = line[1]                   # 句子
        doc     += sent + " "                # 将该句子连接到doc

4、预处理

1）为了让参赛队伍更专注于阅读理解技术本身的比拼，本次评测提供的所有数据（训练、开发、测试）均经过中文的分句、分词处理，处理工具为哈工大LTP平台。然而，参赛者也可使用其他分词工具处理数据。但考虑到训练、开发、测试集的一致性，不建议参赛者对训练集和开发集重新进行分词。
2）数据中的分句结果仅供参考，参赛者可自由利用。如果不需要分句信息，则可以将所有的分句拼接成一个完整的篇章。

5、评测数据发布

在评测期间，相关数据不对外公开。
评测组委会通过内部邮件与参赛队伍沟通，并提供数据获取的方式。
赛后，评测方将所有训练、开发、测试数据公开，供他人研究使用。
如有问题，请咨询评测委员会：cmrc2017@126.com

评测流程

为了保证测试的公平性，最终的参赛系统将在隐藏的测试集上得到最终比赛成绩。因此，本次评测要求参赛者提交评测系统，由评测委员会运行评测系统得出测试集上的效果。
由于本次参赛队伍较多，为了保证评测流程的顺利进行，请仔细阅读以下内容。

1、测试服务器的基本配置

1）硬件配置

2）软件配置

【说明】
1）请参赛队伍尽量选择开源且主流的算法框架及运算平台，确保参赛队伍的评测系统可以在评测服务器上正常运行。
2）提交的评测系统除上述底层软件配置外，必须是自包含的（self-contained）。即，除了必须通过安装才能使用的第三方库之外，参赛队伍必须将其他第三方库包含在提交的系统中（大多数python的库可以直接调用，而不需要安装，例如Keras等）。
3）在上述软件配置表格中，如有特殊版本需求以及其他必要软件的安装需求，请在提交系统验证开发集之前（2017年7月1日之前）告知会务组。若因参赛队伍未及时告知配置需求而影响整个评测进度，评测委员会有权降低该参赛单位的验证优先权，后果由参赛单位自负。
4）6月上旬开始，评测委员会将征询各个参赛队伍的环境配置需求，请密切注意邮件通知。

2、接口要求

参赛单位提交的系统的接口必须符合评测委员会的要求，否则评测委员会有权拒收。
提交的可执行程序需满足如下命令格式：

./run.sh [dev-file] [predict-file]

其中，
run.sh：程序运行脚本。所有运行步骤都应包含在该脚本内。
dev-file：输入文件的文件名，用于开发集、测试集的输入。文件格式见填空型或用户提问型的doc_and_query文件。
predict-file: 输出文件的文件名，用于输出预测结果。文件格式见填空型或用户提问型的answer文件。

3、提交系统验证开发集（2017年7月1日 ~ 2017年7月31日）

为了避免最终提交系统时出现问题，参赛者可在上述时段提供一个可运行的系统提交给评测方，由评测委员会在开发集上验证结果并与参赛者进行比对，保证结果的一致性。要求所有参赛队伍必须通过开发集的验证，未验证的系统将被取消参赛资格。

【流程】
1）参赛者打包评测系统并提交给评测委员会（提交方法另行通过邮件通知），并报告该系统在开发集上的效果。
2）评测委员会检查系统是否有效，并在开发集上测试效果，与参赛者报告的效果进行比对。
3）在开发集验证成功（即实际测试效果与参赛者报告效果一致）的基础上，评测委员会继续在测试集上测试，查看是否能够跑通程序。需要注意的是我们并不会告知参赛队伍在测试集上的效果，仅告知是否能够正常跑通。

【注意】
1）若上述流程中任何一个流程出现问题，评测委员会及时告知参赛者并要求参赛者及时修复错误。
2）为了保证每个队伍均有足够的时间和机会验证系统，要求每个队伍只有2次验证系统的机会，每跑通1次记1次机会（未跑通则不计入）。希望参赛队伍仅在参评系统有较大软硬件配置变化的时候再使用第二次验证机会。
3）原则上在上述时段提交的系统应与最后提交的系统相差不大（即软硬件配置没有显著变化），以保证提交最终系统时仍能够跑通。若软硬件配置有较大变化，参赛方有义务及时告知评测委员会做出调整。

4、提交最终评测系统（2017年8月1日 ~ 2017年8月3日）

参赛者正式提交最终的评测系统，评测委员会在隐藏测试集上测试效果。
参赛队伍需保证系统的软硬件配置上没有显著变化。如有显著变化，应在上一时段（验证开发集时段）及时通知。由于参赛队伍未及时通知造成无法在测试集验证，后果由参赛队伍自负。

5、撰写系统描述文章（2017年8月18日前）

参赛队伍需要对参赛系统进行详尽的描述，提交评测汇报PPT的初稿（在此时间点之后仍可以继续修改）。参赛队伍可从数据处理、模型选型、实验对比、结果分析等角度对评测系统进行描述。相关实验结果可汇报开发集上的效果供其他队伍参考。
具体模板和要求后续另行通过邮件通知。

联系我们

如果有任何与本次评测相关的问题，请随时联系会务组。
评测会务组邮箱： cmrc2017 [at] 126 [dot] com