微軟應用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所示。
https://imgur.com/it4Lry0
圖1 程式碼行呈現完全無誤的狀態
https://imgur.com/0lEQKPw
圖2 執行程式碼行發生語法結構錯誤時，出現錯誤提示
再來圖3則是開發人員撰寫程式碼過程中，IDE會在其背景偵測每一行的程式碼行，然後對
應彈出一項清單，清單中自動出現可能的相關函數、變數、方法、關鍵字或引數
(argument)等候選提示或建議，以協助開發人員手動選擇適合的建議，以接續未完成的程
式碼撰寫，而這樣的動作就稱為「程式碼行自動完成」(line-of-code completion)。還
有另一種狀況，開發人員透過按下tab鍵後自動補齊程式碼，例如在IDE介面已有個名為
model的變數名稱，當再次輸入mod，然後再按下tab鍵後，IDE將自動完成該變數名稱
model。
https://imgur.com/jfSN2Cz
圖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、…等斷詞，都能自動組合為一連串且有順序的
序列，以接續自動完成尚未完成的程式碼行編寫。
https://imgur.com/MRsyRRd
圖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，
競爭態勢下難道仍會無動於衷嗎？(狹路相逢勇者勝