- 博客(107)
- 收藏
- 关注
RSS订阅原创 On the Robustness of Backdoor-based Watermarkingin Deep Neural Networks
通过使用这两种攻击中的任何一种，攻击者都可以从带有水印的模型中生成一个无水印的模型进行重新分发，而无需准备标记的训练数据，特别是在白盒攻击的情况下无需访问相同的计算资源。我们专注于基于后门的水印技术，并提出了两种简单而有效的攻击方法 - 一种是黑盒攻击，另一种是白盒攻击 - 可以在没有来自地面真相的标记数据的情况下去除这些水印。我们的白盒攻击在标记模型的参数可访问时提出了一种高效的水印去除方法，并将窃取模型的时间提高到从头开始训练模型的时间的二十倍。学到的模式和它们对应的预测将充当所有权验证的密钥。
2024-01-14 20:55:25
880
原创 Protecting Intellectual Property of Deep NeuralNetworks with Watermarking
保护深度神经网络的知识产权与数字水印技术ABSTRACT深度学习是当今人工智能服务的关键组成部分，在视觉分析、语音识别、自然语言处理等多个任务方面表现出色，为人类提供了接近人类水平的能力。构建一个生产级别的深度学习模型是一项非常复杂的任务，需要大量的训练数据、强大的计算资源和专业的人才。因此，非法复制、分发和派生专有的深度学习模型可能导致版权侵权，并对模型创建者造成经济损害。因此，有必要设计一种技术来保护深度学习模型的知识产权，并实现对模型所有权的外部验证。在本文中，我们将“数字水印”概念从多媒体所有权验证
2024-01-14 17:12:50
975
原创 Rethinking Deep Neural NetworkOwnership Verification: Embedding Passports toDefeat Ambiguity Attacks
然而，在实践中，这一要求通常无法满足，我们的实验结果显示，现有水印方法都无法处理本文中探讨的模糊攻击。在嵌入水印的深度学习方法方面，现有的方法可以广泛分为两类：a）基于特征的方法，通过引入额外的正则化项将指定的水印嵌入到DNN权重中；然而，我们的研究揭示了模糊攻击的存在性和有效性，这些攻击旨在通过为涉及的DNN模型伪造额外的水印来对所有权验证产生质疑（见图1）。提出的护照相对于传统水印具有独特的优势，即预训练的DNN模型的推断性能在存在有效护照的情况下将保持完好，或者在存在修改或伪造护照的情况下显著恶化。
2024-01-14 09:13:51
988
原创 Embedding Watermarks into Deep Neural Networks
最近在深度神经网络领域取得了显著的进展。分享深度神经网络的训练模型对于这些系统的快速研究课并发进展至关重要。与此同时，保护共享训练模型的权利也变得十分必要。为此我们提议使用数字水印技术来保护知识产权，并在使用训练模型时检测知识侵权行为。首先，我们提出了一个问题：将水印嵌入深度神经网络。其次，我们提出了一种通用得框架，通过使用参数正则化将水印嵌入参数模型。我们的方法不会损害嵌有水印得网络性能，因为水印实在训练主网络时嵌入的。
2024-01-12 13:52:19
596
原创 javaEE第一、二周知识总结
MySql数据库--》实体类(java类)--》DAO--》javaBean--》servlet--》JSP/Html/Vue。扫码支付--》获取对象存钱(卡、···) --》输入100元--》选择卡支付--》确定(微信/卡) --》监听改变--》显示值。3、配置一个可运行对象。配置可以是：配置文件和注解。1、分层MVC，三层。2、要运行该类完成某个功能。2、每层分成多个模块。
2023-09-13 19:51:26
12
原创 Mobilenet-YoloV4
CSPDarknet53获取到的三个初步特征实际上只是三个特征层而已，如果可以找到Mobilenet系列网络当中特征层高宽和CSPDarknet53有效特征层高宽相同的特征层，就可以将这些特征层替换原始的CSPDarknet53的特征层，这个时候就可以将Mobilenet系列网络的特征层传入到加强特征提取网络进行加强特征提取，这样就把可以将Mobilenet系列网络应用到YOLOv4网络当中了。
2023-08-15 15:01:27
31
原创 YOLOv4
进入加强提取特征网络，获得三次卷积后的特征层先进行一个上采样，高和宽变成原来的2倍，特征层的shape变成26*26，再和主干特征提取网络的26*26*512的特征层进行一个堆叠，就实现了一个特征融合，然后继续上采样，继续堆叠。再往下走进行下采样变成26*26的特征层，然后再和前边这个特征层进行一个堆叠，堆叠后进行5次卷积，继续下采样，到了最下边再堆叠再进行5次卷积。最后YOLO Head会根据提取到的特征进行结果预测。
2023-08-06 01:51:58
18
原创 javaweb中webapp下的文件夹下的jsp访问不到的问题
无论怎么改正都访问不到，然后我把文件夹的首字母改成了小写的，它居然又行了。我到现在还一脸懵，另一个系统我就用的大写，那个就没事儿，怎么这个非得改成小写？
2023-06-20 22:00:12
313
原创 经典的设计模式22——职责链模式
使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
2023-06-16 18:27:02
1140
原创 经典的设计模式21——策略模式
定义了算法家族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。策略模式属于对象行为模式，它通过对算法进行封装，把使用算法的责任和算法的实现分割开，并委派给不同的对象对这些算法进行管理。策略算法是形同行为的不同实现。
2023-06-16 15:41:53
1636
原创 经典的设计模式20——状态模式
当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂的情况。把状态的判断逻辑转移到表示不同状态的一系列类中，可以把复杂的判断逻辑简化。
2023-06-16 13:28:32
1210
原创 经典的设计模式19——解释器模式
定义：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。这个模式简单了解就行，所以不做过多总结。
2023-06-16 12:03:28
28
原创 经典的设计模式18——备忘录模式
在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态。备忘录模式可以和原型模式组合使用。
2023-06-16 09:27:35
1410
原创 经典的设计模式17——中介者模式
用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变他们之间的交互。
2023-06-15 13:59:13
1472
原创 经典的设计模式16——观察者模式
定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态变化时，会通知所有的观察者对象，使得他们能够自动更新自己。目标和观察者：一对多单向依赖。通知的顺序绝不依赖于通知的顺序，多个观察者之间的功能是平行的。这个模式又叫发布-订阅模式，模型-视图模式，源监听器模式，从属者模式。
2023-06-14 22:13:55
1367
原创 经典的设计模式15——迭代器模式
在迭代器模式中只需要用一个不同的迭代器来替换原有迭代器即可改变遍历算法，我们也可以自己定义迭代器的子类以支持新的遍历方式。就是说当需要访问一个聚集对象，而且不管这些对象是什么都需要遍历的时候，就应该考虑用迭代器模式。由于引入了迭代器，在原有的聚合对象中不需要再自行提供数据遍历等方法，这样可以简化聚合类的设计。在迭代器模式中，由于引入了抽象层，增加新的聚合类和迭代器类都很方便，无须修改原有代码，满足开闭原则。具体迭代器角色：实现抽象迭代器接口中所定义的方法，完成聚合对象的遍历，记录遍历的当前位置。
2023-06-13 23:26:54
1109
1
原创 经典的设计模式14——命令模式
调用者/请求者（invoker）角色：要求命令对象执行请求，通常会持有命令对象，可以持有很对的命令对象。这个是客户端真正触发命令并且要求要执行的相应操作的地方，相当于使用命令对象的接口。定义：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开，这样两者之间通过命令对象进行沟通，这样方便将命令对象进行存储、传递、调用、增加与管理。实现者/接收者角色（receiver）：接收者，真正执行命令的对象，任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。，实现命令的撤销与恢复。
2023-06-12 20:58:55
1070
原创 经典的设计模式13——模板方法模式
对每个不同的实现都需要定义一个子类，这会导致类的个数增加，系统更加庞大，设计也更加抽象。父类中的抽象方法由子类实现，子类执行的结果会影响父类的结果，这导致一种反向的控制结构，提高了代码阅读的难度。实现了反向控制，通过一个父类调用其子类的操作，通过对子类的具体实现扩展不同的行为，实现了反向控制，并符合开闭原则。算法的整体步骤固定，但其中个别部分易变时，这时候可以使用模板方法模式，将容易变的部分抽象出来，供子类实现。：实现代码复用，将相同的部分的代码放在抽象的父类中，而将不同的代码放入不同的子类中。
2023-06-12 17:49:47
1238
原创 javaweb老是报找不到数据库的问题解决
这次找不到数据库，完全是因为忘了把配置文件改过来了，粗心了粗心了，我还纳闷为什么怎么修改都不对。这个问题解决了之后，又有新问题，结果原来是有个判断条件写错了。
2023-06-11 21:12:22
174
原创 经典的设计模式11——组合模式
应用场景：需求中是体现部分与整体的结构以及用户可以忽略组合对象对单个对象的不同，统一的使用组合结构中的所有对象时，就应该考虑用组合模式。组合模式：将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。有两个要实现的例子，一个商品类别树，一个是公司管理的例子，这里以公司管理为例子。一些典型例子：绘图编辑器，图形捕捉系统，drow.io。缺点：很难限制组合中的组件类型。
2023-06-11 17:18:26
45
原创 经典的设计模式10——代理模式
典型的案例，就是一个追求者可以找一个代理人去给被追求者送礼物，实质还是追求者送的礼物，只是找人代替送礼物这件事情。代理模式：为其他对象提供一种代理以控制对这个对象的访问。
2023-06-11 15:43:51
38
原创 经典的设计模式9——适配器模式
系统的数据和行为都正确，但是接口不符合时，我们应该考虑用适配器，目的是使控制范围之外的一个原有对象与某个接口匹配。适配器模式主要应用于希望复用一些现存的类，但是接口又与复用环境要求不一致的情况。将一个类的接口转换成客户希望的另外一个接口。emmmmmmm，感觉这个模式好像不是重点，也没布置啥作业，估计会出选择或者简答题。，本节主要就是对象适配器，采用对象组合的方式，更符合松耦合。缺点：过多使用适配器模式，会让系统凌乱，不容易整体进行把握。优点：更好的复用性，更好的扩展性。本质：转换匹配，复用功能。
2023-06-11 15:15:22
1037
原创 经典的设计模式8——外观模式
外观模式：为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。使用场景：当客户程序与抽象类的实现部分之间存在很大的依赖性。外观模式的外观类将客户端与子系统的内部复杂性分隔开。外观模式是迪米特法则的一个经典应用。缺点：不符合开闭原则。
2023-06-10 14:51:25
40
原创 经典的设计模式6——桥接模式
这学期虽然科目少，但是工作量确实是大，真是头一次遇到这么紧凑的情况，既然无法避免，那就直面它！挑战一下极限！合成/聚合复用原则：尽量使用合成/聚合，尽量不要使用类继承。好处：优选使用对象的合成/和聚合将有助于保持每个类被封装，并被集中在单个任务上。这样类和类继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物。
2023-06-10 09:56:22
1080
原创 经典的设计模式5——建造者模式
截止到今天，创建者模式这一类别的模式已经全整理完了，一共包含5个，工厂方法模式，抽象工厂模式，单例模式，原型模式和建造者模式。还是太看的太慢，得加快进度了。就是使得建造代码与表示代码分离，由于建造者隐藏了产品是如何组装的，所以如果需要改变一个产品的内部表示，只需要再定义一个具体的建造者就可以了。如果使用了建造者模式，那么用户就只需要指定需要建造的类型就可以得到它们，而具体建造的过程和细节就不需要知道了。，所以建造者Builder类里的那些建造方法必须要足够普遍，以便为各种类型的具体建造者构造。
2023-06-09 20:08:48
891
原创 经典的设计模式4——原型模式
原型模式就是从一个对象再创建另外一个可定制的对象，而且不需要知道任何创建的细节。原型模式是用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。原型模式内容比较少，今晚实现了简历的那个例子，深复制的问题。希望明天可以看到一个不一样的自己！今天状态比较差，效率低。
2023-06-08 23:45:41
41
原创 经典的设计模式3——抽象工厂模式
说真的，我还真没发现，这个模式和工厂方法模式到底有什么区别，无非就是多了几个抽象的产品而已。抽象工厂模式以一种倾斜的方式支持增加新的产品族。提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。本质：选择产品族的实现一个系统有多于一个的产品族，而系统只消费其中某一产品族。希望一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节时。在抽象工厂模式中，产品族是指由同一个工厂生产的，位于不同产品等级结构中的一组产品，如海尔电器工厂生产的海尔电视机、海尔电冰箱。
2023-06-07 19:27:10
38
原创 经典的设计模式2——工厂方法模式（含简单工厂模式）
简单工厂模式中，工厂类用于创建各种各样的产品，根据输入来的参数不同，创建出不一样的产品。但是如果有新的产品要加入，我们需要修改工厂类中的代码，这违背了开放封闭原则，并且对于工厂类有着较大的依赖。所以引出工厂方法模式。工厂方法模式是类的创建模式，其用意是定义一个创建产品对象的工厂接口，将创建产品工作推迟到子类中，**在工厂方法模式中，核心的工厂类不再不再负责所有产品的创建，而是将具体的创建工作交给子类去做。**这个核心类仅仅负责给出工厂必须是实现的接口，而不接触哪一个产品类被实例化这种细节。
2023-06-05 17:53:41
457
原创 经典的设计模式——UML类图的一些规范
当一个类“知道”另一个类时，可以用关联关系表示，比如企鹅和气候就是这种关系，企鹅需要知道气候，在企鹅类里边可以定义气候。这个用的也还是比较多的。聚合表示弱拥有关系，体现的是A对象可以包含对象B，但B对象不是A对象的一部分。部分和整体的关系，强拥有关系。用实心菱形+实线来表示。这个一般在客户端实现那里使用，其余的地方没见过有用这个表示的。比如动物依赖于氧气和水的关系就是依赖关系。+号表示公有，-表示私有，#表示保护。我感觉这个依赖关系模模糊糊的。这个也用的稍微多一点点吧。这个用的还是比较多的。
2023-06-05 15:33:39
1083
原创 经典的设计模式1——单例模式
通常我们可以让一个全局变量使得一个对象被访问，但它不能防止实例化多个对象。最好的办法就是让类自身负责保存它的唯一实例。这个类可以保证没有其他实例可以被创建，并且它可以提供一个访问该实例的方法。2、必须创建自己的唯一实例。3、必须共享实例（static），给其他对象提供这一实例。一般有饿汉式单例（空间换时间）和懒汉式单例（时间换空间），：保证一个类仅有一个实例，并提供一个访问它的全局访问点。读取配置文件是典型的单例模式。打印机也是单例模式。输出结果为两个实例相同。
2023-06-05 11:35:48
40
原创 经典的设计模式——具体分类以及七大面向对象设计原则
开放封闭的原则的核心：软件实体应该是可扩展的，而不可修改的。也就是，对扩展是开放的，对修改是封闭的。对扩展而言，如果我们需要新的方法，新的功能。我们可以对原本的类实现扩展，适应新的需求。但对于已经设计好的类，我们尽可能的不再去修改这个类。所以要求我们合理的抽象、分离出变化与不变化的部分，为变化的部分预留可扩展的方式。但是不能盲目的追求开放封闭原则，否则会造成系统的复杂度大大增大。
2023-06-05 09:43:21
511
原创 javaweb的servlet显示找不到路径以及显示数据库找不到指定列的问题解决
考虑两个原因，一个可能是需要重新打个war包，另一个可能就是sql语句写错了，这次是因为sql语句写错了。
2023-05-24 16:23:24
851
原创 JavaWeb——找了1个多小时才发现的错误。。
之前敲过一个类似的加载properties的文件的方法，直接把课本的这个改成这个就可以解决500的错误了。注释下边这个没问题，记得路径改成绝对路径！如果只是跟着课本敲，那就肯定报错了。注释的地方是行不通的错误代码！
2023-05-11 20:04:16
75
原创 SpringBoot——花了半个多小时才发现的错误。。
在找错误的过程中发现有些sql语句也写得不对，单词拼错的，后边多加逗号的，某些html语句后边多写逗号的。找了半天原来改写mapper的地方写成了service。
2023-05-08 21:24:19
38
原创 SpringBoot工程的创建流程
创建好mapper接口之后继承BaseMapper根据数据库的字段名进行属性的定义，有下划线的用驼峰命名。最后再创建controller。加上下面这个注解就可以解决。将接口放在前端url上边。再创建service。
2023-05-08 10:39:04
244
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人