夕小瑤科技說 原創
作者 | 夕小瑤編輯部
OpenAI o1大火之後，國內外上演的AI推理能力競賽可以說是2024下半年AI領域最大看點了。
甚至前陣子，還有一個很火的開源專案試圖透過prompt工程來讓Claude 3.5具備類o1的推理能力。
顯然，如果你是技術出身，一眼就會知道這種方法是不可能work的，它只會獲得“表演性推理”的能力。
而OpenAI o1的推理能力是什麼特點呢？
根據官方的說法&case驗證：
透過強化學習，o1 學會磨練其思維鏈並改進它使用的策略。它學會識別和糾正錯誤。它學會了將棘手的步驟分解為更簡單的步驟。它學會了在當前方法不起作用時嘗試不同的方法。此過程顯著提高了模型的推理能力。
顯然，要實現這樣複雜的類人推理能力，純靠暴力的網際網路語料統計訓練是一定做不到的。因為——
網際網路上的資料，承載的是“人類思考過程後的結果”，它是個產物，而不是過程本身。
而思維推理，則是過程。
這個“過程資料”，都不用說網際網路了，甚至在o1之前，任何企業內部都不可能有這個資料——畢竟誰會閒的把自己腦子裡過掉的東西原封不動寫下來發到網際網路上呢。
但有一個領域例外，那就是數學。
數學的推理過程，你能在網際網路上找到大量推導過程。
這也是為什麼，很多類o1模型，會非常強調“數學”能力。因為這個領域的過程資料最容易得到。
而像OpenAI o1表現非常驚豔的程式設計能力，字謎甚至醫學問題，這些領域的過程資料在網際網路上是不存在的。在筆者看來，能否真的把數學之外的過程推理能力大幅提升上來，才更能考驗一個類o1模型是否“硬核”。
我這兩天就恰好遇到一個程式設計問題，硬核到主流AI大模型全崩：
我想要python實現一段程式碼支援一個操作，就是將我在命令列裡輸入過的query按照時間順序cache到本地的一個檔案裡和記憶體裡，如果我在命令列裡按方向鍵上或方向鍵下，就能切換到上一個輸入的query或者下一個輸入的query（像使用bash那樣）。如果按方向鍵左或右，則能夠移動游標來編輯文字（而不是輸入一個方向字元）；移動游標或刪除的時候，需要支援中文漢字刪除，不能把漢字拆分成多個char去分別刪除不要在命令列裡出現這種把方向鍵當做查詢輸入的情況，而是去解析方向鍵：請輸入搜尋查詢: ^[[A^[[A^[[B^[[B^[[A^[[B
如果你是程式設計師，那你肯定知道我在講什麼。如果不是，不妨轉給你的程式設計師朋友為難他一下。
還是漏個題吧：python自帶的input函式，從命令列裡接收輸入，預設不支援中文，並且方向鍵不能控制，這裡我想實現一個“智慧輸入框”，像bash命令列一樣，還能透過方向鍵檢視歷史輸入並持久化記憶。
我首先把問題拋給了GPT-4o和Claude 3.5 Sonnet(New)，這兩個“老一代”大模型中曾經的程式設計王者。
來，執行一下GPT-4o生成的這個程式碼。
結果，當我輸入了幾個漢字後就：
好傢伙，你是把中文給我轉火星文了嗎。
再來看看Claude 3.5 Sonnet交的卷子，這個曾經的程式設計強者。
執行一下，發現沒有中文亂碼問題，但方向鍵移動游標卻玩兩下就失靈了——
算了，老一代的程式設計模型肯定不指望了。必須要上先進的類o1正規化模型了。
我還測試了前陣子國內釋出的某個類o1模型，
輸出是非常的長，但我一跑程式碼，中文輸入不了，也沒解決。
難道除了o1，真的地球上就沒一個模型能解決這個問題了嗎！
等等，我突然想到，上海 AI Lab前兩天也悄悄上線了一個類o1強推理模型，叫「書生InternThinker」。
來，試一下吧！
ps：長圖預警
有了前述國內外模型的一連串翻車，我本來沒抱啥希望。但，運行了一下它生成的程式碼後：
臥*，中文支援&游標移動這麼絲滑的嗎。
好，關掉重執行，試試query記憶功能，看能不能透過上下方向鍵，還原出我們的兩次歷史輸入——
完美，全部需求都支援到位了。
對此我來了興趣，準備再測測InternThinker的其他推理能力，是否也這麼穩。
等不及的小夥伴，可以去這裡測試 https://internlm-chat.intern-ai.org.cn
我先找了道今年難倒不少考生的高考數學題，測一把：
三個問題都答對了。還是穩（正確答案截圖列在這兒）
複雜數學可以，難倒一眾博士生的“小學奧數題”我也準備為難它一下。
26-63=1，移動哪個數字能讓等式成立
別小看這道題，我親測過，GPT-4o和最新版Claude 3.5 Sonnet是集體陣亡的——
來，我不信InternThinker你能再次吊打gpt-4o和claude3.5sonnet。
臥*，竟然真的做對了。
這道題跟本文開頭的程式設計題一樣，據筆者所知，目前為止就只有OpenAI o1模型和書生InternThinker模型解對了。
而且不知道你們有沒有注意到，書生InternThinker模型絲毫沒有像o1那樣掩飾自己的思維鏈過程，不怕被別人蒸餾。從這個open程度來說，真的值得推給OpenAI讓其羞愧一下。
我仔細研究了下它的思維鏈，我發現它確實不是表演式思考。以第一個程式設計case為例，從下圖可以看出，它是實實在在的在除錯程式碼、反思總結：
從思維鏈內部來看，中間過程中寫過有bug的程式碼，但從它命名為“Review”的思考部分，說明它具備自我反思的能力，發現了bug並進行程式碼修正，直到完成一個推理邏輯自洽的程式碼版本。
o1強推理的體現，就是學會識別和糾正錯誤並改進它使用的策略。
這個過程，確實非常符合一個程式設計師程式設計過程。
拆解到這裡，我幾乎可以100%的猜測，它一定是想辦法合成了大量的“程式設計過程資料”加入到了模型的訓練過程。
於是，我深扒了一下這個書生模型。
果然，我從官方的公眾號文章報道里，發現了關鍵。
這個「通專協作」的合成數據構造方法怎麼理解呢？
根據筆者的理解，要合成InternThinker的思維過程資料，首先是透過基座能力足夠強的專家模型，來為手上的複雜推理任務取樣出足夠多的“思維鏈”。在這個思維鏈的候選集中，很可能就包含了一條“完美思維鏈”或一些“比較不錯的思維鏈”。而另一個通用模型，則主打“監督陪伴”，負責觀察、分析和改進思維鏈的質量和可讀性。這兩個過程交代迭代，最終產出一條正確的思維鏈，即最終的“過程”訓練資料。
看到這裡，你可能很快就發現了問題的關鍵——我怎麼能知道大量取樣的思維鏈候選中，哪一條是正確或比較不錯的呢？
人工標註可能是最容易想到的。但上海AI Lab團隊還為此構建了大規模沙盒環境，來批次解決掉那些可以良好形式化定義的推理任務。
根據官方的報道，上海AI Lab團隊，為這個模型的訓練和推理，特意構造了一個大規模沙盒環境來拿到思維過程的反饋訊號。這裡面也包括了“程式設計沙盒”。
根據筆者的理解，像“程式碼寫的對不對”，“數學公式的計算結果對不對”，都可以透過推理任務沙盒來輔助驗證當下計算/中間結果的正確性，從而為思維過程提供反饋訊號，進而驗證某條思維鏈是否合理、正確。
ps：顯然，這個推理任務的沙盒工程量相當大。比如程式設計沙盒中，就包含了C++、python、java等幾十種程式語言的執行編譯環境。而程式碼之外的通用推理任務沙盒就更不知道有多少了。
當然，還有程式碼以外的通用推理任務沙盒，來獲取反饋訊號。
這些過程資料雖然在網際網路上不存在，但上海AI Lab透過“通、專模型協作+大規模推理沙盒”的方式，確實能為程式設計、謎題等推理任務大量獲取到珍貴的過程資料，包括了50多種不同思維方式的推理任務的思考過程。
這個沙盒的概念，就像強化學習中的環境的概念。大模型能透過這個環境，來為程式設計這種可以形式化驗證的任務，檢驗其所構想的“過程結果”是否真的達到了“驗收標準”，從而拿到明確的reward訊號，進而最佳化模型的引數。
此外，官方還提到了“人機協同策略生成”，盲猜也為高質量的思維鏈生成或標註引入了人工資料，進一步解決掉其他難以建模或基座模型難以取樣出良好思維鏈的場景。
模型基於這些珍貴的過程資料用RL正規化加以訓練，便可以學會像人一樣求解那些需要大量複雜推理的任務。這也難怪，InternThinker的強大推理能力，遠不止解數學題這麼簡單。
除此之外，我還發現，背後獨創了一套有意思的模型範式——元動作思考正規化。
這個正規化，很像大名鼎鼎ReAct[1]正規化的豪華升級版。
這個元動作思考正規化，包含了“理解、知識回憶、規劃、執行、反思、總結”等一系列類人的思考步驟。仔細觀察一下前面InternThinker解程式設計題和數學題的思維鏈，你會發現其跟這個元動作推理正規化能非常好的吻合上。
例如，對於數學case來說。
-
先是審題，即理解題目的意思，求解啥問題。這步對應就是理解任務和理解需求。 -
關聯已經習得的知識，比如條件機率、線性變換，這步對應的是知識回憶、經驗關聯。 -
分析解題的步驟，這裡本質是拆解和規劃解決步驟。 -
以上都搞清楚後，就可以開始動手解題了，這步其實就是在執行。 -
最後就是檢查，也就是反思和調整的過程。
從第一性原理出發，傳統的鏈式思維，比較像暴力列舉，而讓大模型顯式的羅列所有可能性，這無疑非常的不像一個“優等生”的腦袋；InternThinker的這套啟發式的思維正規化，無疑更像一個經過良好思維培訓的“優等生”的解題習慣，效率要高得多。
最後，不得不強調一下，這個書生InternThinker的模型，來自上海人工智慧實驗室，這也是書生系列模型首次面向公眾開放試用。
近期如果再有人問我國內推理能力最接近OpenAI o1模型的是誰，我會毫不猶豫的甩他一個連結：
https://internlm-chat.intern-ai.org.cn
參考資料
ReAct: Synergizing Reasoning and Acting in Language Models https://arxiv.org/abs/2210.03629