1. 這不是在聊“護(hù)城河”的比喻而是在拆解AI系統(tǒng)里真正扛壓的底層結(jié)構(gòu)很多人一聽(tīng)到“護(hù)城河”第一反應(yīng)是模型參數(shù)量、私有數(shù)據(jù)量、微調(diào)能力——這些確實(shí)重要但它們更像是城墻上飄的旗子風(fēng)一吹就晃。真正決定一個(gè)AI應(yīng)用能不能活過(guò)三個(gè)月、能不能撐住每天十萬(wàn)次并發(fā)、能不能讓銷售總監(jiān)敢把客戶合同直接扔進(jìn)去問(wèn)“這單能不能接”靠的從來(lái)不是L7應(yīng)用層那點(diǎn)花哨的界面交互或提示詞工程。我?guī)F(tuán)隊(duì)做過(guò)17個(gè)落地RAG項(xiàng)目從律所合同審查系統(tǒng)到制造業(yè)設(shè)備維修知識(shí)庫(kù)踩過(guò)最深的坑90%都出在L3網(wǎng)絡(luò)層和L4傳輸層沒(méi)搭穩(wěn)。比如某醫(yī)療客戶上線第三天就崩排查三天才發(fā)現(xiàn)是L4層TCP連接復(fù)用策略沒(méi)調(diào)導(dǎo)致知識(shí)檢索請(qǐng)求在高并發(fā)下大量超時(shí)還有個(gè)金融客戶的知識(shí)庫(kù)明明文檔切片質(zhì)量很高但用戶反饋“總卡在加載”最后發(fā)現(xiàn)是L3層DNS解析緩存時(shí)間設(shè)成了24小時(shí)CDN節(jié)點(diǎn)切換后舊IP還在被反復(fù)嘗試。L7層再漂亮的向量檢索界面擋不住一次DNS抖動(dòng)再精巧的RAG重排邏輯救不回一個(gè)沒(méi)開(kāi)keep-alive的HTTP連接。所謂“真正的護(hù)城河”就是當(dāng)別人還在調(diào)embedding模型溫度系數(shù)時(shí)你已經(jīng)把TCP TIME_WAIT回收周期、TLS握手耗時(shí)、DNS預(yù)解析策略、HTTP/2流控窗口這些“看不見(jiàn)的管道”全擰緊了。它不炫技但決定了你的RAG系統(tǒng)是能跑還是能穩(wěn)跑、快跑、扛著流量洪峰跑。2. L3L4不是“基礎(chǔ)設(shè)施”而是RAG知識(shí)流轉(zhuǎn)的生命線2.1 為什么RAG對(duì)L3/L4異常敏感——從一次文檔解析失敗說(shuō)起去年幫一家汽車零部件廠做售后知識(shí)庫(kù)他們提供了一份PDF手冊(cè)共287頁(yè)含大量CAD圖紙嵌入和表格。我們用主流OCRLayout Parser方案處理本地測(cè)試完美。但上線后用戶上傳同份PDF系統(tǒng)返回“解析超時(shí)”。日志只顯示“timeout”沒(méi)報(bào)錯(cuò)。常規(guī)思路會(huì)去查OCR模型性能、GPU顯存、Python進(jìn)程內(nèi)存——我們?nèi)榱硕紱](méi)問(wèn)題。最后抓包發(fā)現(xiàn)客戶端上傳時(shí)HTTP POST body大小約12MB而Nginx默認(rèn)client_max_body_size是1MB。L7層根本沒(méi)收到完整請(qǐng)求L4層TCP連接在傳輸中途就被resetL3層IP包還沒(méi)到應(yīng)用服務(wù)器就丟了。這不是模型問(wèn)題是L3/L4的“門禁”太窄。RAG場(chǎng)景天然放大L3/L4脆弱性大體積輸入PDF/PPT/掃描件常達(dá)5–50MB遠(yuǎn)超Web表單常規(guī)尺寸高頻小請(qǐng)求一次用戶提問(wèn)觸發(fā)3–5次向量檢索2次重排1次LLM生成每秒數(shù)十次HTTP請(qǐng)求長(zhǎng)鏈路依賴用戶→CDN→負(fù)載均衡→API網(wǎng)關(guān)→RAG服務(wù)→向量庫(kù)→LLM服務(wù)→結(jié)果返回任意一環(huán)L3/L4配置不當(dāng)整條鏈就斷。L3網(wǎng)絡(luò)層管的是“怎么找到對(duì)方”核心是IP路由、DNS解析、MTU路徑發(fā)現(xiàn)L4傳輸層管的是“怎么可靠傳過(guò)去”核心是TCP連接管理、端口復(fù)用、擁塞控制、TLS握手效率。RAG不是單體應(yīng)用它是多個(gè)服務(wù)協(xié)同的“知識(shí)流水線”L3/L4就是這條流水線的傳送帶和供電系統(tǒng)。傳送帶松了DNS緩存過(guò)長(zhǎng)零件請(qǐng)求就掉地上供電不穩(wěn)TCP連接池不足機(jī)器服務(wù)就頻繁重啟。2.2 L3層關(guān)鍵配置DNS、路由與MTU三者如何聯(lián)動(dòng)影響RAG響應(yīng)DNS看似簡(jiǎn)單卻是RAG穩(wěn)定性的第一道閘門。我們?cè)龅揭粋€(gè)典型故障某省政務(wù)知識(shí)庫(kù)白天正常凌晨批量更新知識(shí)后連續(xù)兩小時(shí)響應(yīng)延遲飆升。排查發(fā)現(xiàn)其向量庫(kù)域名解析TTL設(shè)為86400秒24小時(shí)而向量庫(kù)集群在凌晨做了滾動(dòng)升級(jí)新節(jié)點(diǎn)IP已變但舊DNS記錄還在各層級(jí)緩存中?？蛻舳顺掷m(xù)向已下線的IP發(fā)請(qǐng)求直到TTL過(guò)期才刷新。解決方案不是改TTL為60秒太短增加DNS壓力而是采用DNS預(yù)解析健康檢查雙機(jī)制在RAG服務(wù)啟動(dòng)時(shí)主動(dòng)調(diào)用getaddrinfo()預(yù)熱DNS緩存每5分鐘對(duì)向量庫(kù)IP發(fā)起輕量級(jí)HTTP HEAD探針若連續(xù)3次失敗則強(qiáng)制刷新該域名解析。路由層面關(guān)鍵是避免跨AZ可用區(qū)流量繞行。某電商客戶將RAG服務(wù)部署在華東1區(qū)向量庫(kù)在華東2區(qū)兩地間通過(guò)公網(wǎng)互通。實(shí)測(cè)單次向量檢索P95延遲達(dá)1200ms。改為同AZ內(nèi)部VPC直連后降至85ms。這不是模型優(yōu)化是L3路由策略調(diào)整。更隱蔽的是MTU最大傳輸單元問(wèn)題。當(dāng)RAG請(qǐng)求經(jīng)過(guò)多層NAT如企業(yè)防火墻云廠商SLB容器網(wǎng)絡(luò)若路徑MTU小于1500字節(jié)大包會(huì)被分片。而某些老舊防火墻不支持IP分片重組導(dǎo)致請(qǐng)求丟包。我們的標(biāo)準(zhǔn)做法是在RAG服務(wù)Pod內(nèi)執(zhí)行ping -s 1472 -M do 向量庫(kù)IP1472281500逐步減小-s值直到不丟包確定路徑最小MTU然后在服務(wù)端TCP socket設(shè)置TCP_MAXSEG為此值并通知前端壓縮上傳文件至該MTU限制內(nèi)。2.3 L4層生死線TCP連接池、TLS優(yōu)化與HTTP/2流控L4層直接決定RAG的吞吐天花板。我們對(duì)比過(guò)三種連接模式在1000QPS壓力下的表現(xiàn)連接模式平均延遲連接建立耗時(shí)占比內(nèi)存占用每次新建TCPTLS420ms68%低長(zhǎng)連接keep-alive180ms12%中HTTP/2多路復(fù)用95ms3%高結(jié)論清晰RAG必須用HTTP/2。但HTTP/2不是開(kāi)個(gè)開(kāi)關(guān)就行。關(guān)鍵參數(shù)有三個(gè)SETTINGS_INITIAL_WINDOW_SIZE默認(rèn)65535字節(jié)對(duì)RAG小響應(yīng)如向量ID列表足夠但對(duì)大響應(yīng)如帶圖表的PDF解析結(jié)果易觸發(fā)流控阻塞。我們?cè)O(shè)為262144256KBMAX_CONCURRENT_STREAMS默認(rèn)100但RAG常需并行查向量庫(kù)查圖譜查規(guī)則庫(kù)。我們?cè)O(shè)為500TLS 1.3優(yōu)先級(jí)必須關(guān)閉TLS 1.2回退因1.2握手需2-RTT1.3僅1-RTT。Nginx配置中明確ssl_protocols TLSv1.3; ssl_prefer_server_ciphers off;。TCP連接池更需精細(xì)調(diào)控。以Python FastAPI服務(wù)為例若用httpx.AsyncClient訪問(wèn)向量庫(kù)limitsLimits(max_connections100, max_keepalive_connections20)是常見(jiàn)配置。但這是靜態(tài)值。真實(shí)場(chǎng)景中我們動(dòng)態(tài)調(diào)整監(jiān)控向量庫(kù)P95延遲若200ms且連接池滿則自動(dòng)擴(kuò)容max_connections至150若延遲50ms且空閑連接80%則縮容至80。這套邏輯封裝成獨(dú)立中間件比硬編碼參數(shù)可靠十倍。3. L7只是“臉”L3/L4才是“骨架”RAG系統(tǒng)架構(gòu)中的分層責(zé)任歸屬3.1 四層責(zé)任地圖誰(shuí)該為哪類故障負(fù)責(zé)很多團(tuán)隊(duì)故障歸因混亂導(dǎo)致修復(fù)周期拉長(zhǎng)。我們按L3/L4/L7劃分明確責(zé)任邊界故障現(xiàn)象典型原因責(zé)任層責(zé)任人用戶上傳PDF卡在“正在處理”無(wú)日志Nginx client_max_body_size不足L3/L4運(yùn)維/Infra同一問(wèn)題多次提問(wèn)答案不一致RAG重排邏輯bug或緩存key設(shè)計(jì)錯(cuò)誤L7算法/研發(fā)高峰期所有請(qǐng)求超時(shí)504負(fù)載均衡器后端健康檢查失敗流量全打到1臺(tái)實(shí)例L3/L4運(yùn)維/Infra向量檢索結(jié)果相關(guān)性突降embedding模型版本誤更新或索引未重建L7算法/數(shù)據(jù)某些地區(qū)用戶訪問(wèn)極慢其他地區(qū)正常CDN節(jié)點(diǎn)未覆蓋該區(qū)域回源距離過(guò)長(zhǎng)L3運(yùn)維/Infra關(guān)鍵認(rèn)知L3/L4故障表現(xiàn)為“全量不可用”或“隨機(jī)超時(shí)”L7故障表現(xiàn)為“功能錯(cuò)亂”或“結(jié)果不準(zhǔn)”。前者是血管堵塞后者是大腦指令錯(cuò)誤。某教育客戶曾抱怨“RAG有時(shí)答對(duì)有時(shí)答錯(cuò)”團(tuán)隊(duì)花兩周調(diào)提示詞最后發(fā)現(xiàn)是L4層TCP重傳率過(guò)高因云廠商虛擬交換機(jī)隊(duì)列積壓導(dǎo)致部分檢索請(qǐng)求數(shù)據(jù)包丟失服務(wù)端收到殘缺請(qǐng)求后返回默認(rèn)答案。這種問(wèn)題絕不能甩鍋給算法。3.2 RAG知識(shí)庫(kù)的存儲(chǔ)真相圖片能存嗎結(jié)構(gòu)化知識(shí)怎么放熱搜詞里“RAG知識(shí)庫(kù)能存儲(chǔ)圖片嗎”暴露了普遍誤解。RAG知識(shí)庫(kù)本質(zhì)是向量索引元數(shù)據(jù)存儲(chǔ)不是文件倉(cāng)庫(kù)。圖片本身不存于RAG庫(kù)而是圖片經(jīng)CLIP等多模態(tài)模型提取特征向量存入向量庫(kù)如Milvus原圖URL或OSS路徑作為元數(shù)據(jù)metadata關(guān)聯(lián)存儲(chǔ)檢索時(shí)返回匹配向量的圖片URL前端再加載。所以“存圖片”實(shí)際是存圖片的“數(shù)學(xué)指紋”。這直接依賴L3/L4若OSS URL訪問(wèn)慢整個(gè)RAG體驗(yàn)就卡在最后一步。我們要求OSS Bucket必須與RAG服務(wù)同Region且開(kāi)啟HTTP/2TLS 1.3CDN緩存圖片Cache-Control: public, max-age31536000。至于“KG知識(shí)庫(kù) vs RAG知識(shí)庫(kù)”本質(zhì)是查詢范式差異KG知識(shí)圖譜回答“關(guān)系型問(wèn)題”“特斯拉Model Y的電池供應(yīng)商是誰(shuí)”→ 查三元組特斯拉-供應(yīng)-寧德時(shí)代RAG回答“語(yǔ)義型問(wèn)題”“對(duì)比Model Y和比亞迪海豹的冬季續(xù)航衰減原因”→ 檢索多篇技術(shù)文檔片段LLM綜合生成。兩者可融合KG提供精準(zhǔn)關(guān)系RAG提供上下文解釋。但融合點(diǎn)必須在L7以下——例如向量庫(kù)檢索返回結(jié)果后L4層服務(wù)調(diào)用KG API補(bǔ)充關(guān)系數(shù)據(jù)再統(tǒng)一返回給LLM。若KG API調(diào)用走公網(wǎng)L3延遲會(huì)拖垮整個(gè)RAG鏈路。因此我們強(qiáng)制要求KG服務(wù)與RAG服務(wù)部署在同一K8s集群用ClusterIP Service直連跳過(guò)所有L3網(wǎng)絡(luò)設(shè)備。3.3 Ontology RAG當(dāng)知識(shí)需要“骨架”L3/L4如何支撐結(jié)構(gòu)化理解Ontology RAG本體驅(qū)動(dòng)RAG是解決“rag瓶頸”的關(guān)鍵路徑。傳統(tǒng)RAG把文檔切塊扔進(jìn)向量庫(kù)像把書(shū)撕碎混進(jìn)攪拌機(jī)Ontology RAG先構(gòu)建知識(shí)骨架如“合同-條款-違約責(zé)任-賠償金額”再將文檔內(nèi)容映射到骨架節(jié)點(diǎn)上。這極大提升檢索精度但代價(jià)是L3/L4壓力倍增構(gòu)建本體需調(diào)用外部規(guī)則引擎如Drools每次映射要發(fā)起3–5次HTTP請(qǐng)求查詢時(shí)需并行遍歷本體樹(shù)的多個(gè)分支產(chǎn)生指數(shù)級(jí)HTTP連接需求。我們的應(yīng)對(duì)方案是L4層連接復(fù)用極致化為規(guī)則引擎客戶端單獨(dú)配置連接池max_connections200keepalive_expiry3005分鐘L3層服務(wù)發(fā)現(xiàn)優(yōu)化不用DNS改用K8s Endpoints直接尋址規(guī)避DNS解析延遲請(qǐng)求合并將同一文檔的多個(gè)本體節(jié)點(diǎn)映射請(qǐng)求在L7層SDK中聚合成單個(gè)POSTbody內(nèi)含數(shù)組服務(wù)端批量處理。實(shí)測(cè)顯示Ontology RAG在法律合同審查場(chǎng)景準(zhǔn)確率提升37%但若L3/L4沒(méi)調(diào)優(yōu)延遲反而增加2.1倍。護(hù)城河不在本體設(shè)計(jì)多精妙而在能否讓本體查詢像本地函數(shù)調(diào)用一樣快。4. 實(shí)操手冊(cè)Mac上搭建RAG知識(shí)庫(kù)時(shí)L3/L4的6個(gè)必調(diào)參數(shù)4.1 本地開(kāi)發(fā)環(huán)境的L3/L4陷阱Mac不是生產(chǎn)環(huán)境但錯(cuò)配會(huì)埋雷在Mac上用Docker Compose跑RAG如llama.cpp ChromaDB FastAPI很多人忽略Mac的網(wǎng)絡(luò)棧特性macOS默認(rèn)TCP keepalive時(shí)間是7200秒2小時(shí)而Linux是7200秒但可調(diào)云服務(wù)器常設(shè)為600秒macOS DNS resolver緩存行為與Linux不同/etc/resolver/*配置易被忽略Docker for Mac使用HyperKit虛擬機(jī)網(wǎng)絡(luò)路徑比Linux長(zhǎng)1跳MTU默認(rèn)1500但實(shí)際路徑MTU常為1450。不調(diào)這些本地跑得飛快一上生產(chǎn)就崩。以下是Mac開(kāi)發(fā)時(shí)必須修改的6個(gè)參數(shù)1. Docker網(wǎng)絡(luò)MTU校準(zhǔn)在~/.docker/daemon.json中添加{ mtu: 1450, default-address-pools: [ { base: 172.16.0.0/16, size: 24 } ] }重啟Docker后docker network inspect bridge | grep mtu確認(rèn)生效。否則ChromaDB容器間通信可能丟包。2. Python HTTP客戶端連接池FastAPI服務(wù)中用httpx.AsyncClient時(shí)# 錯(cuò)誤用默認(rèn)配置 client httpx.AsyncClient() # 正確顯式聲明L4參數(shù) client httpx.AsyncClient( limitshttpx.Limits( max_connections100, max_keepalive_connections50, keepalive_expiry60.0 # 60秒空閑即釋放 ), timeouthttpx.Timeout(30.0, read10.0) # 連接30秒讀取10秒 )keepalive_expiry60.0是關(guān)鍵Mac上長(zhǎng)連接易僵死短周期釋放更穩(wěn)。3. ChromaDB向量庫(kù)的L4調(diào)優(yōu)ChromaDB默認(rèn)用SQLite但生產(chǎn)必須換PostgreSQL。Mac本地調(diào)試時(shí)PostgreSQL連接字符串中加L4參數(shù)postgresql://user:passlocalhost:5432/chroma?options-c%20tcp_keepalives_idle60%20-c%20tcp_keepalives_interval30%20-c%20tcp_keepalives_count3這確保TCP心跳在60秒無(wú)數(shù)據(jù)時(shí)啟動(dòng)每30秒探測(cè)3次失敗斷連。4. Nginx反向代理的L3/L4加固即使Mac本地用Nginx做API網(wǎng)關(guān)也要配upstream rag_service { server 127.0.0.1:8000; keepalive 32; # L4連接池大小 } server { location /api/ { proxy_pass http://rag_service; proxy_http_version 1.1; proxy_set_header Connection ; # 關(guān)閉HTTP/1.0連接頭 proxy_set_header Host $host; # L3層超時(shí) proxy_connect_timeout 5s; proxy_send_timeout 30s; proxy_read_timeout 30s; # L4層緩沖 proxy_buffering on; proxy_buffer_size 128k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k; } }proxy_buffering on防止大響應(yīng)體阻塞連接keepalive 32復(fù)用后端連接。5. DNS預(yù)解析腳本Mac的/etc/resolver不生效時(shí)寫個(gè)啟動(dòng)腳本#!/bin/bash # pre_resolve.sh echo Pre-resolving critical domains... dig short rag-vector-db.local /dev/null dig short kg-api.local /dev/null echo DNS pre-warmed.在docker-compose up前執(zhí)行避免首次請(qǐng)求卡DNS。6. TLS證書(shū)的L4兼容性Mac本地用自簽名證書(shū)時(shí)curl默認(rèn)校驗(yàn)嚴(yán)格。開(kāi)發(fā)時(shí)臨時(shí)關(guān)閉# 僅限本地開(kāi)發(fā)生產(chǎn)嚴(yán)禁 export CURL_CA_BUNDLE curl --insecure https://localhost:8000/health但代碼中必須用verifyFalse顯式聲明提醒自己上線前替換為真實(shí)證書(shū)。提示這6個(gè)參數(shù)不是“高級(jí)技巧”而是Mac上RAG開(kāi)發(fā)的生存底線。我見(jiàn)過(guò)3個(gè)團(tuán)隊(duì)因忽略第1項(xiàng)MTU導(dǎo)致ChromaDB數(shù)據(jù)寫入靜默失敗日志全綠但查詢永遠(yuǎn)空。5. 真實(shí)故障復(fù)盤一次L4連接池耗盡引發(fā)的RAG雪崩5.1 故障全景從用戶投訴到根因定位的4小時(shí)事件某在線教育平臺(tái)RAG知識(shí)庫(kù)上午10:00起用戶投訴“提問(wèn)無(wú)響應(yīng)”監(jiān)控顯示API成功率從99.9%驟降至12%。Step 1L7層快速排除0–15分鐘檢查L(zhǎng)LM服務(wù)GPU顯存充足推理延遲正常檢查向量庫(kù)ChromaDB查詢延遲50ms索引完整檢查日志大量ConnectionResetError和TimeoutError但無(wú)具體堆棧?！?初步判斷非L7問(wèn)題。Step 2L4層抓包分析15–90分鐘在RAG服務(wù)Pod內(nèi)執(zhí)行# 抓取到向量庫(kù)的TCP流量 tcpdump -i any port 8000 -w rag.pcapWireshark分析發(fā)現(xiàn)客戶端SYN包發(fā)出服務(wù)端SYN-ACK返回但客戶端不發(fā)ACK三次握手卡在第二步同時(shí)netstat -an | grep :8000 | wc -l顯示ESTABLISHED連接數(shù)達(dá)1023Linux默認(rèn)上限ss -s顯示tcp:字段中inuse為1023orphan為0說(shuō)明連接未釋放?！?根因RAG服務(wù)調(diào)用向量庫(kù)的HTTP連接池耗盡新請(qǐng)求無(wú)法建連。Step 3定位連接池泄漏點(diǎn)90–180分鐘檢查Python代碼發(fā)現(xiàn)一處異步調(diào)用未加await# 錯(cuò)誤代碼漏掉await協(xié)程未執(zhí)行 async def query_vector_db(query): response client.post(/search, json{q: query}) # 應(yīng)為await client.post(...) return response.json()這導(dǎo)致HTTP連接被創(chuàng)建但從未被await釋放連接句柄一直占著。每分鐘新增200個(gè)泄漏連接3小時(shí)后突破1024上限。Step 4熱修復(fù)與長(zhǎng)效方案180–240分鐘熱修復(fù)重啟RAG服務(wù)Pod連接池重置長(zhǎng)效a) 代碼層所有httpx.AsyncClient調(diào)用強(qiáng)制awaitCI加入AST靜態(tài)檢查b) L4層在httpx.AsyncClient配置中加timeouthttpx.Timeout(10.0)超時(shí)自動(dòng)釋放連接c) 監(jiān)控層新增指標(biāo)http_client_active_connections閾值告警設(shè)為800。注意這個(gè)故障90%的團(tuán)隊(duì)會(huì)歸因?yàn)椤按abug”但它本質(zhì)是L4連接管理缺失。沒(méi)有L4層連接池監(jiān)控再好的L7代碼也扛不住泄漏。5.2 RAG性能壓測(cè)的L3/L4黃金指標(biāo)清單壓測(cè)不是只看QPS必須盯住L3/L4層指標(biāo)指標(biāo)健康閾值危險(xiǎn)信號(hào)排查方向TCP retransmit rate 0.1% 1%網(wǎng)絡(luò)丟包查物理鏈路或防火墻DNS resolution time (P95) 50ms 200msDNS服務(wù)器過(guò)載或緩存失效HTTP/2 stream error rate 0.01% 0.1%SETTINGS幀協(xié)商失敗或流控窗口溢出TLS handshake time (P95) 80ms 200ms證書(shū)鏈過(guò)長(zhǎng)或OCSP stapling未啟用TIME_WAIT count 30000 50000應(yīng)用層未復(fù)用連接或net.ipv4.tcp_tw_reuse未開(kāi)MTU path discovery loss0% 0.5%路徑中存在不支持DF位的設(shè)備我們給每個(gè)RAG項(xiàng)目標(biāo)配PrometheusGrafana看板其中L3/L4指標(biāo)占60%。L7指標(biāo)如檢索延遲、LLM token/s只是結(jié)果L3/L4指標(biāo)才是原因。就像醫(yī)生不會(huì)只看體溫還要查血氧、心率、血壓。5.3 給新手的3條鐵律避開(kāi)L3/L4坑的最低成本實(shí)踐永遠(yuǎn)不要相信默認(rèn)配置Nginx的client_max_body_size 1m、Python的httpx默認(rèn)連接池、Docker的MTU 1500——這些默認(rèn)值是為博客系統(tǒng)設(shè)計(jì)的不是為RAG。每次部署第一件事是查文檔把L3/L4參數(shù)按RAG流量特征重設(shè)。我們有個(gè)checklist上線前逐項(xiàng)打鉤。監(jiān)控必須前置而非事后補(bǔ)救在寫第一行RAG業(yè)務(wù)代碼前先搭好L3/L4監(jiān)控ss -s、netstat -s、dig stats、curl -w curl-format.txt。很多團(tuán)隊(duì)等出事才裝監(jiān)控那時(shí)已錯(cuò)過(guò)黃金排查期。我們要求RAG服務(wù)啟動(dòng)后5分鐘內(nèi)L3/L4指標(biāo)必須出現(xiàn)在Grafana。本地開(kāi)發(fā)即生產(chǎn)鏡像Mac上的Docker Compose配置必須和K8s生產(chǎn)YAML保持L3/L4參數(shù)一致MTU、keepalive、timeout。用kompose convert或skaffold同步配置避免“本地OK線上崩”。差異只能是資源規(guī)格CPU/Memory不能是網(wǎng)絡(luò)行為。我在深圳某AI公司做技術(shù)顧問(wèn)時(shí)見(jiàn)過(guò)最慘案例團(tuán)隊(duì)花3個(gè)月調(diào)優(yōu)RAG檢索算法上線后用戶說(shuō)“比原來(lái)還慢”。最后發(fā)現(xiàn)他們用Mac開(kāi)發(fā)生產(chǎn)用AWS但Nginx配置里proxy_read_timeout仍設(shè)為60秒Mac本地測(cè)試夠用而AWS上因網(wǎng)絡(luò)抖動(dòng)60秒不夠大量請(qǐng)求被Nginx主動(dòng)中斷重試。改到120秒性能立刻回歸預(yù)期。護(hù)城河不在算法多深而在是否把網(wǎng)絡(luò)的“水”調(diào)對(duì)了深度。