storyline.md

问题描述

用一句话描述你想解决的问题，并添加要点作出解释

• 问题的一句话描述：TODO
• 解释1：TODO
• 解释2：TODO

问题重要性

写出这是一个重要问题的理由，并给出论据。

• 论据：文献，博客，新闻报道，自己做的实证研究等

• 有文献：一句话总结文献的论证

• 文献不要太少（尽量避免一篇论文的孤证），尽量选取 CCF-A 类会议/期刊

• 没有文献：

• 在原理上论证重要性

• 针对性地设计实证研究/实验/问卷调查来获取支撑数据

• 理由 1：： TODO

  • 论据1 ：TODO
  • 论据2 ：TODO

• 理由 2：： TODO

  • 论据1 ：TODO
  • 论据2 ：TODO

问题重要性：实证研究（选填）

设计实证研究/实验/问卷调查来获取支撑数据。

• 收集到的数据尽量简单直观

• 收集数据的方法能够反映真实世界的普遍情况

• 收集什么数据： ： TODO

  • 什么结果能证明问题的重要性：TODO

• 收集数据的方法： ：TODO

• 收集数据的方法为何能够反映普遍情况：：TODO

• 收集数据的方法可能的缺陷（引入偏见/误差）：

  • 偏见/误差 1： TODO
    • 如何避免：TODO

背景知识

给出相关技术的背景介绍。

• 文章用到的理论、概念等、

• 区别于相关工作，背景知识主要是教科书上的内容

• 背景知识 1：TODO

  • 解释 1：TODO
  • 解释 2：TODO

• 背景知识 2：TODO

  • 解释 1：TODO
  • 解释 2：TODO

解决问题的现有相关方法

列出解决这一问题的现有相关方法。

• 直接方法： 直接针对这一问题

• 间接方法： 针对其它问题的方法稍作调整可以适应这一问题

• 其它问题和这一问题有共同性/相似性

• 第一类方法：

  • 直接方法：TODO
    • 方法的局限：TODO
    • 局限的根本原因：TODO

• 第二类方法

  • 间接方法：TODO
    • 方法的局限：TODO
    • 方法局限的根本原因：TODO

现有相关方法的共性缺陷

总结现有相关方法的共同的根本的缺陷。

• 最好是 1 个，不超过 3 个
• 导致缺陷的根本技术原因从思想上或者大的原理上讨论
• 避免讨论具体算法和工程实现
• 技术原因：如果这个缺陷不被解决，为什么这个问题就无论如何也解决不好
• 不是这个缺陷为什么困难
• 共性缺陷 1： TODO
  • 技术原因 1：TODO
  • 技术原因 2：TODO

解决共性缺陷的难点/挑战

列出解决现有相关方法的共性缺陷的难点/挑战。

• 解决共性缺陷需要技术满足某些需求/达到一定指标，目前无法满足/达到：

• 技术需要资源太多/理论复杂度太高/存在 open problem

• 技术需求之间存在矛盾

• 技术需求： TODO

• 技术限制 1：TODO

  • 解释：TODO

• 技术需求矛盾 1：TODO

  • 解释：TODO

Insights

针对现有相关方法的共性缺陷及其技术原因，提出新的 insights。

• 1-3 条 insights，最好是 1 条，不要超过 3 条
• 避免算法/代码等技术细节

Insight：地球绕太阳的轨道是一个椭圆，太阳在椭圆的一个圆心上

• 该 insight 能解决现有方法的共性缺陷并克服相关困难的原因：模型更精确

新的 Insights 的本质区别

归纳出新的 insights 和现有方法的思路的本质区别。

• 1-3 点区别，最好是 1 点，不要超过 3 点
• 避免具体的算法设计
• 强调本质区别
• 采用不同的机器学习模型/方法不算本质区别
• 区别 1： TODO
  • 解释 1：TODO
  • 解释 2：TODO

新的 Insights 的技术难点

归纳出新的 insights 在实现时需要解决的技术难点。

• 技术难点：整体上的困难，如效率、准确性等

• 技术难点 1： TODO

  • 解释：TODO
  • 本工作技术方案：TODO

• 技术难点 2： TODO

  • 解释：TODO
  • 本工作方案：TODO

新的 Insights 的正确性：Insight 1

从概念上解释新的 insight 1 的正确性。

• 避免算法/代码等技术细节
• 理由 1：TODO
  • 解释 1：TODO
  • 解释 2：TODO

Motivating Example

给出一个简单示例。

• 示例能说明现有技术的共性缺陷
• 示例能体现新的 Insights 能解决共性缺陷
• 示意图/代码：TODO
• 具体地说明现有技术的共性缺陷：TODO
• 具体地解释新的 Insights 能解决共性缺陷：TODO

新的 Insights 下解决难点/挑战的思路

基于新的 Insights，针对前面指出的难点/挑战，提出解决思路。

• 列出关键技术点

• 是 Insights 的细化

• 难点/挑战 1：TODO

  • 解决思路 1/关键技术点 1：TODO
  • 解释：TODO

• 难点/挑战 2：TODO

  • 解决思路 2/关键技术点 2：TODO
  • 解释：TODO

设计方案：Overview

• 架构图：TODO 体现新的 Insights 的组件：TODO 架构输入：TODO 架构输出：TODO
  • 组件 1：TODO
    • 功能：TODO
  • 组件 2：TODO
    • 功能：TODO

设计方案：组件1

• 输入：TODO

• 输出：TODO

• 技术挑战 1：TODO

  • 解释： TODO

• 解决挑战的重要性（不解决挑战的影响）：TODO

• 现有相关技术方案（每种方案用一句话总结）：

  • 方案 1：TODO
  • 不能解决这一挑战：TODO

• 本工作技术方案：TODO

实验：架构设计有效性

实验验证新设计方案的有效性。

• 指标能够正确度量新设计方案的优势与额外代价

• 请对每个指标的合理性进行讨论，尽量采用其他顶会论文用过的指标

• 预期新架构有优势的方面以及度量优势的指标

  • 优势 1：指标 1
  • 优势 2：指标 2
  • 优势 3：指标 3

• 优势指标正确性：

  • 优势指标 1：原因 1
  • 优势指标 2：原因 2

• 预期新架构会付出额外代价的方面以及度量代价的指标：

  • 代价 1：指标 1
  • 代价 2：指标 2

• 代价指标正确性：

  • 代价指标 1：原因 1
  • 代价指标 2：原因 2

实验：架构设计有效性

实验验证新设计方案的有效性。

• Baselines 能够代表现有相关方法的普遍情况

  • 每一类现有相关方法都需要有至少一个 baseline

• Baseline 开源：配置

• Baseline 不开源：复现

• 选取的 baselines：

  • Baseline 1：原因
  • Baseline 2：原因

• Baselines 的实现与正确性：

  • Baseline 1：实现与正确性
  • Baseline 2：实现与正确性

• 排除的 baselines 与原因

  • 排除的 Baseline 1：原因

实验：架构设计有效性

实验验证新设计方案的有效性。

• Dataset/Benchmark 能够公平地评测 baselines

• Dataset/Benchmark 公开：如何使用

• Dataset/Benchmark 不公开：如何构造，为什么合理

• 选取的 datasets/benchmark：

• datasets/benchmark 1：描述/原因

• datasets/benchmark 2：描述/原因

• datasets/benchmark 的使用：

  • datasets/benchmark 1：配置
  • datasets/benchmark 2：配置

• 排除的 datasets/benchmark 与原因

  • 排除的 dataset/benchmark 1：原因

实验：架构设计有效性

实验验证新设计方案的有效性。

• 实验方法能够反映真实世界的普遍情况

• 典型偏差 1：没有多次实验计算平均值和方差，与baseline比较没有计算统计显著性

• 典型偏差 2：baseline没有覆盖主要典型相关方法

• 典型偏差 3：实现未开源的baseline，没有讨论如何保证实现的正确性

• 实验 1：TODO

  • 实验方法为何能够反映普遍情况：TODO
  • 可能的偏见/误差：TODO
  • 避免偏见/误差的方法：TODO
  • 对于 baselines 的公平性：TODO

• 实验 2：...

实验：架构设计有效性

实验验证新设计方案的有效性。 列出实验数据

• 优势：
  • 优势 1：指标数据 1，图或表，一句话总结实验结果
  • 优势 2：指标数据 2，图或表，一句话总结实验结果
  • 优势 3：指标数据 3，图或表，一句话总结实验结果
• 代价：
  • 代价 1：指标数据 1，图或表，一句话总结实验结果
  • 代价 2：指标数据 2，图或表，一句话总结实验结果
  • 代价 3：指标数据 3，图或表，一句话总结实验结果

实验：讨论现有方法性能不够好的技术原因

现有方法的实验可能和其论文中的表述有出入，请详细分析解释原因 讨论现有方法效果不好的原因，为什么不好，你的实验中和他论文的实验中有什么不同，这些不同怎么导致了现有方法性能不好，这些不同是否是由于你的insight导致的

• baseline 1（SOTA） 性能不好： 技术理由1：一句话总结
• baseline 2（Pruned） 性能不好： 技术理由1：一句话总结

实验：Insights 正确性

实验验证 Insights 的正确性。

• 分析优势 1：是由 insights 导致的某种现象引起的
  • 现象：TODO
  • 现象观察实验：TODO
    • 实验方法：TODO
    • 实验方法普适性：TODO
    • 实验方法正确性：TODO
  • 现象观察结果：观察到的数据，图或表，一句话总结

实验：Insights 正确性

实验验证 Insights 的正确性。 证明 insights 的风险/局限能够被克服，或虽然存在但在实际情况中影响不大

• Insights 风险/局限 1：TODO

  • 能够被克服/不能被克服但对实际效果影响不大

  • 实验证明：TODO

    • 实验方法：TODO
    • 实验方法普适性：TODO
    • 实验方法正确性：TODO

  • 实验结果：图或表，一句话总结

实验：重要模块对实验结果的影响

实验测量重要模块对实验结果的影响，证明各个模块的重要性。

• 重要模块 1：TODO
  • 实验方法：TODO
  • 实验方法普适性：TODO
  • 实验方法正确性：TODO
  • 实验结果：图或表，一句话总结

关于实验部分的典型拒稿理由

• Does not follow accepted evaluation standard. The evaluation standard in the fuzzing community (Klees et al.'s "Evaluating Fuzz Testing") recommends statistical significance tests to compare competing tools, yet the authors did not perform any such tests in their evaluation. Moroever, the metric of "unique crashes" is widely known to be over-counted and unreliable, yet the authors list it as a key evaluation metric in comparing their approach to others.
• Unclear experimental setup. The paper claims that competing state-of-the-art tools fail on a large percentage of benchmarks, yet the authors provide only vague explanations of the supposed causes of failures. Recent literature shows that these tools do in fact support many of these benchmarks, suggesting there are discrepancies in the authors' experimental setup. Moreover, at least one of the competing tools has been obsolete for several years, and the authors fail to include the state-of-the-art successor in their evaluation.