舆情行业一个很大的难点其实是舆情事件的定义，这个“定义”指的并不是概念上的，而是信息技术上的。所谓舆情分析，就是针对某一事件大量 掌握了网络信息资源(包括媒体舆论报道、主流网 站发布、论坛持续关注、微博、微信广泛转发、大 Ｖ 或有一定身份的公众人物、事件当事人发声等)的 基础上遵循一定的理论规律、充分利用科学的方法、技术手段和信息化工具对采集到的内容进行 梳理运用抽样、分类等形式对该事件做出一个 全面的、综合性的评价同时能够及时预测事件的 发展态势形成舆情分析报告并提出合理化的建议以供决策.
那么，舆情分析的流程可以大概分为，信息获取-信息清洗-数据统计型分析-数据挖掘型分析-得出用于支持决策的结论或深加工数据。在舆情系统的社会化宏观分析，即常规监测中，通常只是对关键词进行大规模监测以获取最粗的线索，在这一步关键词之间通常只是或的关系，并且数量大，也就是监测结果成百上千，导致人工二次研判分析的任务量和难度都不小。但是常规监测只是线索发现，也就是大海捞针，对召回率和准确率都有容忍度，而事件分析则不同，对两项数值都有较高的要求，否则分析的结果可能会差别巨大。
然而市面上绝大多数的舆情系统的专题监测（一般专题监测、事件监测、主题监测功能都类似）的现状是什么样子呢？对于计算机系统，通常从宏观来说，就是输入-计算-输出，所有功能基本都离不开这个简单的逻辑。所谓事件监测也是如此，输入指用哪些条件来圈定事件，计算指对符合前述设定条件的数据做什么计算，输出则是以何种形式展示什么数据已提供结果给用户。目前大多数国内舆情系统的现状是：
事件监测输入条件-现状：支持多组关键词，每组间支持多个关键词，类似搜索引擎，但是组的数量更多，最终形成复杂的查询语句，并且关键词会在搜索引擎或特定网站中进行检索和收录以提高召回率。时间维度，可以限定时间范围，通常以发布时间为准。数据范围，可以限定哪些网站或平台来源。附加条件，例如词距离值，对标题和正文的匹配倾向，主体词、事件词、地域等限制条件。
事件监测数据计算-现状：通常，关键词进入系统后，会先在目前的数据库（一般是ES）中进行查找，找到符合的数据并展现。但是好的系统会同时启用多种手段提高数据召回率，例如搜索引擎、特定渠道的文章搜索等等。每篇文章都会进行细致的NLP语义分析以用于更详细的挖掘用，但是由于算力和技术问题，大部分NLP计算都用于标签分类、实体提取、依存文法关系、情感分析等基本提取上了，并没有形成很好的协同效应。
事件监测输出-现状：目前由于各方面成本限制，大部分市面产品主要以统计性图表输出为主，包括日数据量曲线图、来源分布柱状图、传播路径树形图等。
这就是目前的大概现状，这样导致的问题是什么呢？一个事件在网络上传播的版本会很多，标题和正文都会有很大的变化，所以直接找出他们的共性是很难的，通过定义关键词规则，实际上是将其中最大的共性找出来，但是词向量间关系无法详细定义，关键词规则目前都是布尔表达式，也就是与或非关系，仅此而已了。这就各项指标极大地受制于关键词规则设置的水平高低，非常不稳定。召回率指标在设置关键词范围广的时候，会很高，但是监测到的无用数据也会很多，需要筛选出来；而准确率则完全依赖关键词规则，一字之差都可能导致大幅度降低甚至驴唇不对马嘴的情况发生。而这一切已经成为行业通病，却无力突破。
一种可能性的尝试是通过事件文章出发，首先可以被认为的是，当输入一篇文章，这篇文章是人工筛选的，可被认为是100%匹配该事件的文章，那么系统把它作为输入开始匹配全库数据内所有与该文章近似，或相关的文章，所有结果集在某个阈值之下，均视为该事件的相关文章。这样的话，就可以得到关于该事件的一个文章集合，每一个输入该集合的新文章，就像新的节点一样，可以扩散并发散找到和它非常近似的文章。这样的话，该事件的监测的准确率会高的惊人，完全用阈值来调控便可。唯一的问题是召回率，但是通过不停输入人工发现的新文章，并且通过算法技术扩充已有文章的关联文章，可以更好地提高召回率。例如，通常事件网络刚发布的时候，文章版本只有几种，很容易统计出来词之间的关联，尤其是主题、地域、人名、组织和描述关系，但是后续出现的文章开始变体，描述关系也开始变化，这个时候则需要利用算法，发现主体间的关联，通过隐性知识而非人工提炼的显性知识来表达这个事件。最终通过算法总结并生成检索语句，从库内发现事件关联文章。这样的话，事件监测便不再依赖关键词的组合了，转化为更高阶的输入条件。而且这个条件应该是动态迭代的，随着事件的发酵，条件不能一成不变，要跟上变化。
