代码提交总结 第1篇

搞完了单元测试，接下来就是搞回归测试。

为什么需要回归测试，通俗的说， 只保证了单元的正确性， 但是多个正确的单元有可能错误的结合， 所以我们需要回归测试， 来保证业务逻辑代码的正确性。

SRS里面是怎么做的

 这个目录下， 提供了压测工具和单元测试工具。

原理也很简单， 用GO自带的TEST, 结合GO语言开发快的特点， 用PION这个库做了一些简单的回归测试，都有些啥：

在这个基础上， 我补充了一个RTC推流， FLV播放， 验证音视频时间戳是不是对齐的逻辑。截取个代码片段：

写完后，本地多次验证OK， 安心提交。

得益于github完善的机制， 提交后自动跑单元测试，回滚测试，各种环境的编译脚本。全绿！通过！

有了单元测试 + 回归测试这俩牛逼的组合， 对于开发者来说， 提交代码更安心了， 虽然全部测试通过不一定意味着没问题， 因为可能有一些函数和逻辑没有被测试覆盖到， 但是有不通过的测试一定意味着有问题， 这就足够了， 保证了BUG尽量在早期被发现， 提升软件的可靠性。

SRS的未来， 希望每一个PR， 都能用测试用例覆盖。

代码提交总结 第2篇

赛题任务：本赛题采用的时序知识图谱为ICEWS05-15, 时间范围为2005-2015年。所有问题均基于时序知识图谱进行构建，其中，问题与答案中包含多种粒度的时间信息，包括年xxx和日，且问题中涉及多种时序逻辑约束，如之前、之后、首个等，问题答案限定于图谱中的实体和时间。

思路：根据所给的四元组[头实体 关系 尾实体 时间]

step 1: 根据所给的四元组[头实体 关系 尾实体 时间] , 训练ConpllEx, TComplEx,TNTComplEx张量分解模型，得到实体评分矩阵和时间评分矩阵，Concat之后得到实体时间评分矩阵（用处：Sentence_embedding* 实体时间评分==》每个实体和时间的score,这里相当于在做分类任务）

step 2: 利用LM对question进行编码，（如果有辅助标签，可以concat实体和时间的辅助信息表达), 再见过transformer编码得到last_embedding

step 3: last_embedding * 实体时间嵌入矩阵 ==》可能是每个实体和时间的scores,取topk作为答案。

3. 时序知识图谱辅助知识：Question Answering Over Temporal Knowledge Graphs

Instroduction:

知识图谱问答：把知识图谱作为知识库来回答自然语言问题（对比基于阅读理解的问答，它不需要理解上下文）

KG 嵌入： 得到实体关系时间的低维向量表示（研究此最初四为了知识图谱补全）

数据集：带有时态的KG, 一组需要推理的自然语言问题

所提方法：CRONKGQA, 应用了基于深度语言模型（LM）的方法t5,bert,knowbert,以及混合LM+KG嵌入方法

Related work:

普通图谱数据集：从KG中提取一个事实来回答一个问题，提取事实涉及多跳推理

时态数据集：多用于阅读理解，自然语言问题涉及时态比如before after

时序问答算法：最近的KGQA算法多是基于非时间KG，扩展此任务到包含形式（主体、关系、对象、开始时间、结束时间）的时序KG是很重要的。 TEQUILA（2018）是一种专门针对时间KGQA的方法：将问题分解并重写为非时间子问题和约束问题。非时间的子问题使用任意KG检索答案，TEQUILA在时间间隔上使用约束推理来计算完整问题的最终答案，缺点是需要使用预先指定的模板分解问题，以及对实体具有时间约束的假设。

CronQustions: 新的时序知识图谱数据集

构造的数据集由两部分组成：时序知识图谱和需要时态推理的自然语言问题。

每一个example包括：一个自然语言问题、问题中的实体、时间集合，标准答案（实体或时间）

问题分类：简单问题和复杂问题（需要进一步推理的问题before/after, first/last, time join）

时序知识图谱嵌入

研究了时间和非时间的KG嵌入，以及预训练语言模型来执行时序KGQA

KG嵌入模型的使用：ComplEx 将实体 关系表示为向量， TComplEx,TNTComplEx 多了时间表示

CronKGQA: 所提的创新方法

1.使用时间不敏感（ComplEx）或时间不敏感(TComplEx或TimePlex)的KG嵌入算法，获得时序知识图谱中实体、关系和时间戳嵌入

论文首先将EmbedKGQA(2020)直接应用于时态KGQA任务（在最初的实现上，EmbedKGQA用ComplEx嵌入，并且只能处理非时态的KG和单一的实体问题）----> 为了将其应用于CronQuestions，我们将遇到的第一个实体称作“head entity”，改用TComplEx来获取实体和时间嵌入。使用LM-CronKGQA找到问题嵌入q，然后将其投影得到两个嵌入q_ent和q_time,这两个嵌入分别用于预测实体和预测时间。

实体评分函数

时间评分函数

代码提交总结 第3篇

每次提交代码到 Git 仓库时，都需要写 commit message。通常情况下，commit message 应该清晰明了，说明本次提交的目的和具体操作等。然而，在日常开发中，开发者们提交的 commit message 千差万别，中英文混用，导致后续代码维护成本很高，有时候甚至自己都不知道修复的是什么问题。因此，为了解决这些问题，我们希望通过一种方式来监控用户的 git commit message，以提高代码规范，提高开发效率。

代码提交总结 第4篇

以后再怎么改代码， 跑一遍单元测试， 起码能让人安心， 知道这一次修改的代码没有基本的函数级别的错误；

试想一下如果没有用单元测试发现这几处细微的代码错误， 合并到 后， 最终问题还是会变成 ISSUE 回来， 而且更隐晦， 更难排查。从长远看， 单元测试节省了开发者的时间。

搞完了单元测试，接下来就是搞回归测试。

为什么需要回归测试，通俗的说， 只保证了单元的正确性， 但是多个正确的单元有可能错误的结合， 所以我们需要回归测试， 来保证业务逻辑代码的正确性。

SRS 里面是怎么做的

原理也很简单， 用 GO 自带的 TEST, 结合 GO 语言开发快的特点， 用 PION 这个库做了一些简单的回归测试，都有些啥：

DTLS 握手的丢包，乱序， 重复等多种可能的测试；

RTC 推一个自带的xxx达视频， 验证能不能用 RTC 拉流；

其他一些基本的流程验证。

在这个基础上， 我补充了一个 RTC 推流， FLV 播放， 验证音视频时间戳是不是对齐的逻辑。截取个代码片段：

写完后，本地多次验证 OK， 安心提交。

得益于 github 完善的机制， 提交后自动跑单元测试，回滚测试，各种环境的编译脚本。全绿！通过！

有了单元测试 + 回归测试这俩牛逼的组合， 对于开发者来说， 提交代码更安心了， 虽然全部测试通过不一定意味着没问题， 因为可能有一些函数和逻辑没有被测试覆盖到， 但是有不通过的测试一定意味着有问题， 这就足够了， 保证了 BUG 尽量在早期被发现， 提升软件的可靠性。

SRS 的未来， 希望每一个 PR， 都能用测试用例覆盖。

代码提交总结 第5篇

使用chinese_roberta_wwm_large_ext_L-24_H-1024_A-16 的表现如图1(在真实的测试数据集上的表现为 epoch=12 r1)

2. 改进思路1：模型在Common Knowledge和other上的表现较低，考虑将该类数据做一个数据增强？

不分类别 对所有数据都做数据增强 效果如图

发现除了healthy lifesty 表现在下降（测试模型路径不对劲，得改）

3. 改进思路2：用中文医疗数据集做一个预训练，得到预训练模型，再在这个基础上进行训练

4 改进思路3：考虑做一个标签增强学习

5 改进思路4：先做一个已知意图和未知意图的检测，在进行已知意图的分类

6 改进思路5：更换预训练语言模型：bert-chinese-base,

chinese_roberta_wwm_large_ext_L-24_H-1024_A-16,

7 改进思路：更换分类器BiLSTM+fc

5 调参：baches,epoches, ema,fgm

规律：发现使EDA反而会使效果下降，还是不用

(2)

(5)

（5*）

（9）

（10）

(11)

(12)

(13)

数据观察

训练集和测试集标签分布：

训练集和测试集句长分布：

新服务器：EPOCHES=50，TEXT_LEN=20

(1)

(2)

(3)

(5)

数据分布不均匀问题： 每个类别进行数据增强

(6)

（7）试下

检测出的正例中，真正是正例的个数占检测出的正例的比例

所有的样本中，被判断为正例的占所有正例的比例

将准确度的r21的第5类标签全部改为2 观察其准确度

预测完毕之后再进行二分类？ 期待stemp的效果

（8）二分类预训练之后的六分类效果（二分类训练集数据量0-1225 1-445条）

(9) 先对二分类数据增强（每一条样本生成两条增强样本，共5010条样本）：效果变差 pass[

解决二分类数据平衡问题（二分类中0每条样本增强一条 0-2450条 1每条样本增强4条 1-2225条）

10折交叉验证epoches=30

*模型融合part: robert（） macbert() ft-bert() 硬投票cb1

概率平均cb2

加权平均 cb-weight

三个模型特征的拼接

对基于Robert的模型进行阈值调优

*五折的效果会怎么样呢？

cb1-5: cb1-10:

cb1-prob-5: cb-prob-10：

预训练二分类均衡样本量(效果不行pass)

三个模型的融合:

尝试uer NEZHA

把tricks都加上

softmax之后的五个单模型的效果：

NEZHA单模型: nezha2

ROBERTA单模型： rober2 还没有预测结果文件

LERT单模型： 还没有预测结果文件

FT 单模型：正在跑

macBert单模型

softmax之后的十折交叉验证融合的效果:

c1-s: √

c2-s:√

c3-s:√

c1-nezha-s:√

c1-lert-s: √

五个单模型十折融合+结果文件融合：

2. 知识图谱 实践CeKG

论文相关工作：

PLM=roberta dropout= model = 41

PLM=roberta dropout= model=base_roberta_atten-best-loss

PLM=roberta dropout= model=base_atten-best-loss2

PLM=macbert dropout= model = base_atten-mac-best-loss3

PLM模型参数不固定的情况：

PLM = macbert dropout= model = base_atten-mac-best-loss2

PLM = macbert dropout= model = base_atten-mac-best-loss

将dropout加在CNN后：效果感觉不行

将dropout加在bert层：也不行呀看着

bert与训练模型加载两次本身的输出就是不一样的

macbert dropout=: acc=

macbert dropout= acc=

macbert dropout= acc=

roberta dropout= acc=

roberta dropout= acc=

roberta dropout= acc=

代码提交总结 第6篇

Commit Log 包含三个部分：header、body、footer。其中，header 是必需的，格式固定，body 在必要时用于详细解释变更。

commit log 格式如下：

注意：冒号后面必须有一个小写空格，types 和 scopes 可以是多个，中间用逗号分隔。

举例：

英文，小写。必须是以下中的一个或多个：

英文，小写。表示变更的包或模块范围，可以是多个组合，如果涉及范围较大，可以用*代替。各服务可以自行定义，组内同学可以轻易理解。通用 scope 列表如下：

除了上述通用字段外，各方向可以自行定义关键字。例如，以下是商品平台中定义的字段：

中文。简要描述修改，结尾不要有句号。

中文。修改的背景（为什么做这次修改），说明修改逻辑。

中文。可以放置需求 wiki 或 task 链接，对以后其他同学查看很有用。

安装该插件后，在提交页面会有一个按钮

本文由 mdnice 多平台发布

代码提交总结 第7篇

出现错误的主要原因是gitee(github)中的文件不在本地代码目录中

解决fatal: The current branch master has no upstream branch.

解决Push rejected Push to origin/master was rejected idea中使用alt+F12打开控制台或在Git Bash中输入如下命令

在使用git的时候，每次执行

git add .

都会提示这样一个警告消息：

原因是路径中存在 / 的符号转义问题，false就是不转换符号默认是true，相当于把路径的 / 符号进行转义，这样添加的时候就有问题

虽然说没有什么影响吧。

不过就是觉得太碍眼了，

按照这样设置就没有问题了:

这样设置git的配置后在执行add操作就没有问题了。

git clone 时403报错问题 解决方法：重置本机保留的git config 信息。 命令：git config --system --unset 然后再次clone的时候，就会让你输入用户名和密码了。