開源到底是否適用於人工智慧?
我們需要做一些事情來談論開源和開放性。至少從2006年開始,筆者就清楚地知道——筆者因為認為谷歌和雅虎阻礙開源而與很多人有了爭吵。正如Tim O'Reilly當時寫道的那樣,在一個開源的雲時代,“為了讓別人執行你的程式,分享原始碼副本的必要性的動機之一不復存在了。不僅不再需要它,對於最大的應用程式來說,這不再可能。”
在過去的十年裡,共享的不可能性攪亂了開源的定義,正如Mike Loukides最近指出的那樣,它現在正在影響我們對人工智慧(AI)的思考方式。在人工智慧領域進行合作,從來沒有比這更重要的時刻,但也從來沒有比這更困難的時刻。正如Loukides所描述的,“由於其規模,大型語言模型在再現性方面存在重大問題。”
正如2006年的雲技術一樣,在人工智慧領域做最有趣工作的公司可能會努力以我們傳統預期的方式“開源”。即便如此,這並不意味著它們不能以有意義的方式開放。
根據Loukides的說法,雖然許多公司可能聲稱參與了人工智慧,但實際上只有三家公司推動了該行業的發展:Facebook、OpenAI和谷歌。他們有什麼共同點?大規模執行模型的能力。換句話說,他們正在以一種你我都做不到的方式做人工智慧。他們不是在試圖保密;他們只是擁有基礎設施和如何執行基礎設施的知識,而你我都沒有。
“你可以下載Facebook的OPT-175B的原始碼,”Loukides承認,“但你無法在任何你可以訪問的硬體上對其進行訓練。即使對於大學和其他研究機構來說,它也太大了。你仍然必須相信Facebook的話,它做它所說的事情。”,儘管Facebook宣佈“共享開放式預訓練Transformer(OPT-175B)……讓更多社群參與瞭解這項基礎性新技術。”
這聽起來不錯,但正如Loukides堅持的那樣,“即使谷歌和OpenAI擁有足夠的計算資源,也可能無法複製OPT-175B。”為什麼?“OPT-175B與Facebook的基礎設施(包括定製硬體)聯絡太緊密,無法在谷歌的基礎設施上覆制。儘管Facebook並沒有試圖隱藏它對OPT-175B的使用。建造這樣的基礎設施真的很難,即使是那個些有資金和技術的人最終也會建造一些不同的東西。
這正是雅虎的Jeremy Zawodny和谷歌的Chris DiBona於2006年在OSCON上所體現的。當然,他們可以開放所有程式碼的原始碼,但考慮到它是以一種在其他任何地方都無法複製的方式大規模執行的,別人能用它做什麼呢?
回到人工智慧。如果我們不瞭解機器內部的科學,就很難相信人工智慧。我們需要找到開放基礎設施的方法。Loukides有一個想法,儘管它可能無法滿足最狂熱的自由軟體/人工智慧人士:“答案是向外部研究人員和早期採用者提供免費訪問許可權,以便他們可以提出自己的問題,並檢視廣泛的結果。”不,不是讓他們透過鑰匙卡訪問Facebook、谷歌或OpenAI的資料中心,而是透過公共API。這是一個有趣的想法,可能會奏效。
但它並不像許多人所希望的那樣“開源”。
另一個角度看開放
自2006年以來,谷歌在滿足其戰略需求的情況下對關鍵基礎設施進行了打包和開源。TensorFlow開源可以稱為入站,Kubernetes的開源可以稱為出站,要麼是機器學習的開源行業標準,有望帶來更多谷歌雲工作負載,要麼是確保雲之間的可移植性,給谷歌雲更多贏得工作負載的機會。這是一種智慧業務,但在某種程度上,它不是開源的。
在這方面,谷歌也並非孤軍奮戰。它只是比大多數公司更擅長開源。因為開源天生自私,公司和個人總是會開啟有利於他們或他們自己的客戶的程式碼。一直都是這樣,而且永遠都是這樣。
對於Loukides關於如何有意義地開放人工智慧的觀點,儘管三大人工智慧巨頭與其他所有人之間存在差異,但他並沒有像我們傳統上在開源定義下那樣主張開源。為什麼?因為儘管它很神奇(事實上也是如此),但它從來沒有解決過DiBona和Zawodny在2006年OSCON提出的軟體開發者和消費者的雲開源難題。已經過去十多年的時間了,但我們還沒有找到答案。
筆者認為我們需要一種新的思考開源許可的方式,筆者的想法可能與Loukides思考人工智慧的方式沒有太大的不同。我理解他的論點,關鍵是為研究人員提供足夠的途徑,使他們能夠重現特定人工智慧模型工作的成功和失敗。他們不需要完全訪問所有程式碼和基礎設施來執行這些模型,因為正如他所說的那樣,這樣做基本上是沒有意義的。在一個開發者可以在膝上型電腦上執行開源程式並進行衍生工作的世界裡,要求完全訪問該程式碼是有道理的。考慮到谷歌或微軟今天執行的程式碼的規模和獨特的複雜性,這已經沒有意義了。無論如何,並不是所有大規模執行的雲程式碼。
我們需要拋棄開源的非黑即白觀點。它從來不是一個特別有用的視角來看待開源世界,考慮到我們的雲時代,它正變得越來越不那麼有用。作為公司和個人,我們的目標應該是以有利於我們的客戶和第三方開發者的方式開放對軟體的訪問,以促進訪問和理解,而不是試圖將幾十年前的開源概念改造為雲。它不適用於開源,就像它不適用於人工智慧一樣。是時候換個角度思考了。
來自 “ 開源雲中文社群 ”, 原文作者:開源雲中文社群;原文連結:https://mp.weixin.qq.com/s/axiaOk4ky4HhB8yRqepUYw,如有侵權,請聯絡管理員刪除。
相關文章
- 是否有用於建立簡單CRUD應用的開源工具? - ycombinator開源工具
- 適用於人工智慧開發的程式語言,主要有哪些?人工智慧
- 開源LIMS系統miso LIMS(適用於NGS基因測序)
- 開源AwaitableCompletionSource,用於取代TaskCompletionSourceAI
- Spark適用於哪些場景?不適用於哪些場景?Spark
- 實體店是否屬於數字化智慧經營的適用範圍?
- 你是否真的適合搞NDK開發?
- 低程式碼適用於哪些應用開發場景
- 在選擇開源時需要基於自身需求選擇合適的開源協議協議
- 適用於iOS的AnyTransiOS
- 基於大模型的人工智慧應用開發大模型人工智慧
- 協作機器人是否適合您的應用?機器人
- 如何分辨問題是否適用魚骨圖來分析?
- 6 個用於寫書的開源工具開源工具
- 開源到底是不是商業模式模式
- 微軟適用於 Visual Studio 的 Edge 開發者工具微軟
- PbootCMS授權碼是否可以用於不同埠? 授權碼是否可以用於 HTTPS 環境?bootHTTP
- 人工智慧是否適合使用?將來我們能代替體力勞動嗎?人工智慧
- python到底適不適合大型專案呢?Python
- 3 款用於學術出版的開源工具開源工具
- PHP的確不適合做 人工智慧 開發!PHP人工智慧
- 6種適用於開發人員的Linux發行版本!Linux
- 適用於 PHP 開發人員的 Python 基礎知識PHPPython
- 自定義表單系統開源是否好用?
- Apache Kafka不適用於Event Sourcing!ApacheKafka
- 人工智慧應用於智慧社群人工智慧
- AAAI 2020 開源論文 | 用於深度立體匹配的自適應單峰匹配代價體濾波AI
- 開發一個適用於 nodejs 與瀏覽器的 npm 包 - 基於 rollupjsNodeJS瀏覽器NPM
- Oracle Advance Queuing是否適合您?OracleUI
- 用於聯絡人管理的三個開源工具開源工具
- Swift For TensorFlow終於開源,但先別急著用Swift
- 擁抱開源,浪潮將OpenStack之路踐行到底!
- 適用於 Go 專案的 Makefile 指南Go
- [譯] 介紹適用於 iOS 的 AloeStackViewiOSView
- 適用於小程式的 ES6
- title並不只適用於連結元素
- 人工智慧到底能否取代人類?人工智慧
- TriggerMesh開源用於多雲環境的Knative Event Sources