北京
“將向量搜索視為規(guī)模化已解決的基礎(chǔ)設(shè)施問題，是一個危險的錯誤。”任何用5分鐘教程搭完RAG（檢索增強(qiáng)生成）原型的團(tuán)隊，把應(yīng)用丟進(jìn)真實的B2B SaaS生產(chǎn)環(huán)境時，很快就會被這句話打臉。本地跑通的demo到了企業(yè)場景，面對的就不再是整潔的靜態(tài)文件，而是動態(tài)涌入的實時數(shù)據(jù)流，還綁著嚴(yán)格的法律與合規(guī)約束。
把文檔切片、調(diào)嵌入API、扔進(jìn)向量庫再套個界面——這套流水線在測試?yán)锘蛟S能過，但一遇生產(chǎn)流量，架構(gòu)馬上塌方。第一個也是最普遍的瓶頸，就出在同步攝取上。用戶上傳一份500頁的合規(guī)手冊，客戶端發(fā)出POST請求，服務(wù)端開始解析文檔、切分文本，然后一個接一個地同步調(diào)用OpenAI或Cohere的嵌入接口，等向量算完再寫入數(shù)據(jù)庫。
這條路會引爆兩種致命故障：一是超時，500頁的文檔幾乎沒有可能在標(biāo)準(zhǔn)的30到60秒HTTP超時窗口內(nèi)處理完全部嵌入調(diào)用；二是級聯(lián)失敗，一旦碰上速率限制或延遲尖峰，整個攝取操作直接拋500錯誤，用戶上傳的文檔就消失了。
生產(chǎn)級的AI管線必須用持久化事件替代單純的HTTP調(diào)用。但直接把整份500頁的文檔丟給Kafka或RabbitMQ里的單個消費(fèi)者去處理，又是另一個坑——這個消費(fèi)者可能連續(xù)10分鐘都在生成嵌入，心跳被卡死。消息代理認(rèn)定該工作節(jié)點(diǎn)已死，隨即殺掉消費(fèi)者并觸發(fā)分區(qū)重平衡，造成的就是重復(fù)勞動與停擺的無限循環(huán)。
反過來，把每個切塊都變成一條獨(dú)立的消息，等于是對自己發(fā)動分布式拒絕服務(wù)攻擊。一份分割出1500個塊的文檔，就會產(chǎn)生1500條消息，瞬間沖破上游每分鐘請求數(shù)的限制，讓管線淹沒在網(wǎng)絡(luò)開銷里。
真正的工程甜點(diǎn)，是一套批處理扇出方案：Web API將原始文件直接存在Amazon S3上，觸發(fā)一條document_uploaded事件，并立即返回202 Accepted狀態(tài)。這條單一的異步路徑，對處理一頁的發(fā)票和處理上百頁的SOC2報告同樣可靠，從根本上消除了同步攝取帶來的技術(shù)債務(wù)。
特別聲明：以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布，本平臺僅提供信息存儲服務(wù)。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
