How Web Data Infrastructure Powers the Next Generation of AI — Patricija Žemaitytė, Oxylabs

Oxelapse 是一個成立於 2015 年的網頁情報平台和代理服務提供商。演講者 Patricia 從技術團隊成長到產品經理，通過三個大規模項目的故事，闡述了 AI 時代基礎設施的本質。

第一個故事發生於銷售團隊從舊金山帶回的緊急需求：2 週內建立視頻 API，處理每月 5 PB 數據。這不只是下載功能，而是完整的管道系統——包括收集、傳輸、儲存、交付，需要達到 AI 訓練工作負載的可靠性標準。初版在截止日期前完成，但客戶的真實需求遠超預期。客戶先要求字幕而非轉錄，再要求特定語言的搜尋能力，然後要求元數據和頻道信息。每次迭代都打破初始的功能邊界，最終在三個月內演變成完整的視頻 API 套件。這個過程教會 Patricia 最重要的教訓：創新不是預設的路線圖，而是在高壓截止日期下持續適應客戶的實際需求。

第二個故事聚焦於搜尋引擎結果頁（SERP）數據在 AI 系統中的角色轉變。傳統上 SERP 用於分析和市場情報，但 AI 時代它成為實時檢索管道、助手系統和智能體與外部信息互動的核心。Google 的官方文檔明確指出搜尋是連接模型與實時公開知識的方式。2024 年客戶要求次秒級 SERP 交付，而既有爬蟲延遲為 4 秒。當時市場尚未準備好，需求被擱置。2025 年新客戶要求零數據保留、800 毫秒以內延遲、2 週內完成。從 4 秒到 800 毫秒不是優化，是完全重設計。首版在 2 週內達到 650 毫秒 P90，但正式測試時系統因檢測機制受阻。第二次迭代被迫依賴瀏覽器，這是個矛盾——客戶要次秒級，瀏覽器卻要 4 秒。解決方案是逐項獵取時間：優化佈局、解析器、會話、代理，每處削減幾百毫秒。最終達成 550 毫秒平均延遲，同時日請求量從 4 億增長到 60 億。這個轉變意味著速度本身變成了產品特性——4 秒只能做慢管道，次秒級才能直接集成到 AI 工作流中。

第三個故事講述可視化阻止器從 10,000 req/s 到 60,000 req/s 的擴展（2 個月內），現已升級至 100,000 req/s。這不是簡單的 HTTP 計數，而是端到端爬蟲作業——路由、渲染、代理、瀏覽器執行、解析、重試、規範化、交付。增加 2,000 台伺服器不足以解決問題，需要架構、可靠的中心組件和能反映現實的測試。最大瓶頸出現在負載測試中。生成合成流量容易，但有機數據測試（模擬真實客戶行為）困難。測試在 20,000 req/s 時碰到不確定性瓶頸。傳統觀測在超大規模下變成真實工作——收集日誌難，處理日誌更難，遙測本身成為負載的一部分。最終接受真相：生產流量測試是最佳測試，幸運的是一切順利，但基礎設施需求持續升級。

這些故事的共通點是：基礎設施的本質不是「構建一次」，而是「永遠適應」。目標數字會變、檢測機制會演變、市場需求會轉變。最有用的創新定義就是：足夠快地保持適應，使得變化的需求本身成為新基礎設施。