当前位置: 首页 > news >正文

近期文章方向调研:模糊本体、本体匹配、加密流量

最近在考虑两个点的工作,分别是模糊本体和本体对齐,但都处于比较卡壳的状态的。
再考虑到现实情况,就是安全专业和以后就业需求,看下加密流量的文章,就我目前的了解来说,加密流量的文章主要还是用数据分析的或AI的技术来做的,只不过分析对象是加密流量。从应用型论文的角度来说,既需要了解应用场景,有需要熟悉分析技术,AI是分析技术,安全是应用场景,很多论文都是这个路数弄出来的,不能完全说灌水,有些确实有用。不是看了就一定要基于这个方向弄文章,只是先了解一下,有充分认识之后再做后续考虑。

初步了解和动机

由于我做的是安全领域本体这种比较小众的方向,得益于创新资助计划才沿着本体工程这个思路做了几篇文章。但是如果没有创新资助的话,我曾经考虑两个事。第一,沿着UCO1的思路,建模模糊安全本体(话说为什么我弄的论文阅读博客能在bing学术上搜到,好尴尬);第二,做安全本体的融合,也就是本体对齐(匹配)。这两个方向都只是想过,没有实际去做(感觉太难/懒)。

  • 模糊本体:考虑对知识的不确定性和概率建模,按照UCO的展望描述,安全领域确实需要这样的模糊本体。我个人觉得的难点是:1)高质量的建模太困难,现在哪怕是UCO,也只是少数的领域建模尝试,如果想要作为公开的本体资源文章的话(resource paper),很难;2)实用性验证的说服力,除了持续说本体的推理有可解释性之外,在实际安全应用上,很难看出它的优势。
  • 本体对齐:做本体库,很自然想到不同来源的本体库的融合问题,我曾想做安全领域的本体对齐,但发现行不通。我认为的难点是:1)和我做安全本体工程类似,最难说的一点就是如何说明我的方法适用于安全领域(特定领域),实际上我并没有太多对安全领域的特殊考虑。便陷入这样的矛盾中,若要做领域特定的方法,那就必须对该领域有特别的优化,否则,就是通用方法,能够PK过别人的方法;2)目前本体匹配是一个相对较卷的方向,有OAEI的比赛,想做出能发表的文章,那就要多接触前沿的机器学习深度学习这些(我这些基础目前还不太行,要补上)。因为我是网安专业,不能做完全抛离网安的方向,但现在不用受这个桎梏了。3)对1补充,经过初步了解,一个方法的好坏,不同领域有其差异性,比如某OAEI轨道该方法第一,换个轨道就不是第一了,但只要有比较好的表现,就算不错。可是从方法实现来说,看不出方法对某个领域有特殊的设计,所以稍微总结一下,就是好的方法在不同领域都应该有不错的表现,但如果是在某个领域表现好,那就要体现方法实现为什么能在该领域有好的表现(不是仅仅使用了该领域的数据集这么简单)。
  • 加密流量:最直接的任务是加密流量分类任务,是个很卷的方向,以后做所谓的弹性网络评估,我觉得多少都会接触到一些。
目前想法

不需要资格论文,所以可以相对稍缓一些,写出后用于工作。这两个点都可以考虑,并且都不是短期内可以出东西的方向。

  • 安全本体建模要达到真正可发布可复用,作为长期建模优化的工作,不是随便画张图设置几个概念就可以拿去水文章的;
  • 本体对齐需要先复现别人的,了解清楚流程细节和评估手段之后,去做指标上的提升工作,同样不是一时半会就能出内容的。另外,只有真正有价值的工作,才会被不断引用和比较。
调研1:模糊本体
现有代表性工作和近期文章

此前有关于Fuzzy OWL 2的插件的研究。
搜索关键词有“fuzzy logic”、“fuzzy ontology”,有很多数学占比高的文章,晦涩难懂。就目前看来,多数文章讨论模糊逻辑时,会把不确定性和概率事件作为本体描述能力之外的内容,并且把这个当做本体的问题,引出模糊性的讨论。
应先考虑清楚,模糊安全本体应当是怎样的,有什么作用?

文章题目年份开源问题和方案解读实验解读
Fuzzy ontology representation using OWL 222011语义Web语言需要处理模糊信息的能力,要用一种标准的方式来表示这些信息。作者开发了protege的插件,用于模糊本体建模与推理。实验才用的是讲解建模案例的形式,这篇文章的工作量很扎实。
调研2:本体匹配
现有代表性工作和近期文章

此处列举比较有代表性的工作(记录来源)。
可以搜索关键词“ontology alignment”、“ontology matching"或者"ontology fusion”,都是本体匹配相关的文章,文章数量挺多的。这是本体领域的“打榜类”的方向,仔细了解下,可以熟悉相关技术路线。

文章题目年份开源问题和方案解读实验解读
Ontology alignment with semantic and structural embeddings32023声称过去工作主要是基于外部词典和本体结构的预定义规则(换言之,以旧方法为主),而这篇文章要使用深度学习了,此为方法优越。在效果上,就是优于baseline。作者的说法是,证明了学习语义表示和结构表示的重要性。实验仓库关注的人不多,从readme来说,介绍了预处理步骤,看起来有可信度,值得花时间去了解一下实验细节。实验先介绍了训练时间和超参数设置,验证度量。随后就是在Foodon和Helis上的实验测试,有Mappings数量、RecallG S ^{GS}GS、Precision≈ ^{\approx}、Recall≈ ^{\approx}、F1≈ ^{\approx}这些指标。而在OAEI tracks上面则是使用Total/correct、Precision、Recall、F1等指标。此外,还有所谓的消融实验(Ablation study),看来本体对齐主题的文章都有,它们算提出AI模型类的文章,消融实验可能是必需品了。在Foodon和HeLis的实验上,对比的方法有LogMap2、AML、LogMap-ML、RDGCN,在OAEI的conference track对比的方法有AML、GMap、LogMap、Wiktionary、TOM、AMLl o c a l ^{local}local、LogMapl o c a l ^{local}local、LogMap-ML、RDGCN等(对比表格分成了两大行)。
Ontology Matching Method Based on Deep Learning and Syntax42025声称为解决本体异构问题,文章提出一种融合循环神经网络和句法分析的混合本体的匹配方法。这里的问题,是本体对齐的目的,虽然这么说是对的,但就缺少了针对性,因为所有做本体对齐的工作,都是为了解决本体异构问题的(过于笼统)。方案是基于深度学习的方法,利用本体树结构中的入度和出度信息提取具有代表性的实体。训练数据集均来自OAEI,用若干case表示。和来自OAEI的代表性方法对比,包括AML、LogMap家族(LogMap和LogMapBio)、PhenoMF、以及基于Transformer的方法。为了比较作者提的N-gram,作者将其和另外两个相似度度量方法替换并对比,即SimRank(基于结构)和Wu-Palmer(基于语义)。作者也做了所谓消融实验,最终还比较了LSTM和GRU的时间空间复杂度(LSTM+N-gram、GRU+N-gram)。
Ontology Alignment Approach Based on Attribute Self-Adaption Mechanism and Hetergeneous Feature Fusion52025指出本体对齐面临三个问题:1、reference mapping缺乏隐式语义;2、类嵌入之间错误的高相似性;3、训练数据不平衡。提出主动学习本体对齐方法。在文章摘要处,提及了重建reference mapping避免false positive对齐类,一定程度上紧扣所提问题。使用8个数据集,有来自OAEI的。对比的基线方法有String-match,Edit-similarity,LogMapLt,LogMap,AML,LogMap-ML,Truveta Mapper,BERTMap。能对比的话,要么这些方法易于复现,要么是这些方法在数据集上已经有现成的指标数据,可以抄过来。实验指标采用经典的Precision,Recall和F1-score,注意reference mapping被用来计算这些指标。除此之外,还有所谓的消融实验和参数实验。实验数据丰富,可惜没找到开源代码,若要对比,只能选取其现成数据。
The AgreementMakerLight Ontology Matching System62013否(文章里没看到有关开源的说明,但是应该至少有工具可以获取,不然对比实验不好搞)没有明确说问题,而是说在生物医学领域,本体变得越来越大,带来了挑战。AML是为了处理特别大的本体而设计的,同时保留原框架AgreementMaker的大部分灵活性和可扩展性。在OAEI的Anatomy和Large Biomedical Ontologies轨道上验证了AML的有效性,说明AML在运行时间上很优越。在Anatomy而言,AML是目前F-measure最好的系统。在Large Biomedical Ontologies上,AML的F-measure也是前列的。实现AML使用了Apache Jena,将本体以OntModel对象的形式维护在内存中,其实这样就够了,想到我用什么多叉树,确实是伪需求。
LogMap: Logic-Based and Scalable Ontology Matching72011不确定,论文里没写。提出LogMap是唯一能够处理包含上万个(甚至上百种)类的语义丰富的本体的匹配系统,特点是高度可扩展。相比于大多数的现有工具,LogMap实现了unsatisfiability检测与修复。在NCI、FMA、SNOMED CT上实验,表示LogMap可以有效地匹配现有的最大的生物医学本体。LogMap在很多情况下能够产生"干净"的输出映射集,即LogMap的输出映射与输入本体集成后得到的本体是一致的,不包含不可满足的类。
Dividing the Ontology Alignment Task with Semantic Embeddings and Logic-based Modules82020英国团队的网站。Java代码、Python代码、数据集、OAEI的网站文章认为大型本体是本体对齐系统的严峻挑战,因而文章针对的仍然是大本体对齐问题。文章提出的方法是结合神经嵌入模型和基于逻辑的模块的方法(直观感觉是“神经”+“符号”的缝合),能够准确将输入本体匹配任务划分为更小且更易处理的匹配(子)任务。实验部分使用OAEI评估倡议的数据集进行评估(再次说明OAEI在本体匹配任务的权威性,你想要说明你的方法好,那就用OAEI的数据集来说明)。鉴于文章里附上了代码,可靠性较高,文章发表在ECAI会议上。
Augmenting Ontology Alignment by Semantic Embedding and Distant Supervision92021提出使用远程监督和语义嵌入的ML扩展,用于增强传统的本体对齐系统。和原始LogMap以及AML v3.1比较,这俩在OAEI任务中排名较高。为了精准评估两个本体的对齐效果,使用了金标准mapping来计算precision和recall(不过作者自己也承认,金标准的Mapping也是高度不完整的,这是因为其偏向于使用LogMap可以找到的映射),他们还使用了近似精度和召回率,即Precision≈ ^{\approx}和Recall≈ ^{\approx}。运行时间也作为系统考量的一部分(毕设里也可以说一下时间效率,只是提一嘴)。
Jointly Learning Entity and Relation Representations for Entity Alignment102019注意该文的主题是实体对齐Entity Alignment,说明它和本体对齐有很大的相似之处,实体对齐是NLP的经典问题了。这篇文章发表于2019年的EMNLP,是大模型爆火之前。本体对齐有个明显不一样的是,它更侧重于模式层的对齐,里面的节点以概念为主。这篇文章提出的方法基于图卷积网络GCN,用于学习实体和关系的表示。 而不是依靠预先对齐的关系种子来学习关系表示,首先使用GCN学习的实体嵌入来近似它们。然后,将关系近似合并到实体中,以迭代地学习两者更好的表示。实验宣称,在三个真实世界的跨语言数据集上进行的实验表明,该文的方法明显优于当前(2019)最先进的实体对齐方法。实验对比部分使用的指标是Hits@1和Hits@10,我没有用过这个指标,但是见过很多次了,在知识图谱预测部分也经常出现(实体和关系对齐均使用了此指标)。该方法被其它文章拿来用作本体对齐的对比,然而这篇文章通篇只提到两处本体对齐,可见实体对齐和本体对齐有一定的兼容关系,即实体对齐方法也可以拿来本体对齐。如此也可见即便大方向差不多,细分方向的差别也是非常大的。
GMap Results for OAEI 2021*112021问题仍是本体对齐,打榜类。GMap是一种用于本体匹配的概率性替代方案,它融合了和积(sum-product)网络与噪声或(noise-or)模型。具体地,作者使用和积网络基于个体集合和不相交公理来编码相似性,同时运用噪声或模型来编码描述本体间实体对相互影响的概率匹配规则。方法在OAEI2021的会议和解剖学两个赛道上验证,比较的指标有Precision、Recall、F.5-Measure、F1-Measure和F2-Measure。这里的.5和2的含义和用意是?既然是开源的项目,那就可以试试,主要看其是否可以快速部署运行。
Wiktionary Matcher Results for OAEI 2021122021以Wiktionary知识库作为外部知识资源的本体对齐系统。在OAEI2021的6个轨道上做了测试。
TOM Matcher Results for OAEI 2021132021否(暂时没找到)它叫TOM是因为它将Transformer应用于本体匹配,不是TOM猫,但这个缩写比较好记。在OAEI的Anatomy和Conference轨道上测试了。
方法分类

摘自相关文章的Related Works部分,有以下类别的本体对齐方法:

  • 基于字符串
  • 基于结构
  • 基于深度学习

其他文章里提及的对比方法列举,应该是有代表性的,不然不应该拿来比:

  • AML6:可扩展本体对齐系统,认为词库是对齐任务的重要依赖,使用外部本体作为输入本体之间的中介,在OAEI track上排名靠前。
  • LogMap7:同样在OAEI上排名靠前,首个能处理超过上万个类的本体的对齐工具,设计了锚映射(anchor mappings,M a M_aMa)。LogMap和AML的输出映射通常作为训练数据来训练有监督的方法。
  • LogMap28:是LogMap和AML v3.2的修改版本(modified version),在OAEI任务中排名很高。
  • LogMap-ML9:对传统本体对齐系统LogMap的拓展(基于机器学习),使用了Siamese网络并基于OWL2Vec*嵌入来学习本体表示。
  • RDGCN10:此方法使用GCN来学习本体结构嵌入,受所谓DPGCNN的影响,取得了SOTA表现。从文章标题来看,是实体对齐,而且2019年的时候,大模型还没火。
  • GMap11:OAEI2021上的GMap结果,GMap结合了sum-product网络和noisy-or模型。
  • Wiktionary12:是一个本体匹配器,在OAEI2021上进行了测试,将Wiktionary作为知识源。
  • TOM13:OAEI2021上,名为TOM的本体匹配器,使用了一个zero-shot transformer-based语言模型来计算每个实例的置信度,使用的预训练transformer模型paraphrase-TinyBERT-L6-v2。
  • Siamese-GCN3:即华中农业的这篇文章,和以上方法做了对比。
调研3:加密流量

和态势感知有关,因为态势感知是一个大的方向,说白了各种具体安全任务都可以用来支撑态势感知,但如果不是特别直接的关系的话,没必要硬往论文上面套。

代表性现有工作和近期文章

可以从相关综述入手来了解现状,尽管这类文章非常多,但总有一些主流的文章,总被拿来对比的。深层次的调研,除了看一看文章之外,还应把比较有名的开源代码下载部署并解读一下,趁着有服务器,可以多考虑。

文章题目年份开源问题和方案解读实验解读
暂时空着

加密流量分类很卷,需要算力,很多文章的设计看起来不甚合理。

方法分类
小结

大模型技术发展特别快,很多方向其实都可以被大模型统治了,只要是以文本、图像、音视频之类的为输入的工作,都要考虑去抱大模型的大腿。过去所谓的insight,很难比得过大模型。就这几个方向而言,我个人觉得反而是模糊本体受大模型冲击小些,本体对齐、本体工程这些时下最好的方法,都要结合大模型。加密流量分类,其实仍然是数据处理方法,把输入数据限定为加密流量,大概率也是要被大模型统治的。在没有足够大模型资源的情况下,多考虑一些相对不依赖大模型的方向。
仅作为个人调研记录,不涉及具体实现方案,尽量避免文章灌水。
待补充,持续更新。


  1. https://cdn.aaai.org/ocs/ws/ws0163/12574-57427-1-PB.pdf ↩︎

  2. https://doi.org/10.1016/j.ijar.2011.05.003 ↩︎

  3. https://www.sciencedirect.com/science/article/pii/S1570826823000276 ↩︎ ↩︎

  4. https://www.mdpi.com/2504-2289/9/8/208 ↩︎

  5. https://www.sciopen.com/article/10.26599/TST.2025.9010003 ↩︎

  6. https://link.springer.com/chapter/10.1007/978-3-642-41030-7_38 ↩︎ ↩︎

  7. https://link.springer.com/chapter/10.1007/978-3-642-25073-6_18 ↩︎ ↩︎

  8. https://arxiv.org/abs/2003.05370 ↩︎ ↩︎

  9. https://link.springer.com/chapter/10.1007/978-3-030-77385-4_23 ↩︎ ↩︎

  10. https://aclanthology.org/D19-1023/ ↩︎ ↩︎

  11. http://ceur-ws.org/Vol-3063/oaei21_paper7.pdf ↩︎ ↩︎

  12. http://ceur-ws.org/Vol-3063/oaei21_paper14.pdf ↩︎ ↩︎

  13. http://ceur-ws.org/Vol-3063/oaei21_paper13.pdf ↩︎ ↩︎

http://www.jsqmd.com/news/1211678/

相关文章:

  • 如何彻底解决微信QQ消息撤回问题:Windows平台终极防撤回指南
  • 如何完全掌控微信聊天数据:开源工具WeChatMsg的完整实战指南
  • AI Toolkit:为什么这个开源工具能让普通人也能训练专业级扩散模型?
  • VirtualBox主机与虚拟机交互配置与排错指南
  • 露易丝·海的诗歌12
  • Inkling-NVFP4快速上手指南:3步实现本地部署与多模态交互(附SGLang/vLLM教程)
  • 基于LangChain的智能客服系统架构与优化实践
  • 解决UE5材质编译错误:SM6下Missing Preview connection的排查与修复
  • 如何快速掌握围棋AI分析工具:面向新手的Katrain完整教程
  • APIKit:BurpSuite上最强大的API安全扫描插件终极指南
  • MediaCrawler:5分钟搞定多平台社交媒体数据采集的终极指南
  • Cortex-M4异常处理:SYSPRI与SYSHNDCTRL寄存器配置与调试实战
  • Android通知栏快捷开关开发指南
  • 如何永久保存微信聊天记录?WeChatMsg让你的数字记忆永不丢失!
  • Ubuntu 18.04虚拟机编译Android源码实战指南
  • Python模块化编程:从基础到高级应用全解析
  • 【C++初阶】stack、queue与容器适配器
  • Android开发中nonTransitiveRClass的真相与资源冲突解决方案
  • RevokeMsgPatcher深度解析:Windows平台企业级消息保留技术完全手册
  • 三星到iPhone联系人迁移全攻略:4种方案实测对比
  • 终极指南:3步让老款Mac重获新生,免费升级最新macOS系统
  • OpenLayers.js核心功能与开发实践详解
  • 终极指南:3天掌握Arduino ESP32物联网开发,从零到项目实战
  • C#开源项目精选与最佳实践指南
  • 基于LeRobot与ACT策略的SO-101机器人模仿学习实战指南
  • Xenia Canary技术解析:如何在现代PC上实现Xbox 360游戏的高性能模拟
  • 动态 | 团队白杰副研究员获JAG期刊2024年和2025年“最佳审稿人奖”
  • 揭秘OBS Studio多机位切换:重塑专业直播体验的完整指南
  • Next.js框架核心特性与实战优化指南
  • Kotlin协程超时机制:withTimeout原理与实践