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