Ahmad Al-Dahle 在今年一月加入 Airbnb 擔任技術長之前，曾是 Meta 生成式 AI 部門主管，並在 2023-2025 年間主導了其開源 Llama 模型的發布。現在，Al-Dahle 的任務是將 Airbnb 轉變為一家「AI 原生公司」。

實際上，這意味著在內部運用 AI 來加速產品開發，然後再利用這些相同的能力來轉變客戶體驗。我們將這種方法稱為「由內而外（inside-out）的 AI 策略」，本文將深入探討其細節。

Al-Dahle 向 Latent Space 談論了 Airbnb 的 AI 轉型。我們首先問他，為何從 Meta 建立尖端模型轉變為在 Airbnb 部署這些模型。他回答說：「基本上，我喜歡追逐我認為真正的難題所在。」

他補充道：「我們在 Meta 已經知道飛輪效應的運作方式，也了解如何一代又一代地改進模型能力。」Al-Dahle 認為，下一個挑戰是如何大規模部署模型。

在 Airbnb，他的目標是「推動人們以不同的方式工作，因為這些工具正在改變你的工作方式」，並「將這些系統部署到生產環境中，以創新的方式為核心使用者體驗增添價值」。

自 2008 年成立以來，Airbnb 一直被視為一家在飯店業經營的科技公司。該公司於 2020 年上市，目前市值約為 930 億美元（撰寫本文時）。因此，要使其成為「AI 原生」是一項龐大的工程。

Al-Dahle 列舉了一些數據，顯示 Airbnb 現在已全面擁抱 AI：其 60% 的程式碼現在由 AI 編寫，每年發布的功能和改進增加了近 80%，而工程師平均的 pull-request 吞吐量也提高了約 1.6 倍。

但 Airbnb 究竟是如何做到這一切的呢？首先，他說這關乎改變軟體工程的組織流程。傳統上，你可能會先進行產品需求分析，然後在 Figma 中進行設計工作，接著是工程實作，最後是生產測試。

過去，這些步驟需要不同團隊之間的交接。但現在，Airbnb 的產品、設計和工程團隊直接轉向使用原型進行工作。Al-Dahle 表示：「縮短這個時間實際上是許多傳統軟體公司必須跨越的最大障礙之一。」

他補充說：「所以我們跨越了這個障礙，它實際上為我們的產品開發流程帶來了巨大的推動力。」這種改變的一個附帶結果是，團隊直接處理程式碼，而不是處理像產品需求文件這樣的「產物」。

他說：「我們擺脫了過度生成產物的做法，轉而將程式碼和原型作為我們推理的依據。」Al-Dahle 告訴我們，客戶支援是他們首次引入 AI 的使用者面向領域。

他將其描述為「最難部署的問題」，因為「錯誤的風險和後果非常高」。Al-Dahle 表示，目前 Airbnb 大約一半的支援工單純粹由 AI 解決（這與該公司第二季財報的數據一致，當時的數字接近 45%）。

他補充說，關鍵在於使用合成資料在投入生產之前徹底測試系統。他解釋：「我們從建立模型、建立代理開始，然後在投入生產之前生成一系列合成資料進行測試。」

他指出，儘管代理處理了大約一半的客戶支援查詢，但他們對於哪些問題需要人工協助非常謹慎，例如安全問題。他表示：「因此，雖然我們解決了 50% 的工單，但我們實際上對於那些尚未選擇讓代理解決的工單是經過深思熟慮的。」

兩個你可能還不熟悉的 Airbnb Services 專案是雜貨配送和機場接送（雜貨服務最近已擴展到更多城市）。這兩項服務都在今年稍早推出，部分歸功於 Airbnb 的「由內而外」AI 策略。

一個名為 Everest 的內部組織情境圖（organizational context graph）幫助這些產品快速上市。Al-Dahle 表示，Everest 使用 LLM、嵌入（embeddings）和基於 AI 的檢索等技術來建立和查詢此圖。

他解釋說，雜貨配送和機場接送服務「有點類似，都是與合作夥伴服務（外部公司）的 API 整合，這些服務整合到我們的平台上」。雜貨服務首先建立，從中學到的經驗被整合到 Everest 中。

這使得機場接送團隊能夠更快地完成他們的專案。Airbnb 在其第二季財報中指出：「雜貨服務花了八到九個月，而機場接送服務大約只花了六週就開發完成。」

此外，使用 Everest 意味著開發人員不一定需要專業知識來處理專案。Al-Dahle 說：「由於這個存在於整個程式碼庫中的情境圖，我們能夠讓通才在非常專業的程式碼部分工作。」

這兩項新服務都在執行長 Brian Chesky 於五月舉行的 Airbnb 2026 夏季發布會上被重點介紹。

為了更深入了解 Airbnb 內部 AI 的使用情況，Al-Dahle 將其描述為一家「多模型公司」，並表示他們在生產系統中部署了「許多不同的模型」。

Airbnb 混合使用尖端模型和開源模型，但大部分的後訓練和強化學習都是在開源模型上進行的。Al-Dahle 表示，該公司為生產用例部署了至少 10 個客製化模型。

他們還根據成本、效能和延遲，沿著帕累托前緣（Pareto frontier）評估模型，為每個應用程式選擇不同的權衡。他解釋：「我們針對每個用例進行特定的評估。」

他補充說：「因此，如果我們將模型用於搜尋，我們會有一組從生產環境中採樣的搜尋查詢來進行衡量。如果我們在做客戶支援，我們也會採樣所有我們最關心的生產查詢，包括邊緣案例。」

他補充道：「我們嘗試為正確的工作選擇正確的工具。」例如，程式碼編寫可以容忍較高的延遲，但錯誤的代價很高。因此，他們傾向於為程式碼編寫任務使用最強大的尖端模型。

「使用最尖端的程式碼模型是有道理的，因為模型產生的每一個缺陷都可能輕易地讓我們付出更高的代價。」另一方面，搜尋被 Airbnb 的用戶大規模使用，因此對延遲非常敏感。

因此，對於這項工作，他們更喜歡較小的專業模型。Al-Dahle 聲稱，較小、經過後訓練的模型有時甚至優於尖端模型。他表示：「對於狹窄的用例，我們能夠採用非常小、非常靈活、快速且便宜的模型，並將其後訓練到超越尖端模型的程度。」

像其他 AI 原生公司一樣，Airbnb 也創建了一個內部代理，在他們的情況下稱為 AirChat。Al-Dahle 說：「我們有自己的內部代理，我們稱之為 AirChat，它基本上包含了所有必要的 MCP 組織情境。」

但 Airbnb 也開始實施 Al-Dahle 認為是代理的下一個發展方向：在容器中運行並由事件觸發的非同步代理。他解釋說：「我們的許多團隊都開始自動化他們的隨叫隨到（on-calls）任務。」

他補充說：「因此，如果發生了什麼事，如果 Grafana 的限制或你使用的任何監控系統觸發了警報，代理就會啟動，然後進行分類並執行你的隨叫隨到，即你的初步隨叫隨到。」

人工工程師可以審查代理提出的 pull-request，而如果代理判斷警報是誤報，它可能會自行關閉事件。這個過程讓我們想起 Vercel 的 AI SDK、Astro、Flue 和 tldraw 等開源專案如何使用軟體工廠（即代理團隊）來應用修復和功能。

Al-Dahle 認為這種方法最終將應用於其整個市場平台；例如監控詐欺、「信任違規」、市場品質和軟體缺陷。他表示：「我的願景是大量非同步代理協助自動化和管理市場。」

Al-Dahle 相信，圍繞成果而非功能來組織團隊是成為 AI 原生公司的關鍵。他說：「如果你是一家以功能開發來組織的公司，你將在 AI 時代舉步維艱。」

他補充說：「如果你是一家以目標、使命和你試圖實現的成果來組織的公司，你就會沒事。」儘管如此，Al-Dahle 在這次 AI 原生轉型中仍有一個擔憂：年輕工程師是否能發展他們的手藝和判斷力，因為現在 AI 能夠為他們完成如此多的工作。

他補充說，資深工程師的判斷力是透過多年來發布系統和在生產環境中操作軟體，包括他們一路走來的錯誤，所累積的。

Al-Dahle 說，解決方案的一部分是確保所有工程師都能解釋 AI 為他們完成的工作。他表示：「我非常強烈地推動的一點是，即使是 AI 生成的 pull-request，每位工程師都必須能夠解釋他們所建立的內容。」

他總結道：「我認為，如果這個基本前提保持不變，那麼較年輕的工程師將學習介面設計和架構的技巧，以及測試、單元測試和整合測試的重要性。所以我們正在努力保持我們工藝的高水準。」