llm 0.37 新增模型選擇並更改預設設定
Simon Willison 於 11 月 2 日發布 llm 0.37，新增模型選項之餘，亦更改了從未自行選擇預設模型的用戶所使用的設定。這次更新結合更簡易的設定方式，並引出一個實際問題：開發人員可在多大程度上引入模型選擇，同時又不令既有工作流程變得更難預測？
LLM 是 Willison 用來存取語言模型的命令列介面和 Python 函式庫，處於應用程式與其使用模型之間。最新版本令這個連接角色更為明確。開發人員可更簡單地註冊相容服務，而嵌入支援亦擴展至處理不同媒體類型。
可作比較的是直接連接個別供應商，以及 Ollama 等本機模型工具。共用介面可減少這些選擇之間的設定工作，但不代表其行為完全一致。這一差異連繫了本次發布的主要功能、可靠性修正，以及 Willison 審閱 AI 輔助貢獻的經驗。
llm 0.37 除模型清單外還改變了甚麼
這次發布除了透過工具提供更多模型外，亦改變了開發人員選擇及連接模型的方式。
發布公告指，這次更新匯集了約兩個月的工作成果。它加入 gpt-6.1-sol 和 gpt-6.1-terra，引入 llm openai endpoint add，並將備用模型改為 gpt-6-luna。當用戶未有自行選擇預設模型時，便會套用這項預設變更。
這些屬於不同類型的更新。新增具名模型是擴展現有選單；新增端點管理則改變了開發人員維護該選單的方式；更改備用設定，則會影響用戶未有明確指定模型時所發生的情況。
端點是軟件發送模型請求的服務位址。OpenAI 相容端點會按照與 OpenAI 應用程式介面（API）相關的慣例接受請求。相容性讓既有客戶端毋須採用完全不同的整合方式，也可連接其他服務。
對開發人員而言，可用模型與已選模型之間的分別值得注意。新增項目在有人選用前不會產生作用；變更備用設定，則可能影響從未指定模型的既有指令。
試想一名開發人員以明確模型選擇執行定期摘要工作。這項選擇令預期依賴關係清晰可見。另一名同事執行其他方面相近、卻沒有該選擇的指令時，便會依賴環境的預設設定。
兩種做法本身都不一定有錯。預設設定讓人毋須預先作出每項決定也能開始；明確選擇則有助團隊解釋，為何某個工作流程會在升級或環境變更後出現不同表現。
本次發布亦擴展了對類型化嵌入附件的支援。嵌入是一種用於按語義比較內容的數值表示方式。類型化附件會保留進入該處理程序的內容類別資訊，而非把每項二進制輸入一概視為相同。
這一點很重要，因為可接收媒體的模型所需資訊不只原始位元組。周邊軟件必須說明附件代表影像、音訊，還是其他受支援輸入。
更廣泛的改變在於架構。LLM 在維持共用介面的同時，亦要容納模型選擇、服務設定及輸入處理上的差異。隨着開發人員以同一工具處理更多類型的工作，這些責任會變得更明顯。
因此，評估 llm 0.37 的讀者應把存取能力與行為分開看待。這次發布擴展並整理了存取方式；某個特定工作流程是否有所改善，仍取決於該流程的輸入、輸出及要求。
這一差異亦解釋了，為何一次包含熟悉模型新增項目的發布，值得在模型名稱以外獲得關注。設定選擇對可重複性有長遠影響，遠在公告不再受到注意之後。
更易切換模型，責任落在工作流程擁有人身上
模型切換可減少整合阻力，但仍須有人為切換的後果負責。
最直接受惠的是在託管服務與本機模型之間進行實驗的開發人員。共用客戶端可讓他們毋須為每次評估重建基本請求處理機制。當實驗發展成定期工作時，這種便利便更具影響。
原型開發通常會問：某個模型能否完成任務？運作中的工作流程還會問：結果是否以可接受的格式、在可接受的條件下交付？即使函式庫簡化了連接，這些問題仍屬應用程式擁有人的責任。
想像一個工程團隊根據內部事故報告產生摘要。在探索階段，團隊會以相同文件測試不同模型。當同事開始依賴這些摘要時，一致性便成為產品的一部分。
一項令文字更易閱讀的模型變更，仍可能遺漏某項操作細節。另一項變更可能保留所有細節，卻引入下游應用程式無法接受的格式。兩種結果都不會由成功設定端點所反映。
對該團隊而言，壓力來自更易進行的實驗與既有期望相遇。因而必須在把候選模型定為日常選擇前，先界定可接受的行為。
模型切換正是在這裏成為組織議題。設定客戶端的人未必是審閱摘要的人，而批准資料存取的人亦可能另有不同責任。
共用介面可能令這些界線不那麼明顯，因為指令在不同環境中看來相當熟悉。熟悉的語法不應取代對資訊流向及輸出評估方式作出的明確決定。
LLM 現有的記錄控制說明了這項責任的另一部分。該工具通常會在本機資料庫中記錄提示詞及回應，用戶亦可關閉記錄，包括針對個別請求。
記錄可協助解釋結果為何改變，但同時也會建立一份在工作流程中提交資訊的獨立紀錄。評估模型的開發人員需要同時考慮遠端請求及本機紀錄。
當一項有用實驗透過複製指令變成團隊慣例時，這點尤其相關。指令可能比原來有關保留期限、模型選擇及可接受來源材料的假設傳播得更容易。
對於建立可搜尋知識庫的團隊而言，同一所有權問題會延伸至初始模型呼叫以外。必須有人維護來源身分、存取預期，以及檢索材料與生成答案之間的關係。
這些是實際影響，並非證明這次發布為每名用戶帶來新的管治責任。個人實驗與共享的生產流程有不同需要。
共同教訓較為狹窄：更易設定令評估更容易開始，但並不能決定某個模型何時已值得置於其他人信任的工作流程中。
共用介面不保證共同行為
OpenAI 相容性提供的是連接慣例，並不保證每個後端均支援相同工作流程。
LLM 的端點設定文件說明，除了外掛程式外，亦支援額外的相容模型。外掛程式是為主要應用程式增添功能或供應商整合的擴充功能。
這讓開發人員有不同途徑進入共同工作環境。相容端點可重用熟悉的請求慣例；供應商專用擴充功能則可容納不符合這些慣例的行為。
關鍵比較在於，共用介面的便利性與直接整合的針對性。共用介面令常見工作更易重複；直接整合則更明確地呈現供應商本身的功能及假設。
兩種途徑並非在每種情況下都有絕對優勢。正確選擇取決於應用程式實際需要哪些功能，以及需要保留多少供應商專屬行為。
Ollama 是一項有用參照，因為它同時支援本機模型使用及相容客戶端連接。其相容性文件明確說明支援 OpenAI API 的部分功能。
這項限定很重要。開發人員應把相容性理解為對受支援操作的說明，而非完全可互換性的保證。一項請求在基本示範中成功，所能證明的遠少於完整應用程式測試。
例如，某個應用程式可能要求對話在多次請求之間保留狀態；另一個可能依賴特定機制呼叫外部功能。相近的請求語法並不能證明兩項要求可在每項服務中運作。
相關評估應依循應用程式的行為。模型能否接收預期輸入？服務能否返回所需輸出？當它拒絕某個選項、提早停止或返回錯誤時，會發生甚麼？
當模型切換在腳本內進行時，這些問題便更重要。互動式用戶可察覺意外回應並作出調整；無人看管的程序則需要明確處理同樣的意外。
端點管理功能針對的是一個更具體問題：維護可重用設定。註冊令服務更易再次選擇，但不代表該服務適合先前透過另一模型執行的每項指令。
這亦是為何不應把 OpenAI 相容路徑誤解為可獨立於供應商決策。共用客戶端仍依賴所選服務的可用性、受支援功能及其對請求的詮釋。
因此，這次發布強化了一種有用的中間立場。開發人員可將工作流程的部分環節標準化，同時為個別後端保留審慎的例外安排。這種做法要求了解哪些假設是共通的，哪些仍屬供應商專有。
模型切換最適合作為受控能力看待。若把它視為自動等同，便會抹去開發人員正要評估的差異。
類型化嵌入令媒體差異更清晰可見
支援更多輸入類型，即使模型負責數值轉換，周邊資料處理仍變得更重要。
Willison 指出 Gemini Embedding 2 是進行附件變更的原因之一。Google 介紹多模態嵌入，可將文字、影像、影片、音訊及文件置於共享數值空間中表示。
多模態是指系統可處理不同形式的輸入，例如文字和影像。Google 將這個共享空間描述為一種可跨越不同形式比較語義的方式。
它與純文字搜尋的分別很具體。文字查詢可尋找相關媒體，而毋須原始項目包含完全相同的查詢字詞。能否檢索到有用結果，仍取決於模型及資料集合。
Google 的產品頁面列出了來自媒體及法律科技機構的客戶帳戶。這些帳戶描述了在不同媒體類型中尋找相關資料的興趣。它們提供的是需求例子，而非對 LLM 實作的獨立驗證。
對於 llm 0.37 而言，較聚焦的開發在於輸入處理。保留附件的類型，能為整合提供正確路由支援內容所需的資訊。這是運用強大模型的基礎設施，而非搜尋品質有所提升的證據。
設想一個假設性的產品研究檔案庫，當中包含訪談筆記、螢幕錄影和截圖。有關令人困惑介面的查詢，可能在任何一種素材中都有相關證據。
吸引人的承諾，是在整個檔案庫中提供單一搜尋體驗。實際運作上的要求則更細緻：保留每個項目是甚麼，以及它來自何處。
有用的搜尋結果必須帶人們返回可供檢視的證據。單憑數值相似度分數，無法解釋截圖的脈絡。相關的錄影亦不會自動指出讀者所需的確切時刻。
這正是為何即使這項功能聽起來很小，帶有類型的附件仍值得關注。媒體之間的差異，必須能由原始素材一路保留至模型輸入，然後再回到可用的結果。
類型資訊並不能解決每一個步驟。開發人員仍需決定內容如何分割、如何保留來源參照，以及如何向使用者呈現結果。
把長錄影分成較小單位，會改變搜尋系統可傳回的內容。只保留檔案層級的參照，與傳回相關段落或時刻，會帶來不同體驗。
這些選擇亦會影響評估。搜尋系統可以傳回與查詢有關的內容，卻未必傳回能解決問題的證據。團隊需要有能凸顯這種分別的例子。
對個人檔案庫而言，關聯較鬆散的匹配結果仍可能有用。對共享研究流程而言，讀者或需要在查詢、檢索項目與由此得出的結論之間，建立更清晰的聯繫。
這次發布在介面層面為更豐富的輸入騰出空間。下一步的工程工作則圍繞這些輸入：保留脈絡、驗證檢索，以及讓所得證據易於理解。
換一種說法，這就是核心取捨。更多內容可透過共用工具取得，而確保結果具意義的責任仍由應用程式承擔。
可靠性修正為「更易存取」的承諾加上條件
成功的模型回應只是可靠工作流程的一部分；周邊軟件亦必須正確處理控制、儲存和失敗情況。
發布說明包括涉及記錄、工具執行及嵌入儲存的修正。這些細節值得注意，因為它們關乎應用程式在模型答案之外可依賴的部分。
工具呼叫是模型要求軟件執行某項功能的請求。應用程式決定如何把該請求轉化為行動。因此，圍繞該執行的控制檢查，與模型提出正確功能的能力是不同的事。
此次發布修正了一條遭拒絕的工具呼叫仍會執行的路徑。它亦修正了即使停用記錄功能，聊天記錄仍持續寫入的問題。這些是已有記錄的修正，而非完整安全或私隱審計的證據。
另一項修正讓嵌入操作在模型傳回錯誤數量結果時拒絕整個批次。此前，這種不匹配有可能導致資料列遺失，或向量與識別碼之間出現錯誤關聯。
其分析意義在於失敗的處理方式。明確的錯誤讓應用程式有機會停止、重試或要求人員注意。表面上成功但關聯錯誤的操作，可能更難察覺。
對知識應用程式而言，來源身分是根本。一個附於錯誤文件、看似合理的結果，會削弱讀者核實它的能力。再好的語言生成，也無法在事後修復這種關聯。
同樣原則亦適用於中斷的工作。工作流程應區分已完成與僅嘗試的步驟，以及已記錄與遺失的結果。否則，下一個程序便會承接一份不清楚的事件紀錄。
這些是一般工程要求，並非 LLM 獨有的缺點。它們出現在發布內容中，顯示整合函式庫隨着使用方式變得更多樣化時，需要在哪些方面維護。
Willison 對 AI 輔助貢獻的說法帶來另一個角度。他表示，修正來自 12 名作者，幾乎全部使用 AI 協助。他報告指出，審閱這些貢獻的負擔比他預期中較低。
他的解釋強調分類篩選，即整理報告並決定哪些值得關注的過程。他使用 AI 協助找出有用的修正，亦有時會自行編寫實作，而非接納已提交的修補程式。
這段說法支持一項具體觀察：在他的審閱流程中，AI 輔助提交可以提供有用素材。它並不能證明其他維護者面對相同工作量，或收到同樣有用的貢獻。
公告沒有提供審閱時間、回歸率或維護成果的受控比較。審慎的解讀應保留這項限制，同時承認此次發布所包含的具體修正。
對貢獻者而言，含意很實際。即使建議的程式碼在審閱期間大幅改變，清晰的重現步驟和界定明確的失敗情況仍然很有價值。
對使用者而言，含意回到工作流程的擁有權。信任應建基於可觀察的行為，以及與任務相符的檢查。單憑修補程式的來源，無法證明應用程式是否應依賴它。
llm 0.37 之後值得留意的事項
有用的後續訊號關乎相容性、檢索品質和維護成果，而非新可用模型的數量。
在未來數月，首個訊號是端點管理如何在開發人員實際使用的服務中維持運作。具體報告應說明操作、預期行為和觀察到的結果。
基本文字生成只是起點。應用程式還會遇上不支援的選項、驗證失敗、中斷回應，以及對話處理的差異。針對這些情況的文件和修正，將提升共用介面的實際價值。
相反的訊號，會是對哪些組合獲支援持續出現模糊之處。若使用者必須反覆重新發現同樣的限制，較簡單的註冊方式仍會留下大部分整合負擔未獲解決。
這並不代表每個後端都需要相同功能。清晰界線本身已有價值。已記錄的限制可讓開發人員在圍繞假設建立依賴關係之前，選擇合適途徑。
第二個訊號，是嵌入整合對帶有類型附件的有效採用。支援聲明固然重要，但可運作的例子應展示所得搜尋行為如何把使用者連結至可供檢視的來源。
具說服力的例子會定義一個資料集、解釋其查詢任務，並顯示相關素材在哪裏出現。它亦應包括相關內容與正確證據互相競爭的困難個案。
這些證據將強化以下論點：更豐富的附件處理，為應用程式帶來的好處不止於接受額外檔案類型。即使模型傳回看似合理的數值結果，若反覆無法保留來源脈絡，這個論點便會被削弱。
開發人員亦應區分模型示範與應用程式評估。前者顯示某項能力存在；後者顯示該能力能否協助特定讀者完成任務。
第三個訊號，是 AI 輔助維護的持久性。Willison 的經驗在他所描述的限制內令人鼓舞。下一項有用證據關乎獲接納的改動，能否在後續開發中持續保持可理解和可靠。
後續修正並不自動是負面訊號。軟件維護包括發現及修正錯誤。更值得探究的問題是，報告是否可重現、失敗是否獲得清晰解釋，以及修正是否減少反覆出現的不確定性。
這個觀點避免把貢獻數量當作專案健康的完整指標。更多已提交的程式碼，本身不代表維護者有更多可用能力。價值在於問題被理解，以及行為獲改善。
對正考慮這次發布的讀者而言，即時決定應與其影響相稱。在把整個更新視為重新設計既有任務的理由之前，先找出哪項改動與既有任務相關。
個別嘗試模型的人，可能最重視設定的便利性。運行定期工作的團隊，可能更在意明確選擇和可靠紀錄。搜尋開發人員則可能聚焦媒體處理及來源保留。
把 llm 0.37 視為檢視你已了解的工作流程的理由。選擇具代表性的輸入、記錄預定模型，並界定可接受結果必須包含甚麼。擴大它們的角色之前，先按該標準比較候選輸出。對搜尋而言，應檢視檢索到的來源，而非只依賴生成的答案。對自動化行動而言，應檢視拒絕和中斷如何影響下一步。讓評估貼近使用結果的人，因為他們的要求決定了更容易切換是否帶來有用的彈性。你工作流程的哪一部分受惠於更多選擇，而哪一部分需要更明確的依賴關係？
