微软应用Transformer模型开发之生成式AI“程式码自动完成”专利
https://bit.ly/3EAkzg0
针对ChatGPT，Google于2019年10月22日，获得美国专利局核准之一件专利案号为US
10,452,978 B2，其标题为“基于注意力序列转导神经网络”(Attention-based
sequence transduction neural networks)之发明专利[1]（以下称’978专利），目前’
978专利简单同族专利[2]数量有38件并分布在13国家，而被引用专利数量为11件，且还有
对应发表过的原始论文“Attention Is All You Need”[3]。本刊之前已分析过该篇’
978专利之相关介绍(Google Transformer模型专利 – ChatGPT自注意力机制之重要推手)
。
Google固然引领风潮率先推出Transformer模型专利，但商场上第一波ChatGPT成功拔得头
筹的却是微软，微软于2019年向软件开发商OpenAI投资10亿美元，由于持续看好OpenAI旗
下的聊天机器人ChatGPT的前景，随着2022年11月ChatGPT问世后使用热度横扫全球，使得
微软在2023年1月宣布拟再加码投资100亿美元。对于此，市场一度认为微软终于有机会在
这波AI军备竞赛中，打败软件业的巨头Google，使得微软的市值在同年2月突破2兆美元。
也许，大家会好奇，OpenAI与微软在生成式AI的专利布局状况又是如何？
笔者试图寻找OpenAI是否也有相关生成式AI的相关专利，不过截至目前，发现OpenAI似乎
没有申请过相关专利，也许这跟富比士(Forbes)的推测有关：OpenAI的早期本身就是非营
利组织[4]。正因为初期的OpenAI并非以营利为目的，所以在专利申请方面较不在意。
微软的’984专利之Transformer模型的应用
既然暂未发现OpenAI有生成式AI相关专利，那么就来找OpenAI的最大金主微软，看看微软
对于生成式AI或Transformer模型的相关专利有哪些？基于与上次Google篇的同样条件去
检索美国专利数据库，发现微软不仅相关专利的数量不似Google来得多，而且在质量上似
乎也不如Google。笔者最后筛选出的数十篇相关专利，然后再利用ChatGPT快速针对几十
篇的专利说明书做摘要后，决定就来讨论其中一篇发明专利案号为US 11,262,984 B2之“
多语言程式码行自动完成系统”(Multi-Lingual Line-of-code Completion System)[5]
（以下称’984专利）。’984专利在2019年11月11日申请，并在2022年3月1日获准，从申
请到获准共历时28个月。
之所以选定’984专利来做讨论，是因为在微软所有生成式AI或Transformer模型的专利中
，它具有以下特点：(1)简单同族专利数量5件并分布在3个国家，而被引用的专利数量有
19件（包含已获证与其获证之前的申请案）；(2)其系完全基于Transformer模型而做的衍
生应用；以及，(3)可能与微软近来爆红的Copilot产品功能有关。其中，针对第(2)点，
微软’984专利在实施例中，虽然洋洋洒洒用自己的方式大篇幅描述Transformer模型，但
本质上却与Google的原始论文或Google的’978专利所描述的Transformer模型的技术原理
一样，差别在于微软在’984专利中主张，透过应用Transformer模型，开发人员在“部分
形成的程式码行”[6](partially-formed line-of-code)[7]编写程式时，可以“自动完
成”接续未完成的程式码撰写。
传统的程式码行自动完成(line-of-code completion)功能的缺点
什么是程式码自动完成？简单来说，程式码自动完成是一种软件开发工具的其中一项功能
，能够在程式码编辑过程中提供智慧化的建议和自动接续填写功能，以提升程式开发人员
的开发速度。程式开发人员于撰拟程式时，通常会有几个可能，如图1所示，像是笔者常
用R语言的整合开发环境（Integrated Development Environment，简称IDE）RStudio介
面的一部分，其本身就是一个程式码编辑器，只是不含Transformer模型的功能。图1所显
示的是撰写程式码时，在IDE接口呈现完全无误的状态，其中箭头所指示的数字就是所谓
的“程式码行”(line-of-code)。反之，在开发人员撰写程式码的过程中，也有可能发生
一种情况，亦即如执行某程式码行发生语法结构上的错误时，此时IDE接口就会出现错误
提示，以提醒开发人员需要针对该程式码行除错(debug)，如图2所示。

图1 程式码行呈现完全无误的状态

图2 执行程式码行发生语法结构错误时，出现错误提示
再来图3则是开发人员撰写程式码过程中，IDE会在其背景侦测每一行的程式码行，然后对
应弹出一项清单，清单中自动出现可能的相关函数、变量、方法、关键字或引数
(argument)等候选提示或建议，以协助开发人员手动选择适合的建议，以接续未完成的程
式码撰写，而这样的动作就称为“程式码行自动完成”(line-of-code completion)。还
有另一种状况，开发人员透过按下tab键后自动补齐程式码，例如在IDE接口已有个名为
model的变量名称，当再次输入mod，然后再按下tab键后，IDE将自动完成该变量名称
model。

图3 撰写程式码过程中出现候选提示
然而，传统的程式码行自动完成功能，虽然可协助开发人员在编写程式码时，更快地输入
有关的函数、变量、方法、关键字或引数，但它却无法“推理”多行程式码之间的逻辑为
何。以图1、3为例，图1的第10行正确无误的语法结构，亦即“pred <
stats::predict(model, newdata = new, type = “response”)”，才是笔者真实想要
编写的程式码。然而，回到图3所示，笔者做了一个实验，刻意将引数“type = “
response””字段予以删除，试试看会出现什么样的提示或警告，结果发现IDE接口所弹
出的所有候选提示，例如”object =”、”… = ”、”newdata”、”pred”、…等很多
提示都跟笔者真实想要输入的字串“type = “response””无关，因此最后还是得靠过
去程式撰写经验，将“type = “response””予以手动输入完成第10行程式码行的撰写
。由此可见，传统的程式码行自动完成功能，尚无法真正推理出多程式码行之间的涵义，
这就是它的缺点。
微软’984专利利用Transformer模型改进习知程式码行自动完成功能
微软在’984专利中宣称，其程式码行自动完成功能系透过Transformer模型训练而得以改
进习知的缺点，甚至为了降低Transformer模型的训练时间，还引入“多头自注意力层”
(multi-head self-attention layer)。至于大型的训练资料集，则来自如GitHub或其他
程式码储存库中的各种程式语言（例如C、Java、Python、C++）的原始码(source code)
，而训练资料集中的各原始码与注解，都会被编码成数值型向量。这些数值型向量是由断
词(token)[8]和/或子断词(subtoken)组成的序列。在程式语言中常用的元素被编码为断
词，而较不常出现的元素，则被编码成一些组合的字符为子断词。这样的作法，基本上就
是利用了Google在原始论文“Attention Is All You Need”与其获证的专利中所提及的
“词嵌入”(word embedding)[9]与“位置嵌入”(positional embedding)[10]等技术，
如此不仅可以减少大型词汇的储存，而且还有更好的准确度。
以上所述的断词，在自然语言处理的过程是一个很重要而基础的工作，例如“
transformer model <\n>”这样的一序列，可被切割为trans、former、model与”\n”（
此称为换行符，对于程式编辑器而言也是一个字符，通常发生于程式码行的尾端
(end-of-line)），而其对应的编码可为[43678, 67971, 14560, 98765]之数值型向量。
这样编码后的结果就称为4个token[11]，以上的对于理解接下来要谈的’984专利的发明
内容非常重要。
微软在’984专利中的独立项共有3项，分别为独立项1的系统项、独立项9的方法项，以及
独立项15的装置项。虽然’984专利的标题只提到系统，但从’984专利的实施例与代表图
的技术揭露来看，其主要的技术仍是演算方法的保护，故以下就以独立项9与其附属项等
方法项，做一些重要技术特征的说明。
独立项9揭露一种方法，其包含[12]：
1. 在IDE编写程式码过程中，IDE的编辑器，会检视各断词被输入至一未完成的程式码行
(line-of-code)之状况；
2. 递回式(iteratively)执行一波束搜寻(beam search)，以产生多个断词候选(token
candidates)，并陆续完成程式码行的撰写，其中该波束搜寻是从具有注意力机制的解码
器，所产生的多个断词机率中对应生成包含多个字串所组成的一候选清单；
3. 合并该候选清单中的多个字串，使该多个字串成为一候选序列；以及
4. 一旦在IDE中侦测到某一符号字符，就输出至少一候选序列。
以上所述的波束搜寻是一种搜寻算法，通常用于生成式模型，特别是在自然语言处理等
序列生成之任务，它在每个树状节点都代表着，经由Transformer模型的机率分布，所生
成的每一个断词或子断词，借此从众多的断词候选中找出最有可能的前k个断词。
简言之，关于以上所述的具体范例，’984专利给出如图4所示，其显示开发人员在IDE介
面上，正在编写某一程式码行（标号702中的第36行）时，IDE的编辑器侦测到“=”符号
（即前述(d)中所述的“符号字符”），就对应弹出一候选清单（标号704）。该候选清单
（标号704）包含5个候选序列（标号706-714），而这5个候选序列的排序，是依据由大而
小的机率一一往下陈列出。此外，各候选序列中，如tf、train、Adam、Optimizer、
learning_rate、Grad、ient、Des、cent、…等断词，都能自动组合为一连串且有顺序的
序列，以接续自动完成尚未完成的程式码行编写。

图4 在IDE接口上侦测到“=”而弹出候选清单（标号704）之示意图
微软的‘984专利相较于习知的程式码行自动完成功能而言，其最大的特色在于，它可以
从程式码之间的逻辑关系而自动推论出，开发人员可能会用到的程式码提示或建议，并且
自动帮忙补齐之后一长串的相关函数、变量、方法、关键字或引数等程式码编写，而且准
确度还很高。微软的‘984专利主要的贡献在于，过去几年很多开发人员只能天马行空的
想像，是否有一天也能靠AI协助他们撰写程式码，没想到生成式AI居然已能实际应用在具
有高难度的自动生成程式码这样的场景，因此可预期未来生成式AI不仅可自动生成程式码
，也许反过来还能“指导”科学家或工程师导出更具实际应用价值的算法，以解决当今
许多亟待解决的问题，例如资讯安全、病毒变种、气候异常、癌症医疗等攸关民生但始终
迄无最佳解决方案之重要议题。
101专利标的适格性议题
其实，微软的’984专利主要还是AI算法，而算法的专利申请相较于一般的实体装置
、系统而言，通常会先面临到因美国专利法第101条[13]专利适格性问题而遭核驳。由于
AI相关专利常以算法为中心，此类专利申请范围，在专利审查机关或在法院专利维权过
程中，常面临适格标的之挑战而遭遇障碍，为鼓励AI科技产业之发展，防范许多AI申请动
辄于第一回合即中箭落马，故美国专利商标局(USPTO)于2019年1月，发布修订专利适格标
的指南(2019 Revised Patent Subject Matter Eligibility Guidance)、并于同年10月
再颁专利适格指南更新(PEG: Patent Eligibility Guidance Update)[14] ，该指南导引
如何使AI相关技术具适格性，其揭示之专利申请策略影响深远，将增加AI相关发明获得专
利之机会。依该指南原则：Step 2A Prong 2探究是否“整合到一项实际应用”
(integrated into a practical application)之中，Step 2B则确定是否存在发明概念
(inventive concept)，二者之一如肯定，则即便请求项指涉抽象概念，也不会落入不适
格之情况[15]。
微软这篇’984专利请求项的权利保护范围，正是在习知的程式码编辑器上，新增一具有
注意力机制之Transformer模型的算法技术特征，透过应用该特征而整合自然语言处理
；’984专利之所以能克服101条专利适格性，就是将具有注意力机制的Transformer模型
，甚至于根据所产生不同断词的机率，而能转化到程式码编辑器上自动生成程式码撰写、
注解等实际应用，而使之具有专利适格性[16]。
小结
微软的“多语言程式码行自动完成系统”专利，就像是“读心术”一般，能读懂软件开发
人员的心思，其技术的本质正是基于Google的Transformer模型架构而设计，只不过微软
进一步将其应用锁定在程式码的自动生成。相较于传统的程式码行自动完成功能，’984
专利显然更能理解多行程式码之间的上下文涵义，因而能够提供更准确、更弹性地协助开
发人员完成程式码的撰写。此外，透过Transformer模型的训练后，可支援多种程式语言
的语法结构与逻辑，具有相当好的通用性。最后，可能令大家感到好奇的是，微软的“多
语言程式码行自动完成系统”之专利是否对应到Copilot产品上的某一项功能？据市场消
息，Copilot产品卖得还不错，那么身为自注意力机制的Transformer模型原创者Google，
竞争态势下难道仍会无动于衷吗？(狭路相逢勇者胜