1. 為什么“輕型AI中臺”能同時解決錄入和對賬兩個老大難1.1 先看看重復(fù)錄入是怎么發(fā)生的先說個我參與過的真實場景。某家商貿(mào)公司每天的業(yè)務(wù)路徑大概是這樣的銷售在CRM里錄入一筆訂單財務(wù)在ERP里根據(jù)紙質(zhì)單據(jù)再錄一遍應(yīng)收款倉庫人員在WMS里又輸一次出入庫信息最后運(yùn)營同事還要把關(guān)鍵數(shù)據(jù)填進(jìn)Excel報表里做日報。同一筆業(yè)務(wù)四個系統(tǒng)四遍錄入。更麻煩的是不同系統(tǒng)之間的數(shù)據(jù)還不完全一致——CRM里客戶名稱寫的是“北京華信科技有限公司”ERP里可能簡寫成“華信科技”Excel里干脆叫“華信”。等到月底對賬的時候財務(wù)對著三份數(shù)據(jù)找差異光核對客戶名稱就耗掉半天。這種“多點(diǎn)錄入、數(shù)據(jù)孤島、月底對賬難”的問題在中小型企業(yè)里極其普遍。原因并不復(fù)雜早期信息化建設(shè)都是按部門逐個上系統(tǒng)的每個系統(tǒng)各自為政數(shù)據(jù)口徑不統(tǒng)一接口也沒有打通。大家都在喊“數(shù)字化轉(zhuǎn)型”但真正的痛點(diǎn)并不是缺系統(tǒng)而是系統(tǒng)之間不對話。1.2 對賬困難的根本原因?qū)~難最直接的原因是“數(shù)據(jù)對不上”。但深入一看問題往往出在三個層面第一數(shù)據(jù)源不統(tǒng)一。同一個業(yè)務(wù)對象在各系統(tǒng)里的編碼、命名、格式不一樣導(dǎo)致同一筆業(yè)務(wù)在A系統(tǒng)里是“已收款”、在B系統(tǒng)里卻是“未核銷”兩邊拉出來一對比全是差異。第二時間口徑不一致。有的系統(tǒng)按“開票日期”記賬有的按“到賬日期”記賬還有的按“業(yè)務(wù)發(fā)生時點(diǎn)”記賬。日期對不上金額就對不上金額對不上賬務(wù)自然核不平。第三缺少自動核對機(jī)制。絕大多數(shù)企業(yè)還在用“導(dǎo)出Excel—VLOOKUP匹配—肉眼找差異”這種手工對賬方式效率低不說還特別容易漏。一個月幾百上千筆流水光靠人眼盯出錯只是時間問題。1.3 “輕型”意味著什么為什么不上一套重型中臺很多企業(yè)一聽“中臺”兩個字就頭皮發(fā)麻覺得那是大廠才玩得起的東西少說也要幾百萬預(yù)算、十幾號人的團(tuán)隊才能落地。這里我想澄清一個概念中臺的本質(zhì)是“把公共能力抽出來復(fù)用”而不是“買一套巨型軟件”。重型數(shù)據(jù)中臺確實包含了數(shù)據(jù)湖、數(shù)據(jù)倉庫、計算引擎、數(shù)據(jù)治理等一系列組件投入大、周期長。但對大多數(shù)中小企業(yè)來說壓根用不上那些重量級能力它們真正需要的是能讓幾個關(guān)鍵業(yè)務(wù)系統(tǒng)“對話”起來、把重復(fù)的人工操作替代掉的輕量化方案。所以我在這個項目里定義的“輕型AI中臺”用一句話概括就是用容器化部署的AI服務(wù)集群把數(shù)據(jù)采集、智能識別、自動錄入、差異核對這些公共能力沉淀下來以接口方式提供給CRM、ERP、財務(wù)系統(tǒng)調(diào)用。整套系統(tǒng)跑在普通服務(wù)器上用Docker編排大模型部分用Ollama跑本地開源模型不走云端API數(shù)據(jù)不出內(nèi)網(wǎng)既合規(guī)又省錢。從立項到上線跑通核心流程前后用了一個多月硬件成本控制在幾萬塊以內(nèi)。這個思路才適合絕大多數(shù)企業(yè)“花小錢辦大事”的訴求。2. 部署前的核心設(shè)計從“數(shù)據(jù)流”倒推整個方案2.1 兩張表理清需求數(shù)據(jù)源清單和字段映射表真正動手寫代碼之前先別急著安裝環(huán)境。我踩過的最大一個坑就是一上來先部署模型結(jié)果業(yè)務(wù)需求還沒理清楚做了一堆用不上的功能。正確的順序是先把業(yè)務(wù)側(cè)的東西理干凈。我建議團(tuán)隊里負(fù)責(zé)業(yè)務(wù)的人拉通一起做兩件事第一件事整理一份數(shù)據(jù)源清單。把企業(yè)里所有涉及錄入、流轉(zhuǎn)、核對環(huán)節(jié)的系統(tǒng)全部列出來包括系統(tǒng)名稱、業(yè)務(wù)用途、數(shù)據(jù)入口、有無開放接口、數(shù)據(jù)存在哪個庫哪張表。這一步看起來簡單實際做起來很費(fèi)勁因為很多老系統(tǒng)的接口文檔早就丟了得靠問老員工才知道數(shù)據(jù)在哪。我當(dāng)時的清單長這樣系統(tǒng)業(yè)務(wù)職責(zé)數(shù)據(jù)入口接口情況數(shù)據(jù)結(jié)構(gòu)CRM客戶管理、銷售訂單手工錄入有REST接口MySQLERP財務(wù)記賬、應(yīng)收應(yīng)付紙質(zhì)單據(jù)手工僅提供查詢視圖SQL ServerWMS出入庫管理掃碼手工有接口但字段不全OracleExcel日報運(yùn)營匯總手工復(fù)制粘貼無文件第二件事建立字段映射表。把同一個業(yè)務(wù)對象在不同系統(tǒng)中的字段對應(yīng)關(guān)系列出來。比如“客戶名稱”這一項CRM里叫customer_nameERP里叫cust_nameExcel里叫“客戶”格式和長度都不一樣。這張表是整個AI中臺的數(shù)據(jù)字典后續(xù)所有清洗、映射、比對規(guī)則都從這張表出發(fā)。做完這兩張表整個項目的邊界就清晰了要把哪些數(shù)據(jù)打通要在哪里做轉(zhuǎn)換在哪里做校驗一目了然。2.2 技術(shù)選型本地大模型、OCR服務(wù)和自動化流程怎么搭配輕型AI中臺的技術(shù)棧我最終選了“本地大模型OCR接口服務(wù)定時任務(wù)RPA兜底”這樣的組合。選型的邏輯是這樣的本地大模型用Ollama部署。為什么用Ollama它輕量、對硬件要求友好、支持一鍵拉起主流開源模型而且通過OpenAI兼容接口對外提供服務(wù)后續(xù)寫代碼調(diào)用非常方便。模型方面我選了Qwen系列通義千問的本地版因為它對中文語境的理解、關(guān)鍵信息抽取、文本分類這些任務(wù)表現(xiàn)都不錯而且模型體積適中一臺16G顯存的顯卡就能跑起來正好符合“輕型”的定位。OCR服務(wù)用PaddleOCR。對賬過程中有大量紙質(zhì)單據(jù)、PDF文件、掃描件需要轉(zhuǎn)成結(jié)構(gòu)化數(shù)據(jù)PaddleOCR開源免費(fèi)、支持中英文識別、表格結(jié)構(gòu)還原能力強(qiáng)部署也不復(fù)雜直接Docker起一個服務(wù)就行。接口集成用Python的FastAPI寫一個中間層。中臺的核心是“能力復(fù)用”所以我寫了一個統(tǒng)一的數(shù)據(jù)接入服務(wù)把CRM、ERP、WMS這些系統(tǒng)的數(shù)據(jù)都通過這個服務(wù)匯聚到中臺的數(shù)據(jù)模型里。FastAPI輕量、性能好、寫起來快非常適合做這種內(nèi)部工具。RPA用開源框架做兜底。萬一遇到完全沒有接口的老系統(tǒng)就需要模擬人工操作來錄入和讀取數(shù)據(jù)。我用了開源RPA框架具體名字不說了大家按團(tuán)隊熟悉度選就行腳本錄制好之后掛到定時任務(wù)里跑。整個選型的原則就三條能用開源的絕不商業(yè)采購能本地跑的絕不上云能接口直連的絕不人工搬運(yùn)。2.3 系統(tǒng)架構(gòu)五層結(jié)構(gòu)劃分清楚3. 環(huán)境準(zhǔn)備與基礎(chǔ)部署容器化是“輕型”的關(guān)鍵支撐3.1 硬件配置建議先說硬件。輕型AI中臺的硬件門檻并沒有很多人想象得那么高。我的建議配置是這樣的CPU選用主流8核以上內(nèi)存32G起步GPU至少一張16G顯存的顯卡NVIDIA的RTX 4090或者A4000這一級別存儲用1TB SSD。這樣的配置跑一個7B~14B參數(shù)量的量化模型做文本處理或者跑PaddleOCR做文字識別都綽綽有余。如果預(yù)算實在有限甚至可以先用一張8G顯存的卡跑量化版的7B模型起步先把流程跑通后面業(yè)務(wù)需求提升了再擴(kuò)。這里有個經(jīng)驗?zāi)Ｐ筒辉诖髩蛴镁托小Ｎ覀兊膶嶋H業(yè)務(wù)里信息抽取和分類任務(wù)用7B的模型就夠了硬上70B的大模型反而推理速度慢、硬件成本高體驗并不好。操作系統(tǒng)我就直接用Ubuntu 22.04 LTS干凈、穩(wěn)定對Docker和GPU驅(qū)動的兼容性都很好。3.2 Docker部署基礎(chǔ)服務(wù)整個中臺的基礎(chǔ)設(shè)施我全部用Docker Compose編排好處是后續(xù)遷移、擴(kuò)展、備份都方便一臺新機(jī)器拉一下配置就能復(fù)現(xiàn)整套環(huán)境?；A(chǔ)服務(wù)包括這些Nginx做反向代理和統(tǒng)一入口后續(xù)各服務(wù)都通過Nginx轉(zhuǎn)發(fā)請求方便做鑒權(quán)和日志審計。MySQL存中臺的元數(shù)據(jù)、字段映射表、對賬規(guī)則、運(yùn)行日志。Redis做緩存和異步任務(wù)隊列比如OCR識別任務(wù)、大模型推理任務(wù)的排隊都在Redis里做。MinIO對象存儲用來存掃描件、歷史對賬文件、導(dǎo)出報表。Docker Compose的編排文件結(jié)構(gòu)大概是這樣的我用一個簡單的示例說明version: 3.8 services: nginx: image: nginx:stable-alpine ports: - 80:80 volumes: - ./nginx/conf.d:/etc/nginx/conf.d depends_on: - ai-api mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: your_password MYSQL_DATABASE: ai_middle_platform volumes: - ./mysql_data:/var/lib/mysql redis: image: redis:7-alpine ports: - 6379:6379 minio: image: minio/minio:latest command: server /data --console-address :9001 ports: - 9000:9000 - 9001:9001部署Docker本身很簡單裝好之后把Compose文件丟上去docker compose up -d一條命令就全部拉起來了。真正花時間的反而是后面各業(yè)務(wù)服務(wù)的對接和調(diào)試。3.3 Ollama本地部署大模型這是整個中臺里最受關(guān)注也最容易出問題的一環(huán)。我直接在服務(wù)器上裝Ollama然后拉取對應(yīng)的模型。# 安裝Ollama curl -fsSL https://ollama.com/install.sh | sh # 拉取Qwen模型7B參數(shù)量的中文優(yōu)化版本 ollama pull qwen2.5:7b-instruct # 啟動服務(wù)默認(rèn)監(jiān)聽11434端口 ollama serve啟動之后Ollama會提供一個OpenAI兼容的API接口可以通過HTTP調(diào)用這就省去了自己搭模型服務(wù)的麻煩。調(diào)用的方式很簡單curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b-instruct, messages: [{role: user, content: 提取以下文本中的客戶名稱、訂單金額、開票日期}], temperature: 0.1 }這里有一個非常關(guān)鍵的參數(shù)經(jīng)驗temperature要調(diào)低盡量保持在0.1以下。因為我們的場景是信息抽取、結(jié)構(gòu)化輸出不是聊天寫詩需要的是穩(wěn)定、確定性的結(jié)果。溫度越高模型輸出的隨機(jī)性越大同一個單據(jù)每次抽出來的字段可能都不一樣這對后續(xù)對賬是災(zāi)難性的。另外一個容易被忽視的點(diǎn)是上下文窗口。有些字段特別多的單據(jù)文本長度很長如果超過模型的最大上下文長度尾部內(nèi)容可能被截斷導(dǎo)致抽取結(jié)果缺失。我的做法是在調(diào)用時顯式設(shè)置num_ctx參數(shù)一般設(shè)到8192以上保證單據(jù)全文都能進(jìn)入模型視野。3.4 部署驗證模型服務(wù)必須做的三輪測試服務(wù)部署完別急著往上接業(yè)務(wù)。我建議先做三輪驗證第一輪模型能力驗證。拿50張真實的歷史單據(jù)做測試分別用大模型抽取關(guān)鍵字段看準(zhǔn)確率能不能達(dá)到95%以上。達(dá)不到就考慮換模型、調(diào)整提示詞或者加后處理規(guī)則。第二輪接口穩(wěn)定性驗證。用腳本連續(xù)調(diào)用1000次觀察響應(yīng)時間、失敗率、顯存占用。我遇到過模型推理時間越來越長的問題排查下來是并發(fā)請求太多導(dǎo)致顯存溢出后來加了請求隊列和并發(fā)限制才解決。第三輪數(shù)據(jù)一致性驗證。用同一份輸入跑兩遍模型看輸出是否一致。如果有不一致的情況大概率就是temperature設(shè)置太高或者提示詞寫得不嚴(yán)謹(jǐn)。這三輪驗證做完才敢把模型服務(wù)正式交給業(yè)務(wù)側(cè)使用。4. 實戰(zhàn)消除重復(fù)錄入的三條落地路徑4.1 路徑一接口直連讓系統(tǒng)之間自動同步數(shù)據(jù)重復(fù)錄入的根治方案是讓系統(tǒng)之間自動對話根本不需要人手工在各種系統(tǒng)間搬運(yùn)數(shù)據(jù)。以我之前說的商貿(mào)公司為例最核心的打通是“CRM訂單→ERP財務(wù)”這條線。CRM有REST接口ERP雖然只能訪問只讀視圖但至少能查到數(shù)據(jù)。我在中臺里寫了一個數(shù)據(jù)同步服務(wù)每小時從CRM拉取新增和變更的訂單數(shù)據(jù)經(jīng)過字段映射和清洗后寫入ERP對應(yīng)的臨時表再由ERP自身的觸發(fā)器自動生成財務(wù)憑證。這樣做的好處是錄入動作只在一處發(fā)生其他系統(tǒng)自動跟隨徹底消除了“同一訂單錄兩遍”的問題。財務(wù)人員解放出來月底只需要核對異常項而不是重新錄一遍。接口直連的關(guān)鍵是解決“字段不一致”問題。我在前面提到的那張字段映射表在這里就發(fā)揮作用了從CRM拿到的customer_name在寫入ERP之前先跑一遍標(biāo)準(zhǔn)化規(guī)則比如全角轉(zhuǎn)半角、去除空白字符、統(tǒng)一簡稱和全稱。4.2 路徑二OCR加模型抽取把紙質(zhì)單據(jù)變成結(jié)構(gòu)化數(shù)據(jù)接口直連能覆蓋有API的系統(tǒng)但大量紙質(zhì)單據(jù)怎么處理這才是重復(fù)錄入的重災(zāi)區(qū)。流程是這樣的業(yè)務(wù)人員把紙質(zhì)單據(jù)拍照或者掃描后傳入中臺PaddleOCR先做文字識別把圖片變成文本然后大模型從文本里抽取關(guān)鍵字段客戶名稱、單據(jù)編號、金額、日期、商品明細(xì)等最后寫入結(jié)構(gòu)化數(shù)據(jù)表。在這個流程里兩個環(huán)節(jié)最容易出問題OCR識別錯誤。尤其是一些打印質(zhì)量差的單據(jù)、蓋章遮擋了文字、表格線條干擾識別。我的經(jīng)驗是OCR參數(shù)要針對單據(jù)場景調(diào)優(yōu)比如啟用表格結(jié)構(gòu)識別、設(shè)置合適的文本檢測閾值。還有一個笨辦法但很好用——把OCR原結(jié)果保存下來后續(xù)發(fā)現(xiàn)錯誤可以追溯。大模型抽取不穩(wěn)定。即使前面OCR結(jié)果是對的不同單據(jù)的措辭風(fēng)格不一樣模型偶爾會漏抽字段。我寫了兩種方式提升穩(wěn)定性一是設(shè)計嚴(yán)格的提示詞模板要求模型嚴(yán)格按JSON格式輸出字段缺失就返回null而不是自行推斷二是對抽取結(jié)果做規(guī)則校驗比如“金額”字段必須是數(shù)字且與單據(jù)表格內(nèi)的合計一致不符合規(guī)則就觸發(fā)人工審核。4.3 路徑三RPA兜底沒有接口的老系統(tǒng)也能打通這是很多人忽略的一點(diǎn)企業(yè)里總有那么幾個“沒救”的老系統(tǒng)沒有API、沒有開放數(shù)據(jù)庫權(quán)限、甚至界面還是CS架構(gòu)的老程序。這種系統(tǒng)的數(shù)據(jù)錄入只能靠人工。RPA解決的就是這類問題。我在中臺里用開源RPA框架寫了一套腳本模擬人工操作打開老系統(tǒng)界面在指定的輸入框里填入從其他系統(tǒng)同步過來的數(shù)據(jù)點(diǎn)保存再截圖驗證是否錄入成功。腳本跑在專門的RPA執(zhí)行機(jī)一臺裝了Windows的普通PC上由中臺的定時任務(wù)調(diào)度。RPA這條路有三個坑提醒一下第一腳本穩(wěn)定性。界面稍微一變化腳本就廢了所以要用穩(wěn)定的元素定位方式比如窗口句柄、控件ID而不是靠坐標(biāo)點(diǎn)。第二執(zhí)行過程要有日志。每步操作都要記錄方便失敗時回溯。我一開始沒注意結(jié)果腳本跑飛了都不知道它做了什么后來加了截圖留痕才算安心。第三異常情況要設(shè)人工介入通道。比如老系統(tǒng)彈出意外對話框腳本卡住了要有告警通知人處理否則半夜定時任務(wù)跑掛了沒人知道。有了這三條路徑企業(yè)里90%以上的重復(fù)錄入場景基本都能覆蓋。剩下10%的特殊單據(jù)再交給人工兜底量已經(jīng)很小了。5. 實戰(zhàn)AI輔助對賬把“對不上”變成“找得到”5.1 對賬數(shù)據(jù)統(tǒng)一建模錄入問題解決之后對賬問題就好辦多了因為各系統(tǒng)的數(shù)據(jù)已經(jīng)在中臺里匯聚成統(tǒng)一的模型了。我把對賬相關(guān)的數(shù)據(jù)統(tǒng)一建模成“明細(xì)流水 賬單匯總”兩層結(jié)構(gòu)。明細(xì)流水記錄每一筆業(yè)務(wù)的實際發(fā)生信息業(yè)務(wù)編號、交易時間、客戶編碼、商品明細(xì)、金額、狀態(tài)等賬單匯總則按天、按客戶、按賬期聚合數(shù)據(jù)。這樣一來無論是逐筆勾對還是賬單核銷都有清晰的數(shù)據(jù)基礎(chǔ)。建好模型之后對賬的本質(zhì)就變成了把不同來源的明細(xì)流水按業(yè)務(wù)主鍵對齊比對關(guān)鍵字段是否一致。業(yè)務(wù)主鍵一般選擇“業(yè)務(wù)單據(jù)編號 業(yè)務(wù)類型 金額”的組合盡可能保證唯一性。5.2 差異識別規(guī)則引擎對賬的核心引擎是一個差異識別規(guī)則引擎。規(guī)則分三層第一層完全一致。兩邊數(shù)據(jù)主鍵能對上、字段值完全一致直接標(biāo)記為“已對平”。第二層容差一致。金額差異在允許范圍內(nèi)比如單筆金額誤差小于0.01元或者日期相差一天以內(nèi)跨日到賬場景標(biāo)記為“有差異但可核銷”由規(guī)則引擎自動生成調(diào)整說明。第三層無法匹配。一邊有記錄另一邊沒有或者金額差異超限標(biāo)記為“異常差異”需要人工介入。規(guī)則引擎實現(xiàn)起來不難難點(diǎn)在于“容差規(guī)則怎么定”。我的經(jīng)驗是不要拍腦袋定閾值而是先拿三個月的歷史數(shù)據(jù)做統(tǒng)計分析看差異的分布規(guī)律再定。比如歷史數(shù)據(jù)里95%的同筆訂單日期差異都在1天以內(nèi)那么“日期容差1天”就是合理的閾值。5.3 大模型輔助異常核查規(guī)則引擎能把90%的對賬工作自動化剩下的10%異常差異就是過去財務(wù)最頭疼的部分。這里大模型能幫上大忙。我把異常差異的結(jié)構(gòu)化信息業(yè)務(wù)編號、兩邊金額、日期、客戶、備注等拼成一個上下文化描述發(fā)給本地大模型讓模型幫助分析和研判。例如“A系統(tǒng)顯示應(yīng)收款12000元B系統(tǒng)顯示已收11500元差500元客戶備注中提到過折扣請分析可能的核銷原因。”本地大模型基于已有的業(yè)務(wù)上下文常常能給出比較靠譜的判斷方向比如“該客戶在B系統(tǒng)中有折扣記錄建議與財務(wù)確認(rèn)折扣審批單是否同步”。這大大縮小了人工核查的范圍——財務(wù)不再需要對每一筆異常差異從頭查起而是直接按模型提示的方向去核對或補(bǔ)證。當(dāng)然這里必須強(qiáng)調(diào)大模型只做輔助分析和建議最終核銷動作還是要由人工確認(rèn)不能全自動。財務(wù)合規(guī)這根弦任何時候都不能松AI只是把人從低效勞動里解放出來而不是替代人做決策。6. 常見問題與排查實錄6.1 部署層面的問題Ollama服務(wù)突然不響應(yīng)現(xiàn)象系統(tǒng)跑了兩周之后某個早上大模型接口突然超時所有依賴模型的服務(wù)全部報錯。排查過程首先看進(jìn)程還在不在發(fā)現(xiàn)Ollama進(jìn)程還在。然后看日志發(fā)現(xiàn)GPU顯存占用滿了模型推理請求全部卡在等待隊列里。進(jìn)一步查是因為前一天業(yè)務(wù)方同時跑了一個批量處理任務(wù)一次性投了幾百條識別請求進(jìn)來把顯存擠爆了。解決辦法在API網(wǎng)關(guān)層加了請求并發(fā)控制限制同時進(jìn)行的模型推理任務(wù)數(shù)超出部分排隊。同時在Batch任務(wù)里設(shè)置了速率限制避免高峰時段一口氣全壓進(jìn)來。教訓(xùn)任何AI服務(wù)接入生產(chǎn)環(huán)境之前一定要做好并發(fā)評估和限流設(shè)計不能理所當(dāng)然地認(rèn)為模型服務(wù)隨便扛。6.2 識別準(zhǔn)確率問題金額字段偶爾抽錯現(xiàn)象單據(jù)金額字段偶發(fā)抽錯導(dǎo)致對賬時產(chǎn)生虛假差異浪費(fèi)了不少精力。排查過程抽取出來的錯誤金額兩個典型情況一是千分位分隔符被識別成小數(shù)點(diǎn)比如“1,234.56”變成了“1.234”二是“合計金額”區(qū)域被干擾行影響抽到的是明細(xì)金額而不是匯總金額。解決辦法在模型抽取之后加一層規(guī)則校驗金額字段必須匹配“數(shù)字最多兩位小數(shù)”的正則表達(dá)式并且要和單據(jù)OCR還原的表格里的“合計”行交叉驗證。另外提示詞里明確要求“忽略千分位分隔符只輸出純數(shù)字格式”準(zhǔn)確率明顯提升了。6.3 性能問題對賬任務(wù)跑得越來越慢現(xiàn)象上線初期對賬任務(wù)30分鐘能跑完三個月后要跑2個多小時。排查過程數(shù)據(jù)量增長是主因但慢得更厲害是因為規(guī)則引擎里大量使用了全表掃描式的字符串匹配數(shù)據(jù)庫里客戶名稱存在臟數(shù)據(jù)用模糊匹配找關(guān)聯(lián)記錄導(dǎo)致計算量指數(shù)級增長。解決辦法給業(yè)務(wù)主鍵建索引差量計算改成增量計算只對新增和變更數(shù)據(jù)跑規(guī)則臟數(shù)據(jù)歷史數(shù)據(jù)單獨(dú)跑了清洗任務(wù)。優(yōu)化之后對賬時間回到40分鐘以內(nèi)。6.4 日常使用中容易忽略的幾件小事模型更新之后要回歸測試。我升過一次本地模型版本結(jié)果抽取格式變了要不是回歸測試及時發(fā)現(xiàn)差點(diǎn)帶病上線。以后我都固定一個測試集每次換模型先跑一遍對比。服務(wù)日志要留夠。中臺的運(yùn)行日志、調(diào)用參數(shù)、出參結(jié)果至少保留3個月。排查問題全靠日志我第一次遇到接口異常時翻不了日志折騰了很久才追到根因。數(shù)據(jù)備份不能漏。中臺里存著各系統(tǒng)匯聚的業(yè)務(wù)數(shù)據(jù)萬一誤刪非常麻煩。我加了每日自動備份到MinIO保留30天穩(wěn)妥起見跨服務(wù)器再同步一份。7. 這套中臺后續(xù)還能怎么擴(kuò)展輕型AI中臺跑通之后很多同事開始主動往上靠這說明路子走對了。幾個比較容易擴(kuò)展的方向合同/資質(zhì)審核OCR加模型把紙質(zhì)合同的關(guān)鍵條款抽取出來做合規(guī)檢查。智能客服知識庫把對賬FAQ、客服話術(shù)灌到模型里做一個內(nèi)網(wǎng)版的智能問答助手。經(jīng)營分析報表各系統(tǒng)數(shù)據(jù)已經(jīng)在中臺匯聚做跨系統(tǒng)的經(jīng)營駕駛艙就容易多了。我個人在實際操作中最深的體會是中臺的核心不是技術(shù)多炫而是能不能真正把公共能力沉淀下來、讓業(yè)務(wù)方愿意用。技術(shù)選型完全可以從小做起一臺服務(wù)器、一張顯卡、幾個開源組件照樣能撐起一個讓業(yè)務(wù)部門明顯感知到“省事了”的輕型AI中臺。項目真正的成功標(biāo)志不是部署了多少組件而是月底財務(wù)終于不用加班核對流水了。