语言

当初团队里简直所有的代码都须要通过 Code Review（代码审查）之后才容许合入主分支。笔者在 CR 中看到了不少不适宜的问题，也看到了不少值得学习的点，于是决定一点一滴地记录这些做法、教训、教训，以飨读者。如有谬误，也欢送读者不吝指正。 上一篇文章: context 类型的 key 有什么考究？ 一句话标准问题背景可能存在问题解决办法应用值传递的长处什么时候应该应用援用传递一句话标准当函数的入参、出参是一个构造体时，如无必要，应用值传递而不是援用传递问题背景当咱们用 Go 开发时，对外裸露一个函数 / 办法时，以构造体作为函数的入参或出参，是十分常见的。比如说，咱们实现上面的一个函数，返回一个用户信息。 比如说，咱们提供两个函数，别离用来获取相干用户的权限信息: package permissiontype UserPermission struct { UserID string Permissions []string}// GetUserPermissions 获取指定 user ID 的权限func GetUserPermissions(userID string) *UserPermission// SetUserPermissions 设置指定 user ID 的权限func SetUserPermissions(permission *UserPermission) error能够看到，在下面的代码中，UserInfo 作为出入参都是以指针存在的。这种模式的代码十分多，也十分典型，而且大家都会习惯于这么写，特地是有面向对象思路的程序员。 那么，这么写能够吗？有什么问题呢？其实这个要具体问题具体分析，上面咱们就来一起看一看。 可能存在问题假如有一个新需要，是复制一个用户的权限给新用户。这逻辑看起来挺简略，代码里这么写，齐全是荒诞不经的： // CopyUserPermissions 复制用户权限func CopyUserPermissions(ctx context.Context, fromUserID, toUserID string) error { pms := permission.GetUserPermissions(fromUserID) pms.UserID = toUserID return permission.SetUserPermissions(psm)}这种写法，节俭了内存应用，逻辑也十分清晰，code review 的时候直呼赞。 有什么问题吗？隐含的问题不在 CopyUserPermissions 上，而在 GetUserPermissions 中。有时候某些数据，咱们可能是通过本地缓存来实现的，基于这种模式，GetUserPermissions 外部的逻辑就有可能是： ...

大规模语言模型畛域迎来新“选手”。近日，微信 AI 推出自研 NLP 大规模语言模型 WeLM ，该模型是一个尺寸正当的中文模型，可能在零样本以及少样本的情境下实现包多语言工作在内的多种 NLP 工作。 同时，微信 AI 团队也提供了 WeLM 的体验网页和 API 接口，感兴趣的用户可返回 https://welm.weixin.qq.com/docs/体验和申请 API 接口，相干技术论文《WeLM: A Well-Read Pre-trained Language Model for Chinese》也曾经公布于论文预印本网站 arXiv。 NLP 大模型迎新选手，WeLM 提供交互式网页 PlayGround 和 API 接口在近几年自然语言解决（NLP）畛域的倒退浪潮中，OpenAI 开发的自然语言解决模型 GPT-3 无疑风头无两，公布之初便以 1750 亿参数规模的预训练模型所体现进去的零样本与小样本学习能力刷新了人们的认知，也引爆了 AI 大模型钻研的热潮。 对业界来说，预训练大模型升高了 AI 利用的门槛，间隔“AI 把人类从重复性劳动中解放出来”的宏伟目标越来越近，目前，基于 GPT-3，寰球开发者曾经摸索出包含编程、回复邮件、 UI 设计、答复数学问题、法律语言转化、总结中心思想、推理、文本处理等广泛应用场景，并且，各国研究者在多语言/多任务等角度的摸索也正在谱写大模型百家争鸣的新篇章。而在国内以中文为外围的大规模语言模型畛域，微信 AI 推出的百亿级别大规模语言模型 WeLM，便是大模型百家争鸣中的新选手。 据介绍，WeLM 是一个百亿级别的中文模型，可能在零样本以及少样本的情境下实现包含对话-采访、浏览了解、翻译、改写、续写、多语言浏览了解在内的多种 NLP 工作，并具备记忆能力、自我纠正和查看能力。并且，WeLM 具备尺寸正当的劣势，在 14 项中文 NLP 工作上， WeLM 的整体体现超出了所有同大小的模型，甚至可能匹配比它大 25 倍的模型。以被普遍认为是更艰难的 NLP 工作的文本格调转换（改写）为例，只管用户给出的5个例子和最初须要生成的例子并没有重合的格调转换类型，但 WeLM 领有杰出的触类旁通能力，通过学习大量的文本转换例子即可达到对任意类型的文本转换。并且，WeLM 在对话-采访、浏览了解、翻译、续写等多个中文文本生成工作中有着同样优异的体现。 ...

摘要：在这篇博文中，咱们介绍来自Google的一篇论文《Scaling End-to-End Models for Large-Scale Multilingual ASR》，来看看如何构建一个可能辨认15种语言的多语ASR零碎。本文分享自华为云社区《多语言ASR 没有什么听不懂，15种语言我全都要》，作者：xiaoye0829 。 在这篇博文中，咱们介绍来自Google的一篇论文《Scaling End-to-End Models for Large-Scale Multilingual ASR》。建设一个能辨认多种语言的ASR零碎，是非常有挑战的，因为这些语言之间存在着十分大的差别，并且数据量非常不平衡。现有的工作中，咱们能够察看到利用有丰盛语料的语言，能够帮忙只有大量语料的语言的学习，然而这往往也随同着，有丰盛语料的语言的成果会降落。咱们在15种语言上进行了钻研，每种语言的大小从7.7千小时到54.7千小时，咱们发现增大模型的参数量，是解决容量瓶颈的无效办法，咱们500M参数的模型，曾经超过了单语的baseline模型，当咱们把模型参数进一步增大到1B或者10B时，咱们能取得更大的收益。另外，咱们发现大模型不仅在数据利用上更无效，在训练工夫上也更有效率，咱们的1B（10亿）参数的模型达到和500M参数的模型雷同的准确率，只花了34%的工夫。当模型容量无限时，减少模型的深度，通常比减少模型的宽度要好，更大的encoder，也往往比更大的decoder要好。 多语言ASR的关注点通常在于进步低资源（只有大量语料）语言的性能，背地的思维是，利用类似语言的数据，多种语言一起联结优化，以及间断的正向迁徙从高资源语言的迁徙。在这篇文章中，咱们从容量（capacity）的视角来钻研下，在多语言的模型中，高资源语言的性能降落问题。 先前的工作摸索过50到100种语言，然而数据集的大小非常无限，最大的数据集仅仅只有1k小时的演讲数据。在咱们的试验中，每种语言的数据量从7.7千小时到54.7千小时（如下图，counts代表语音的条数，hours代表语音的时长），这使得咱们能够有一个高质量的单语模型，那么咱们就是要训练一个多语的模型，可能超过每个单语的模型。咱们从容量的角度展现了如何去解决这个问题。 随着模型容量回升，咱们胜利复原了所有高资源单语模型的性能。咱们做了很多比照试验，并发现减少深度通常能获得比减少宽度更好的成果，并且咱们发现，encoder的容量往往与模型的辨认成果很相干。咱们察看到，在固定的模型容量下，如何调配语言的信息变得不那么重要了。而且，大模型更简略，并且更有效率，须要更少的训练轮次，和更少的TPU工夫，去达到类似的试验成果。 在本文的多语言ASR零碎中，应用的是一个基于attention的encoder-decoder模型。对于encoder，咱们应用Conformer架构，蕴含一个输出映射层，一个绝对地位嵌入层，以及一些conformer层。第一个conformer块，蕴含4个conformer层。第二个conformer块，蕴含一个conformer层。咱们的decoder尝试了两种不同的架构，一种是单向的LSTM，另一种是带有掩码的自留神和跨注意力机制的Transformer。咱们的输入词表大小为一个有3328个token的表，在这个表中， 3315个token是在训练集中至多呈现了1000次，剩下的token是一些非凡的token，相似“<s>”</s>“”，和一些占位填充符。词表中的大部分词来自于中文，并且中文因为在训练集中的覆盖面，是惟一一个有OOV问题的语言。咱们将语言信息也编码成一个one-hot向量，作为一个额定的输出。咱们在训练的工夫，简略地把所有数据放在一起，并且依据数据分布，在每个batch里，去进行采样。整个eocoder-decoder模型是在网络的输入和实在文字间，用穿插熵进行优化的。 实际上，咱们有很多办法，去缩放一个基于encoder-decoder的多语言模型，在这篇文章中，咱们次要钻研上面四种模式的影响： 深度 vs 宽度；encoder vs decoder；语言相干的模型容量 vs 语言无关的模型容量；架构 vs 容量。严格来说，模型容量并不齐全等于模型的参数量，比方模型大小。对于有语言依赖的模型内容，推理时的模型容量，要小于训练时候的模型容量，这是因为在推理的时候，只有奉献的参数和对应于特定语言的参数被激活。为了简化本文的探讨，咱们关注在训练时的模型容量，并且混用模型大小和容量。缩放模型大小，也会带来很多理论问题，比方模型的并行化反对。 本文的试验，是在来自9种语系的15种语言上进行的试验。总计235.4百万条语音，语音时长共计364.9千小时，这些数据采集自谷歌的声学搜索引擎，数据是齐全匿名的，并且由标注人员标注成文本。本文应用的数据是之前论文应用的数据的20倍。据咱们所知，这也是第一篇在这么大规模的数据集上做多语言试验的论文。与之前多语言的工作不同，咱们关注在不同高资源语言间的烦扰问题。在咱们的设定里，咱们最小的语言有大概7.7千小时的训练数据，大概是之前工作里最大的语言资源的7倍。这个规模的数据集又给训练效率带来了挑战。咱们的每种语言的测试集，蕴含大概3到19k的语音，这些语音是从谷歌语音搜索引擎外面的采样进去的，并且和训练集没有重合。同样地，测试集也是齐全匿名和手工转写的。 咱们在训练的时候应用了80维的log mel特色，每帧的窗口大小为32ms，每两个窗口间有10ms的重叠。将间断3帧的特色重叠起来，并做一个下采样，咱们能取得240维的输出特色，这个特色的采样率为30ms。一个16维的one-hot语言向量，被送入到encoder中作为额定的输出，SpecAugment数据加强也被用来加强模型的鲁棒性。整个模型利用512个TPU核进行训练，除了10B（100亿）参数的模型，用了1024个TPU进行训练，这次要是因为每核16G的带宽限度。模型应用同步随机梯度降落进行优化。对于LSTM作decoder的模型，咱们采样Adam优化器做优化，对于Transformer，咱们采样Adafactor做优化器。transformer学习率优化策略也被应用，其中最大学习率为3e-4，warmup的步数为10k。 在这一节，咱们展现咱们在大规模数据集上建设高质量的多语言模型的钻研后果，为了简略，咱们只用均匀WER作比照，并且只汇报每种语言的性能。 咱们应用Conformer作为encoder和LSTM作为decoder，来构建单语的baseline模型，encoder蕴含17层conformer block，每个conformer层的模型维度为512，有8个head的attention，conformer外部卷积模块中，卷积核的大小为15。decoder是LSTM，蕴含2层640维的LSTM，暗藏单元的大小为2048。每个单语模型的大小为140M，并被用来预测跟该语言相干的token。均匀的WER为9.29%。每种语言的性能如下图所示，其中英语（US）的WER最低，为4.6%，Marathi（IN）的WER最高为20.2%。领有更多训练数据的语言，往往有更低的WER。 为了证实conformer作为多语言建模的encoder的有效性，咱们比照了三种不同encoder，他们都以LSTM作为decoder。1. LSTM作为encoder，蕴含8层LSTM，每层有2048个暗藏单元，和640维的输入单元。2. ContextNet作为encoder，蕴含24层contextnet，每层有640维的暗藏单元，通道大小为2。3. Conformer作为encoder，蕴含17层conformer，每层有512维的暗藏层，这个设置和单语的模型统一。语言适应层（Language Adapter）在每个encoder层之间都被插入。这三种不同encoder构造的抉择，是为了使得模型参数的总数尽肯能保持一致，都大概为220M。相比单语模型，多语模型的大小的减少次要来自于额定的语言适应层（Language Adapter）和输入词表的大小的减少。这三个模型的均匀WER为11.86%，10.77%，和9.43%。这个后果充沛展现了conformer作为多语ASR的encoder的成果。比照单语模型，只管在品质上还不如单语模型，然而它在同时辨认15种语言上，体现得很好。它在大略21个epoch时收敛，训练了大略120万step，而单语模型通常要训练到50个epoch。为了了解语言适应层的成果，咱们做了上面的融化试验，为了疾速进行试验，咱们比照了模型在200k step时候的成果，大概此时是在第3.5个epoch。应用语言适应层，会带来语言依赖的参数，和一些模型大小上的减少。为了帮咱们更好了解，咱们训练了一个独自的适应模型，能使得所有模型共享雷同的adapter transformation。因而，咱们的模型可能大小可能解脱adapter模型。在200k step时，这个模型取得了10.86%的均匀WER，绝对刚刚的baseline（带语言适应层），取得了10.38%的均匀错误率。从这个比照，能够看到，在模型中退出语言适应层很重要。 除了用一个共享decoder，多头模型（用不同的decoder针对不同的语系）可能被用来减少模型容量，和之前的工作雷同，咱们为每种语系应用不同的decoder。总共5种语系会被应用，包含Germanic, Italic，Arabic，Indo-Iranan和其余语言。为了比照，咱们确保单个decoder和多个decoder模型有雷同的参数量：1. 单decoder模型有6层768维的LSTM，每层有3074维的暗藏单元。2. 多decoder，有5个decoder，每个decoder有2层640维的LSTM，每层有2048维的暗藏层单元。这两种模型都有354M的参数。在200k的step时，单个decoder的均匀WER为10.13%，多个decoder的均匀WER为10.28%，这倡议咱们在雷同的模型大小下，咱们用单个decoder，相比多个decoder要好。 为了进步咱们多语模型的成果，咱们进一步把模型参数从354M减少到500M，通过把模型的宽度从512维，增大到640维。把宽度从17层，增大到22层。这个增大后的模型，在200k step时可能取得9.63%的WER，并在1.1M step时，取得了9.13%的WER，能超过单语模型。然而，相比根本的220M的模型，它的训练速度慢了1/3，这是因为RNN的谬误反向流传带来的。这个个性也使得用LSTM做decoder不适宜进一步的模型扩增。相比LSTM，基于transformer的decoder模型，在训练时有更高的并行化能力。在雷同的encoder架构下，咱们建设了一个Transformer decoder模型，参数大概500M，有12层transformer，768维的模型维度，3072维的暗藏层维度，和8个attention head。它的均匀WER是9.26%，比LSTM的WER要高一些，然而它的训练速度和220M baseline模型靠近。因而，咱们在前面的钻研中，都用Transformer作为decoder。 在上面的试验中，咱们想进一步增大Conformer作为encoder和Transformer作为decoder的模型的容量大小，试验后果如下表所示，L示意模型的层数，W示意模型的维度，loss是训练样本负log混同，越低越好。speed是每秒训练的样本数。B0是baseline模型，“-”示意和B0没有区别。所有的E模型的参数量大小都为1B。 比照E1和E2，E5和E6，咱们能够看到越深的模型获得了相比越宽的模型更好的成果。然而，越深的模型须要更长的工夫去训练（2352 vs 3419）。比照E1-E4和E5-E7，增大encoder的容量，相比增大decoder的容量，能取得更好的后果。然而， 更大的decoder往往有更好的training loss。E4,这个模型均匀把模型容量分给宽度和深度，在这个task上体现得并不好，相较而言，E3把更多地模型容量分给宽度，要体现得更好一些。最初，E8模型，首先把模型容量，均匀分给encoder和decoder，而后把更多的容量分给depth，和E3的性能差不多。E3模型最终在600k step时收敛，大概10个epoch。最终取得了大概9.07%的均匀WER。 在这个工作中，咱们钻研了如何构建一个多语言端到端ASR零碎，咱们通过增大模型容量来解决这个问题。随着模型的增大，咱们察看到模型的成果一直减少，咱们也能建设一个独自的多语言辨认的ASR零碎，这个零碎能在高资源的语言上超过不同的单语模型。 想理解更多的AI技术干货，欢送上华为云的AI专区，目前有AI编程Python等六大实战营供大家收费学习。 点击关注，第一工夫理解华为云陈腐技术~

摘要：在理论开发过程中，免不了波及到混合编程，比方，对于python这种脚本语言，性能还是无限的，在一些对性能要求高的情景上面，还是须要应用c/c++来实现。那怎么做呢？咱们能应用pybind11作为桥梁，pybind11的长处是对C++ 11反对很好，API比较简单，当初咱们就简略记下Pybind11的入门操作。 1. pybind11简介与环境装置Pybind11 是一个轻量级只蕴含头文件的库，用于 Python 和 C++ 之间接口转换，能够为现有的 C++ 代码创立 Python 接口绑定。Pybind11 通过 C++ 编译时的自省来推断类型信息，来最大水平地缩小传统拓展 Python 模块时繁冗的样板代码， 曾经实现了 STL 数据结构、智能指针、类、函数重载、实例办法等到Python的转换，其中函数能够接管和返回自定义数据类型的值、指针或援用。 间接应用pip装置pip3 install pybind11因为pybind11依赖于pytest，所以在装置前须要先把pytest给装置上pip3 install pytest2. 求和函数首先，咱们编写一个C++源文件，命名为example.cpp。 // pybind11 头文件和命名空间#include <pybind11/pybind11.h>namespace py = pybind11;int add(int i, int j){ return i + j;}PYBIND11_MODULE(example, m){ // 可选，阐明这个模块是做什么的 m.doc() = "pybind11 example plugin"; //def( "给python调用办法名"， &实际操作的函数， "函数性能阐明" ). 其中函数性能阐明为可选 m.def("add", &add, "A function which adds two numbers", py::arg("i")=1, py::arg("j")=2);}PYBIND11_MODULE()宏函数将会创立一个函数，在由Python发动import语句时该函数将会被调用。模块名字“example”，由宏的第一个参数指定（千万不能呈现引号）。第二个参数"m"，定义了一个py::module的变量。函数py::module::def()生成绑定代码，将add()函数裸露给Python。 咱们应用CMake进行编译。首先写一个CMakeLists.txt。 cmake_minimum_required(VERSION 2.8.12)project(example)add_subdirectory(pybind11)pybind11_add_module(example example.cpp)就是CMakeList.txt和example.cpp放在一个目录上面。 ...

摘要：该文章次要介绍makefile，一种常用语GNU gcc编译的工具语言，同时LiteOS也是利用该文件对工程项目进行make构建生成执行文件的。LiteOS源码中应用makefile进行文件的批处理编译和连贯到生成文件，如果在应用LiteOS来设计工程时应用GNU编译器进行编译，个别会都会应用到makefile进行编译和链接程序，如果应用的Keil或IAR的编译器进行编译则在Keil IDE或IAR IDE中设置编译器信息和文件包换门路就能够了进行编译链接和输入文件。 1、makefile介绍简略的说makefile就是make执行的文件，将代码变成可行性文件的的过程叫做编译，组成一系列文件的编译叫做构建（build），Make是GNU提供的构建工具，次要用C、C++我的项目的构建编译过程，要学会应用Make，咱们就须要学会应用makefile编写，makefile，该文件形容了如何编译和链接由几个C源文件和几个头文件组成的文本编辑器。当明确要求时，makefile还能够通知make如何运行其余命令（例如，删除某些文件作为清理操作） 1.1 makefile 规定一个简略的makefile由具备以下形态的“规定”组成： target … : prerequisites … recipe … …target(指标)通常是由程序生成的文件的名称。指标的示例是可执行文件或指标文件。指标也能够是要执行的操作的名称，例如“clean”； prerequisites（前置条件）是一个文件，该文件用作创立指标的输出。一个指标通常取决于几个文件； recipe（命令）是一种要执行的动作。配方可能在同一行上或在本人的行上具备多个命令。请留神：您须要在每个配方行的结尾增加一个制表符！这是一个含糊的中央，引起了人们的留神。如果您心愿在食谱中应用制表符以外的其余字符作为前缀，则能够将.RECIPEPREFIX变量设置为其余字符 "指标"是必须的，不可省略；"前置条件"和"命令"都是可选的，然而两者之中必须至多存在一个。 一条规定阐明了如何以及何时从新制作作为特定规定指标的某些文件。 make依据创立或更新指标的先决条件执行办法。规定还能够解释如何以及何时执行某项操作。一个makefile可能蕴含除规定之外的其余文本，然而一个简略的makefile只需蕴含规定。规定看起来可能比此样例中显示的要简单一些，但所有规定或多或少都适宜该模式。 1.2Makefile 语法① # 示意正文 ② 通配符用来指定一组符合条件的文件名。Makefile 的通配符与 Bash 统一，次要有星号（）、问号（？）和 [...] 。比方， .o 示意所有后缀名为o的文件。 ③ %模式匹配 如须要编译当前目录下a.c和b.c两个文件，原来的写法是： a.o: a.cb.c: b.c利用%能够简写为： %.o : %.c在解决大量同类型文件时既能够利用%简写文件 ④ “=” 自定义变量 txt = Hello Worldtest: @echo $(txt)下面的 txt代替的了“Hello World” 同时基于“=” Makefile提供了（=、:=、？=、+=）四个赋值运算操作。 ⑤ 内置变量 Make有本人的操作变量，特指一些本人的性能命令；如：$(CC) 指向以后应用的编译器，$(MAKE) 指向以后应用的Make工具 具体变量规定可参考：https://www.gnu.org/software/... ⑥ 主动变量（Automatic Variables） makefile提供一些与规定相干的变量，罕用的有： （1）$@ -----指代以后指标 （2）$< -----指代第一个前置条件 ...

笨办法学io基本上在剽窃《笨办法学python》和《io语言手册》 练习0. 筹备工作 练习1. 第一个程序 练习2. 正文和“#”井号 练习3. 数字和数学计算 练习4. 变量 练习5. 更多的变量和打印 练习6. 字符串和文本 练习7. 还是赋值、拼接和打印 练习8. io语言的基本概念-原型 练习9. io语言的基本概念-都是对象 练习10. 读写文本 练习11. 读取目录中的文件名 练习12. 复制文件 练习13. 再来聊聊原型、对象和办法 练习14. return返回 练习15. List列表和map散列 练习16. 操作字符串 练习17. if条件表达式 练习18. 其余条件表达式 Io语言入门 一个应用Io语言实现的简略weblog 完结

去年，和公司的大佬探讨了一系列对于代码的代码化，还记录了一些笔记。在那之后，我开始了各种尝试：如何将代码转变动代码。原先有一些思路，而后过了一年之后，缓缓地练习，又有了一些新的播种。 咱们想要做的事件是：把任意的 A 语言转换为任意的 B 语言（PS：这里的任意 A 和任意 B 语言都是支流语言）。如此一来，咱们便能够： 疾速重写任何的零碎。与编程语言无关的领域建模。产生一个更弱小的 DSL。创立新的语言。引子 0：对立语言模型对立语言模型，即对不同的比编程语言进行形象，应用同一套数据结构形容编程语言。在我应用了 Golang + Antlr 实现了 Coca 之后，我意识到这是一条可行的计划。然而，因为 Coca 的架构和用处所限，外加之 Antlr 对于 Java 的反对远比 Go 要好，我并没有持续在 Coca 上施行这个计划。 于是乎，我开始了第二个尝试，应用 Kotlin + Antlr 来实现对不同语言的模型对立，也就是我的另外一个开源我的项目 Chapi。然而呢，随着一直的尝试，我发现了其中的难度和工作量比拟大： 编写不同语言的语法解析。社区上曾经有大量的成熟的轮子，其中最闻名的就是 Antlr 相干的语法解析。官网保护的代码仓库（grammars-v4）蕴含了大量的 Antlr 语法解析案例，能够找到市面上一些支流的和非主流的实现。设计对立语言模型。即设计出一套能兼容不同语言的语言模式。当然了，这是一个继续欠缺的过程，会随着更多语言的退出，变得更加残缺和简单。解析不同语言。即依据不同语言的语法个性，转换为上述的模型。从难度上来说，咱们能够看出技术难度次要是在步骤 1 和步骤 2。而步骤 3 呢，则是一个十分繁琐、工作量微小的体力活。咱们还须要相熟不同的编程语言，并一一解析对应的字段，能力转换每一个语言。 因而，我尝试建设起了 Chapi 的社区，而后手把手率领一群人干活。只管，对于不同的语言我曾经建设起了对立的编写模式：TDD + Tasking。仿佛，很多人对于 AST 有点放心，因而参加的人非常少。所以，对于其它语言的反对就不了了之。 相干资源： 具体的设计能够参考我写的那一篇：《如何为代码建模？》具体的实现能够参照：https://github.com/phodal/chapi引子 1：语法高亮的背地与此同时，哪怕有足够的人，Antlr 并非一个完满的答案。在编写不同语言的反对时，我仍旧遇到一系列的 Antlr 语法不反对的问题。如 JavaScript 的 Import，Java 的一些 Lambda 问题……。换句话来说，Antlr 官网只是保护这么一个库，实在的成果就不得而知了。 于是，我就回到了一条老路上，应用正则——当然不会本人写了。在那篇《编程语言的 IDE 反对》中，我提到了基于正则表达式来实现语法分析，其中介绍了两个编辑器的实现形式： ...

近日，怀着新语言的一门心思，在键盘上敲敲打打。golang的强类型有时候着实让人有点摸不着头脑（对于习惯了php的老人来说）下面是一个golang的例子 再看看命令行 虽然if中间的var赋值user挺蠢的，而且就golang的强类型申明user类型之后再来var显得很小白，但是梳理整个逻辑，发现了一个重要的信息点，甚至是背心出了一身冷汗！重现：最开始我想的是ResponseSuc里头统一返回user，所以就用了if else做user的数据处理，按照php的逻辑，第一个if里头不用var，直接user=****就行了，根本不用管类型。（所以var的出现，就是因为去掉var之后限制了user的类型而产生，为了语法不报错而不经过大脑，蠢哭） 结果看到了，就是第一个user打印出来了一大坨数据，而最下面的user没有数据。究其原因，就是因为两个user根本不是一个玩意儿 反思php为弱类型语言，这种非同类型赋值简直写起来不要太舒服。然而golang的语法和php对比，终于让我发现，弱类型的严重缺陷，见下图 注golang中if之前就已经开始报错，因为是非同类型的比较，程序根本运行不起来 注php里头可见0=="0"是true的 同理，可以验证null,""等特殊的玩意儿 那么有什么影响呢 好吧，虽然用了谷歌，还是追到了腾讯的ip上PHP弱类型在实战中导致的漏洞总结 附上php的类型比较图php.net 最后，帖子浏览完，感觉大部分PHP系统可能都在裸奔！ 友情链接《刑法》案例查询

简评：在大英博物馆 (British Museum) 的柔光中，人们只能勉强看到镌刻在这些古老泥板上的密密麻麻的楔形标记。这些细小的标记是世界上最古老的书写系统 —— 楔形文字的遗迹。古帝国的兴衰楔形文字起源于 5000 多年前的美索不达米亚，位于底格里斯河和幼发拉底河之间，也就是现在的伊拉克。它记录了一个长达 3000 年之久的、复杂而迷人的文明。从王室之间愤怒内斗的信件，到安抚一个任性婴儿的仪式，这些石碑让人们可以从另一个独特的视角了解历史初期的社会。它们记录了阿卡德、亚述和巴比伦帝国的兴衰，这是世界上第一个帝国。据估计，人们已经挖掘出了约50万块楔形文字板，但还有很多仍深埋地下。机器翻译约 150 年前，学者们首次破译楔形文字。然而，目前仍有约 90% 的楔形文字未被翻译出来。但是，这种情况可能会有所改变，这都要归功于现代工具 —— 机器翻译。多伦多大学亚述学研究员佩龙 (Emilie Page-Perron) 现在正在进行的一个项目，是用机器翻译公元前 21 世纪以来美索不达米亚文明的行政记录，数量多达 69000 份，其目的之一是为新的研究发掘过去。美索不达米亚文明孕育了车轮、天文学、一小时 60 分钟的计时制、地图、洪水和方舟的故事、以及第一部文学作品 ——《吉尔伽美什史诗》。这本诗集主要是用苏美尔语和阿卡德语写成的，能读懂这些语言的学者少之又少。除了石碑，还有 5 万多枚美索不达米亚雕刻印章散落在世界各地。几千年来，美索不达米亚人使用由雕刻石头制成的印章，这些印章被压入潮湿的粘土中，用来标记门、罐子、石板和其他物品。这些刻章中只有 1/10 被编入目录，更不用说翻译了。牛津大学亚述学教授达尔 (Jacob Dahl) 表示 —— 我们所获得的关于美索不达米亚文明的资料比希腊、罗马和古埃及的加起来还要多，但真正的挑战在于找到能读懂它们的人。佩龙与其团队正在对一个数据库中的 4000 个古代行政文本样本编写算法。这些行政文本包括交易和运输记录，比如把羊、芦苇束或啤酒运到寺庙或个人手中的记录。这些文字最初是用芦苇笔刻在粘土上的。现在，学者已经把它们音译成了我们的字母表。例如，苏美尔语中表示「大」的词可以写成楔形文字，也可以写成英文字母表中的「gal」。这些行政文书的措辞很简单。例如「第15天，厨房有 11 只母山羊」。这种特点使得它们特别适合被自动化处理。一旦算法学会了将样本文本翻译成英语，它们就能自动翻译其他经过音译的石碑。这些记录向我们展示了古代美索不达米亚人的日常生活，包括权力结构和贸易网络，同时还展示了社会历史的其他方面，如女工的角色。佩龙希望机器分析也能弄清苏美尔人的一些特征，这是至今仍困扰着现代学术界的难题。这种已经灭绝的语言与任何现代语言都没有联系，但却保存在以楔形文字书写的碑文中。这可能是我们与更古老，甚至没有历史记载的社会之间最后的联系。芬克尔是世界上顶尖的楔形文字专家之一。他在大英博物馆堆满书的办公室里讲解了手稿是如何慢慢被破译的，这多亏了一位国王的多语种铭文，就像罗塞塔石碑帮助研究人员理解了埃及象形文字一样。触碰古老宝藏多亏了先进的成像技术，现在任何人只要能上网就能接触到这些宝藏。比如，世界上现存最古老的皇家图书馆，人们正在将它数字化。这座图书馆位于尼尼微，由亚述国王亚述巴尼帕（Ashurbanipal）建造。虽然早在公元前 612 年，尼尼微遭遇洗劫时，这些碑文被火烤得又黑又硬，但上面的文字仍可辨认。新的成像技术让人们在处理这些古老且破损严重的文本时更加轻松。有了精细的图像，人们就有可能找出那些肉眼看不见的模糊标记。一个名为「楔形文字数字图书馆倡议」(Cuneiform Digital Library Initiative) 的项目，将储存在德黑兰、巴黎和牛津馆藏中的碑文及印章进行数字化处理。这个庞大的在线数据库已经包含了世界上约三分之一的楔形文字，以及一些未被破译的书面语言（如古伊朗的原始埃兰语）。如果没有这样庞大的数字资源，让机器进行翻译几乎是不可能的。数字化还帮助研究者们将散落在世界各地的文本拼凑起来。研究员曾对美索不达米亚的 200 多枚石印的 3D 图像进行了数字化处理。在试点项目中，他们使用了人工智能算法校验了 6 块碑文，并识别出在世界其他地方发现的与之匹配的石印。算法准确地挑选出了两块现存于意大利和美国的石碑，这两块石碑上盖的石印是一样的。在过去，想要将石印和印痕匹配起来困难重重，因为许多石印储存在数千英里之外的地方。而现在，人工智能的发展能帮助探索世界各地收藏品中蕴藏的丰富信息。破译古人的语言成像技术也改变了对于未破译文本的研究。对于数量少、具创造性文本的破译，人类往往比机器做得更好，人类有着对生活和组织方式的深入理解，以及高度的灵活性。例如，早期的楔形文字符号并不是线性排布的，而是简单地与画在周围的方框排在一起。原始埃兰语是三维立体的，一个圆印的深浅不同意义也不同。但是，技术可以放大、分享和比较图片的细节，加快了破译进程。佩龙希望机器最终能够翻译更复杂的苏美尔语石碑和其他语言，比如阿卡德语。也许有一天，我们将能够阅读所有古老文字的翻译版本。古代美索不达米亚的国王们深深地思考着过去和未来。他们崇敬前朝的楔形文字，将记录着他们的名字和成就的铭文埋藏地下，寄望后世的统治者会将荣耀归于自己。在某种程度上，他们的愿望已经实现。他们的经历过的战争和征服可能已经被大多数人遗忘，但是他们最强大的发明 —— 文字，在过去的几千年里助力了人类思想和技术的发展。而现在，人类开始训练机器从过去中学习。原文链接：The key to cracking long-dead languages？推荐阅读：人工智能缺陷与误觉：让机器产生幻觉的「怪异事件」欢迎关注微信号「极光开发者」

摘要： 在没有足够的训练数据时，本文详细介绍了如何使用FloydHub、fast.ai和PyTorch进行迁移学习。现在，人工智能的发展处于跳跃式阶段，我们也对AI在大型数据集的应用进展感到吃惊。更重要的是，那些我们没有跟踪的数十亿张照片或餐厅的评论并没有被遗漏掉：迁移学习技术让收集数据变得更加“容易”。另外，得益于PyTorch框架、fast.ai应用程序库以及FloydHub公司，小团队或者是个别开发人员也能轻松的应用这些方法。本文要讲的例子就是ULMFiT：Jeremy Howard和Sebastian Ruder在fast.ai展示了如何用几百个标记准确的对电影评论进行分类。除此之外，还有一个在通用英语文本语料库中训练的模型。除了英语文本资料库和标记对评论进行分类外，fast.ai还有一个小技巧，它拥有大量特定领域的文本：10万多个样本评论，来展示普通英语和电影评论之间的区别。这引发了我们的思考：至少得需要多少数据，才足以弥合训练示例和通用语言模型之间的差距？这并不是一个特别愚蠢的问题。Frame可以帮助Zendesk，Intercom和Slack等规模性公司标记、评价和理解与客户的对话。也就是说， “只要有足够的对话，我们就可以手动评价”和“我们有足够的数据从头训练一个模型”，这二者之间有很大的差距。仅仅几十个标签和几千条相关对话，这能够做什么？事实证明，这非常有用。在本文中，我们将使用相同的电影评论数据集来证明：即便是只有少部分的数据，数据迁移依然可以有效。更加详细的代码请参考ULMFiT。迁移什么？深度神经网络是当前最新人工智能背后的关键技术，比如理解图像、音频或文本。深度神经网络的核心是它由层（“深度”）组成，每个层都将输入转换为更接近网络训练答案的新的表示。我们通常会抱怨，不了解神经网络的中间层到底发生了什么……其实，它们通常被设计为更加清晰、可解释的角色！比如：很多语言模型利用嵌入层将单个单词或短语进行分类，将具有相似含义的单词或短语放在一起。举个例子来说，这将有助于翻译AI在需要使用“杰出”（illustrious）这个词的时候，会根据经验选择使用“伟大”（great）。现在变得更有趣了：一个“知道”“illustrious = great”的层不仅有利于翻译，还可以学习情绪估计，将不同的观点聚集起来。这就是迁移学习，也就是说模型在一个任务中学习到的东西可以对另外一个学习任务有帮助。事实上，这个特殊的例子特别受欢迎，以至于改进的通用语言模型已经成为一个全新的领域！ 迁移学习不仅有利于任务之间的转移：它可以帮助一般模型在特定环境中更好的工作。例如：一个通用的英语情绪模型或许可以预测电影评论，但是可能不知道“紧张、紧张的惊悚”是件好事。这就是Jeremy和Sebastian Rudder的通用语言模型微调文本分类（ULMFiT）的用武之地。他们对一个包含100,000个IMDB评论的通用语言模型做了改进。即便是只标记几百个单词，其余的单词也能够帮助AI学习审稿人经常用“杰出”或“很好”代替“紧张、紧绷”等，这很好的弥补了数据不足的缺陷。结果的准确度令我们感到惊讶：仅仅有500个标记示例，分类的准确度却高达94%。未被标记的数据最少需要多少？ULMFiT为NLP提供了一个有力的依据，使模型能够更有效的利用较小的数据集。在这项研究中，我们专注于回答以下问题：如果我们对标记示例的预算特别少，那么，得需要收集多少未标记的数据才能有效的使用迁移学习？为了解决这个问题，我们使用了大量固定的域数据池，并改变了标记示例的数量，来看看模型应该如何改进。将标记示例的数量保持不变，并改变未标记的其他域示例的数量。也就是说，我们的实验包括：1.语言建模（变量）2.语言任务（不变量）我们的语言任务、情感分类和原始的ULMFiT论文中的任务相同，另外，也使用了IMDB电影评论数据集。在实验中，标记情绪训练样本的数量保持在500个，500个样本可以用于很多小领域的研究，并且，有助于强调不同语言模型的差异提升能力。对于语言建模，我们改变了可用于语言任务的三种语言模型的域数据量：仅限ULM：这是使用Wikitext103预训练英语语言模型仅限域（domain）：仅在IMDB数据上的基于域训练的模型。ULM +域（domain）：ULMFiT模型训练这些模型的计算量特别大，最大的域训练可能需要几天的时间才能完成。为了加快训练速度和有效的执行网格搜索，我们使用了FloydHub。结果经过大约50个小时GPU处理，结果如下：从实验结果，我们可得知：使用33％的域数据，就可以获得75％数据的UMLFiT性能。令人惊讶的是，ULM + 2,000域示例的语言任务预测准确率约为85％。本文作者：【方向】阅读原文本文为云栖社区原创内容，未经允许不得转载。