戰(zhàn):OCR識別與規(guī)則引擎如何消滅重復(fù)錄入和對賬難題)
我們公司是做商貿(mào)分銷的旗下還有兩家工廠業(yè)務(wù)線拉得比較長。以前最讓我頭疼的不是客戶怎么談而是每個(gè)月結(jié)賬那幾天——財(cái)務(wù)幾個(gè)人趴在電腦前手里一堆紙質(zhì)單據(jù)和Excel這邊錄入采購單那邊核對銀行流水經(jīng)常對到晚上十點(diǎn)還沒對完。重復(fù)錄入的問題更是普遍同一張發(fā)票業(yè)務(wù)員錄一遍財(cái)務(wù)入賬錄一遍月底對賬又翻出來核對一遍。后來我下決心部署了一套輕型的AI中臺幾個(gè)月跑下來真的把這兩塊頑疾治得差不多了。今天把這套方案的思路、選型、實(shí)操步驟和踩過的坑都寫出來給同樣被錄入和對賬折磨的朋友一個(gè)參考。這套輕型AI中臺本質(zhì)上不是一個(gè)龐大的數(shù)據(jù)平臺而是一個(gè)“能消化單據(jù)、能清洗數(shù)據(jù)、能自動(dòng)匹配”的智能業(yè)務(wù)處理層。它解決的問題很聚焦減少人工重復(fù)錄入提升對賬效率。適合的對象是中小型貿(mào)易公司、制造業(yè)工廠、連鎖門店以及任何還在用“Excel 人工”處理財(cái)務(wù)錄單和對賬的團(tuán)隊(duì)。不需要幾十臺服務(wù)器一臺普通業(yè)務(wù)服務(wù)器、一套OCR識別服務(wù)、一個(gè)規(guī)則引擎再加一個(gè)簡單的調(diào)度任務(wù)就可以跑起來。1. 為什么非得是“輕型”AI中臺1.1 先算一筆賬重型方案到底貴在哪很多企業(yè)一聽到“中臺”兩個(gè)字第一反應(yīng)就是“那是大廠才玩得起的東西”。確實(shí)如果你去咨詢某些頭部云廠商他們給你出的方案動(dòng)不動(dòng)就是數(shù)據(jù)中臺、業(yè)務(wù)中臺、技術(shù)中臺三件套預(yù)算輕松上百萬實(shí)施周期按年算。但說實(shí)話對于一家年?duì)I收幾個(gè)億的中小企業(yè)我們根本用不到那種級別的抽象能力和彈性擴(kuò)展。我當(dāng)初算過一筆賬要解決重復(fù)錄入和對賬困難核心工作就三件事。第一把紙質(zhì)的、圖片的、PDF的單據(jù)變成結(jié)構(gòu)化數(shù)據(jù)第二把分散在ERP、Excel、郵箱里的數(shù)據(jù)按統(tǒng)一規(guī)則清洗和比對第三把匹配不上的異常項(xiàng)自動(dòng)推送給人去處理。這三件事一臺16核32G的服務(wù)器加上OCR服務(wù)、數(shù)據(jù)庫和幾個(gè)Python服務(wù)完全能扛住。整套軟硬件加實(shí)施費(fèi)用控制在20萬以內(nèi)一個(gè)季度省下來的人力成本就回來了。重型方案貴在哪里貴在建模、數(shù)據(jù)治理、組織架構(gòu)調(diào)整這些前置投入。而輕型AI中臺的核心思路是“小步快跑”先從單個(gè)高頻痛點(diǎn)下手把識別、匹配、流程閉環(huán)做扎實(shí)再逐步擴(kuò)展。我自己的體會(huì)是中小企業(yè)的AI轉(zhuǎn)型千萬不要一上來就搞大而全選一個(gè)最痛的點(diǎn)打穿比鋪一個(gè)大攤子有用得多。1.2 輕型AI中臺的模塊選型與部署形態(tài)部署形態(tài)上我建議采用“本地服務(wù) 云端API”的混合方式。單據(jù)識別這塊用本地的OCR服務(wù)保證數(shù)據(jù)和單據(jù)不出內(nèi)網(wǎng)這是財(cái)務(wù)數(shù)據(jù)安全的基本底線。對賬匹配引擎和規(guī)則引擎完全跑在本地服務(wù)器上。至于模型訓(xùn)練和更新可以用云端算力定期做或者干脆用開源的預(yù)訓(xùn)練模型在本地微調(diào)。模塊選型講究“夠用就好”。我當(dāng)時(shí)調(diào)研了一圈最終選定的核心組件是OCR識別服務(wù)選了一款支持表格結(jié)構(gòu)還原的本地部署OCR能識別增值稅發(fā)票、銀行回單、出庫單、入庫單、快遞面單等常見單據(jù)。關(guān)鍵指標(biāo)是字段級的準(zhǔn)確率而不是整頁識別率。規(guī)則引擎用Drools的邏輯來編排匹配規(guī)則但因?yàn)榧夹g(shù)團(tuán)隊(duì)更熟悉Python最終用Python自研了一個(gè)輕量的規(guī)則配置表存數(shù)據(jù)庫里動(dòng)態(tài)生效。調(diào)度與消息隊(duì)列用Celery做異步任務(wù)調(diào)度確保Excel導(dǎo)入、大批量匹配計(jì)算不阻塞主流程。數(shù)據(jù)存儲主庫用PostgreSQL用于存儲結(jié)構(gòu)化單據(jù)和匹配結(jié)果。另外加了一個(gè)Redis用來做去重緩存和實(shí)時(shí)比對。很多朋友一上來就問用什么AI框架、用什么深度學(xué)習(xí)模型。我的建議是實(shí)際上手一個(gè)業(yè)務(wù)流程你百分之八十的時(shí)間花在數(shù)據(jù)清洗和規(guī)則定義上而不是模型調(diào)參上。選型時(shí)一定要評估團(tuán)隊(duì)的維護(hù)能力如果團(tuán)隊(duì)沒有專職算法工程師盡量選成熟的開源方案而不是自己從零訓(xùn)練一個(gè)模型。1.3 一個(gè)容易忽略的決策點(diǎn)接口、數(shù)據(jù)權(quán)限與安全邊界部署過程中最容易被低估的是接口改造和數(shù)據(jù)權(quán)限設(shè)計(jì)。AI中臺不是獨(dú)立存在的它要和現(xiàn)有的ERP、OA、財(cái)務(wù)系統(tǒng)打通。如果原有系統(tǒng)沒有開放API就得靠定時(shí)導(dǎo)出導(dǎo)入或者直接操作數(shù)據(jù)庫表這就有很多隱形工作量。我們公司的情況是ERP是老牌國產(chǎn)生態(tài)系統(tǒng)開放了一部分API但字段命名很不規(guī)范。比如“客戶名稱”在銷售訂單表里叫cust_name在收款單里叫customername在報(bào)表里又變成了“客商名稱”。這些不一致不處理后面AI匹配就全亂套。數(shù)據(jù)權(quán)限方面我的原則是“最小可見性”。業(yè)務(wù)員通過中臺只能看到和自己相關(guān)的單據(jù)財(cái)務(wù)人員能看全部但操作有審計(jì)日志。這個(gè)權(quán)限模型在初期就要搭好不然上線后光權(quán)限糾紛就能煩死你。安全邊界上還要考慮單據(jù)的存儲加密和傳輸加密。我見過一些方案直接讓AI模型調(diào)用公網(wǎng)API識別發(fā)票這在合規(guī)上是有風(fēng)險(xiǎn)的。發(fā)票、回單、合同都是敏感的財(cái)務(wù)信息能本地化處理就一定本地化。2. 消滅重復(fù)錄入的三個(gè)實(shí)際戰(zhàn)場2.1 采購單據(jù)與發(fā)票的自動(dòng)識別入庫重復(fù)錄入最重的地方在采購。我們的采購流程是這樣的采購員在ERP里下一張采購訂單供應(yīng)商發(fā)貨時(shí)附帶紙質(zhì)送貨單和發(fā)票倉庫收貨后要手工錄入實(shí)收數(shù)量財(cái)務(wù)拿到發(fā)票后還要錄入憑證。一張單據(jù)平均被錄入三遍。用AI中臺后流程變成了這樣倉庫收貨時(shí)直接用高拍儀或手機(jī)拍攝送貨單OCR自動(dòng)識別單號、品名、數(shù)量和ERP里的采購訂單進(jìn)行自動(dòng)匹配匹配上了就自動(dòng)生成入庫草稿單。倉管員只需要核對一眼數(shù)量點(diǎn)確認(rèn)即可。發(fā)票到了財(cái)務(wù)后掃描或拍照上傳OCR識別發(fā)票代碼、號碼、金額、稅額自動(dòng)關(guān)聯(lián)到對應(yīng)的采購訂單和入庫單然后生成預(yù)制憑證。這里有幾個(gè)細(xì)節(jié)要注意。第一OCR識別送貨單上的手寫體如果識別率不夠高不要追求全自動(dòng)識別成草稿給人確認(rèn)是最穩(wěn)妥的。第二匹配邏輯要考慮多對一和一對多的情況不能一刀切地按訂單號匹配要支持?jǐn)?shù)量累計(jì)匹配。第三發(fā)票識別要關(guān)注價(jià)稅分離這直接關(guān)系到后面財(cái)務(wù)入賬的準(zhǔn)確性。我實(shí)測下來的數(shù)據(jù)是送貨單字段級準(zhǔn)確率從最初的86%提升到92%之后配合人工抽檢錄入效率能提升70%左右。財(cái)務(wù)團(tuán)隊(duì)從三個(gè)人埋頭錄發(fā)票縮減到每天花半小時(shí)處理異常單據(jù)。2.2 跨系統(tǒng)主數(shù)據(jù)同步與智能補(bǔ)全重復(fù)錄入的另一大來源是主數(shù)據(jù)不一致。比如同一家客戶“深圳市華信電子有限公司”在業(yè)務(wù)員的Excel里叫“華信電子深圳”在ERP里叫“深圳華信電子股份公司”到了財(cái)務(wù)系統(tǒng)里又叫“華信電子”。沒有統(tǒng)一的主數(shù)據(jù)每次錄單都要人去判斷是不是同一個(gè)客戶。AI中臺就在這里承擔(dān)了主數(shù)據(jù)清洗和智能映射的職責(zé)。我們把各系統(tǒng)的客戶檔案、供應(yīng)商檔案、商品檔案匯到一起用相似度算法做聚類識別出同一實(shí)體的不同叫法。規(guī)則考慮三方面文本相似度如編輯距離和Jaccard相似度、關(guān)鍵字段匹配統(tǒng)一社會(huì)信用代碼、電話、地址、以及人工審核反饋的種子數(shù)據(jù)。剛開始時(shí)我們只對供應(yīng)商進(jìn)行主數(shù)據(jù)清洗因?yàn)楣?yīng)商數(shù)量少只有400多家人工核對一遍也不難。清洗完成后每當(dāng)新單據(jù)進(jìn)來系統(tǒng)就能智能判斷它屬于已有供應(yīng)商還是新供應(yīng)商并把規(guī)范化后的名稱自動(dòng)填入各系統(tǒng)。這一步做完的效果很明顯——同一供應(yīng)商的三條不同記錄被合并成一條后續(xù)的采購對賬、供應(yīng)商往來核銷再也不用靠“肉眼搜索”了。2.3 移動(dòng)報(bào)銷場景的“拍照即錄入”員工的報(bào)銷單也是錄入重災(zāi)區(qū)。過去員工貼票、填單財(cái)務(wù)審票、錄系統(tǒng)一張差旅發(fā)票要經(jīng)過三四個(gè)人手里?,F(xiàn)在我們在企業(yè)微信上接入了一個(gè)報(bào)銷入口員工拍下發(fā)票照片AI中臺自動(dòng)完成識別、驗(yàn)真、防重復(fù)報(bào)銷檢查然后把結(jié)構(gòu)化數(shù)據(jù)推送到財(cái)務(wù)系統(tǒng)生成報(bào)銷單。這個(gè)場景的獨(dú)特之處在于使用人群是全員操作必須極簡。我們對員工端的界面做了最大程度簡化拍一張照、填一個(gè)事由、選一個(gè)部門其他都交給系統(tǒng)。對財(cái)務(wù)端則隱藏了大部分信息只展示關(guān)鍵字段和異常提醒。防重復(fù)報(bào)銷是這里的核心功能。做法是建立發(fā)票代碼 號碼的唯一索引每次新報(bào)銷進(jìn)來先在庫里查一遍對同一金額、同一日期、同一賣方的發(fā)票再做一個(gè)模糊匹配攔截“修改金額后再貼票”這種作弊手段。上線以來確實(shí)攔住了幾筆有嫌疑的重復(fù)報(bào)銷這在以前靠人工是幾乎不可能發(fā)現(xiàn)的。3. 怎么把對賬從“人工大海撈針”變成“機(jī)器自動(dòng)配對”3.1 對賬難的本質(zhì)口徑不一致和數(shù)據(jù)延遲對賬之所以難本質(zhì)是三件事。一是時(shí)間差銀行的入賬時(shí)間、我們的開票時(shí)間、客戶確認(rèn)時(shí)間三個(gè)時(shí)間節(jié)點(diǎn)經(jīng)常不一致。二是口徑差比如財(cái)務(wù)以為一筆款項(xiàng)對應(yīng)一張發(fā)票但客戶打款時(shí)備注的是訂單號甚至什么都不備注。三是數(shù)據(jù)孤立銀行流水在網(wǎng)銀系統(tǒng)里銷售數(shù)據(jù)在ERP里發(fā)票在稅務(wù)系統(tǒng)里中間缺一個(gè)自動(dòng)連接的樞紐。以前財(cái)務(wù)對賬就是把銀行流水的Excel導(dǎo)出來再打開ERP的應(yīng)收款明細(xì)兩邊人工找對應(yīng)關(guān)系。具體做法就是靠CtrlF搜索金額再核對打款方名稱。碰上客戶多筆款合并支付、部分付款、折扣退款那就更難了。有時(shí)候?qū)Φ絻裳郯l(fā)花實(shí)在對不上的就扔在一邊攢到年底一起調(diào)整。輕型AI中臺在這里扮演的是一個(gè)“智能樞紐”。它定時(shí)從網(wǎng)銀系統(tǒng)、ERP、發(fā)票系統(tǒng)抽取數(shù)據(jù)統(tǒng)一清洗成標(biāo)準(zhǔn)結(jié)構(gòu)然后用匹配算法自動(dòng)建立銀行流水和應(yīng)收單據(jù)的對應(yīng)關(guān)系。對上的自動(dòng)標(biāo)記核銷對不上的進(jìn)入異常池。3.2 規(guī)則引擎 相似度匹配的雙層方案自動(dòng)匹配的對賬核心我用的是“強(qiáng)規(guī)則 弱匹配”的雙層方案。強(qiáng)規(guī)則是精確匹配也叫硬匹配。比如銀行流水中的憑證號或者是打款備注里包含發(fā)票號碼且金額完全一致這種直接自動(dòng)核銷可靠率極高。弱匹配是模糊匹配適合打款備注不完整或完全無備注的情況。弱匹配的設(shè)計(jì)要謹(jǐn)慎。我的實(shí)現(xiàn)思路是先把銀行流水的收款方名稱解碼成標(biāo)準(zhǔn)化實(shí)體名再和應(yīng)收單上的客戶名做相似度計(jì)算。同時(shí)金額上允許±0.01的誤差因?yàn)橛袝r(shí)會(huì)有手續(xù)費(fèi)拆分時(shí)間上設(shè)定一個(gè)寬松窗口比如開票后90天內(nèi)打款都算有效。綜合相似度超過設(shè)定閾值就進(jìn)入“建議匹配”隊(duì)列由財(cái)務(wù)一鍵確認(rèn)。這里的關(guān)鍵是不要追求100%全自動(dòng)。AI的價(jià)值是幫你處理那90%的常規(guī)情況把財(cái)務(wù)的精力釋放出來處理棘手的10%。如果強(qiáng)行提高自動(dòng)匹配率必然引入匹配錯(cuò)誤到時(shí)候返工的成本遠(yuǎn)高于人工核對。我把規(guī)則設(shè)置成一個(gè)滑動(dòng)閾值剛上線時(shí)閾值調(diào)高保證準(zhǔn)確率優(yōu)先跑了一兩個(gè)季度后對匹配質(zhì)量有信心了再把閾值適當(dāng)調(diào)低擴(kuò)大自動(dòng)化面。一個(gè)容易踩的坑是數(shù)據(jù)質(zhì)量問題。銀行流水導(dǎo)出來經(jīng)常有亂碼、空行、前后空格ERP導(dǎo)出的Excel則存在日期格式不統(tǒng)一、數(shù)字被存成文本等問題。這些臟數(shù)據(jù)不洗干凈再聰明的算法也白搭。我的做法是在中臺里寫一套標(biāo)準(zhǔn)化清洗管道針對每個(gè)數(shù)據(jù)源做定制清洗規(guī)則并在入庫前跑數(shù)據(jù)質(zhì)量檢查。3.3 異常賬項(xiàng)的處理閉環(huán)對賬真正體現(xiàn)水平的地方在于異常處理。不管規(guī)則怎么調(diào)總會(huì)有一些賬對不上。過去這些異常依賴有經(jīng)驗(yàn)的會(huì)計(jì)憑記憶判斷人一離職就全斷了。AI中臺的異常處理閉環(huán)是把這套經(jīng)驗(yàn)結(jié)構(gòu)化。我的做法是給每筆異常賬項(xiàng)建立一個(gè)“處理工單”分為幾類比如“金額一致但時(shí)間超窗”、“金額不一致但相似度高”、“完全無法匹配”、“重復(fù)匹配”等。系統(tǒng)根據(jù)類型自動(dòng)推薦處理策略如沖銷、合并、暫掛或人工介入。每筆異常處理都記錄操作日志、處理人、時(shí)間和最終結(jié)果形成完整的審計(jì)鏈條。這套閉環(huán)跑通后財(cái)務(wù)再也不用月底突擊式對賬了。每天定時(shí)任務(wù)跑一遍當(dāng)日流水異常池慢慢積攢著平時(shí)有空處理幾單月底結(jié)算自然就平了。我們做季度對賬時(shí)過去要整整三天現(xiàn)在半天就能清完剩下的時(shí)間用來分析應(yīng)收賬齡和壞賬風(fēng)險(xiǎn)。4. 從部署到落地的完整實(shí)操路徑4.1 第一步最小化可行的范圍選擇如果你也想做一套類似的輕型AI中臺我強(qiáng)烈建議不要一開始就想覆蓋所有業(yè)務(wù)線。我吃過這個(gè)虧最初方案設(shè)計(jì)時(shí)財(cái)務(wù)老總要求把采購、銷售、庫存、資金全流程都接進(jìn)來結(jié)果項(xiàng)目鋪得太大三個(gè)月都沒上線。后來我砍掉大部分場景只保留“發(fā)票識別 采購入庫 對賬匹配”三個(gè)模塊一個(gè)半月就上了生產(chǎn)環(huán)境。最小化可行范圍的選擇標(biāo)準(zhǔn)有三條。第一高頻每天都有大量重復(fù)勞動(dòng)的場景第二痛點(diǎn)強(qiáng)手工處理容易出錯(cuò)、代價(jià)高的場景第三數(shù)據(jù)條件好已經(jīng)有結(jié)構(gòu)化數(shù)據(jù)基礎(chǔ)或者數(shù)據(jù)源便于接入的場景。每次擴(kuò)展新場景前先問這三個(gè)問題過了再上。在這個(gè)階段就要明確項(xiàng)目目標(biāo)和驗(yàn)收指標(biāo)。目標(biāo)盡量定量比如“發(fā)票錄入時(shí)間從平均5分鐘縮短到1分鐘以內(nèi)”“月度對賬時(shí)間從3天縮短到0.5天”“重復(fù)錄入率下降80%”。沒有定量目標(biāo)后面推動(dòng)業(yè)務(wù)部門配合會(huì)非常艱難。4.2 第二步數(shù)據(jù)采集層的搭建與模型微調(diào)數(shù)據(jù)采集層決定了AI中臺的“視力”和“聽力”。主要工作包括三塊OCR識別服務(wù)部署、各業(yè)務(wù)系統(tǒng)數(shù)據(jù)接口對接、以及數(shù)據(jù)標(biāo)準(zhǔn)化管道建設(shè)。OCR服務(wù)我選了本地方案部署在一臺帶GPU的服務(wù)器上。國產(chǎn)化和開源的模型里我測試過幾款結(jié)論是單張識別效果差距不大但表格結(jié)構(gòu)還原能力差異明顯。發(fā)票、送貨單這類有邊框的表格單據(jù)用帶表格還原能力的模型效果更好。模型部署后用我們自己的歷史單據(jù)做微調(diào)準(zhǔn)備大概300到500張有代表性的樣本標(biāo)注后訓(xùn)練一輪字段準(zhǔn)確率能提高四到六個(gè)百分點(diǎn)。數(shù)據(jù)接口對接這塊優(yōu)先走API。沒有API的系統(tǒng)采用定時(shí)數(shù)據(jù)庫視圖同步。我給每個(gè)系統(tǒng)都建了只讀賬號提供專用的視圖供中臺查詢數(shù)據(jù)避免給AI中臺過高的數(shù)據(jù)庫權(quán)限這樣既穩(wěn)定又安全。標(biāo)準(zhǔn)化管道分為四步抽取、清洗、映射、加載。清洗是最費(fèi)時(shí)的要處理字段前后空格、全半角字符、日期格式、金額千分位符號等。我寫了一個(gè)通用清洗函數(shù)庫根據(jù)不同字段類型調(diào)用不同規(guī)則。加載時(shí)寫入統(tǒng)一的貼源層表之后再根據(jù)業(yè)務(wù)邏輯轉(zhuǎn)換到模型層。4.3 第三步業(yè)務(wù)流程改造與用戶觸達(dá)技術(shù)部署只占整個(gè)項(xiàng)目的一半另一半是流程改造和用戶習(xí)慣的培養(yǎng)。這是真正的難點(diǎn)因?yàn)锳I中臺改變了原有的人工操作習(xí)慣總有人覺得系統(tǒng)不靠譜、還是在旁邊放個(gè)Excel安心。流程改造的關(guān)鍵是讓AI融入原有工作流而不是額外增加操作。比如倉庫收貨原來是“手工錄一張入庫單”改成“拍一張照系統(tǒng)自動(dòng)生成草稿人看一眼確認(rèn)”。雖然還是要操作一下但輸入成本低多了。這個(gè)改動(dòng)讓倉管員很樂意接受。用戶觸達(dá)上要有耐心。我組織了三次全員培訓(xùn)核心不是教操作方法而是解釋為什么這么做以及哪些環(huán)節(jié)還需要人工參與。尤其要消除“AI會(huì)全面取代我”的焦慮明確告訴團(tuán)隊(duì)AI只是一個(gè)輔助工具能把大家從繁瑣的機(jī)械勞動(dòng)中解放出來去做更有價(jià)值的分析和決策。這里我傳授一個(gè)經(jīng)驗(yàn)上線初期一定不要讓用戶填任何多余字段。只要系統(tǒng)里多一個(gè)必填項(xiàng)用戶的反感度就指數(shù)級上升。寧可先在后臺默認(rèn)賦值跑一段再優(yōu)化。4.4 第四步灰度切換與驗(yàn)收標(biāo)準(zhǔn)上線采用灰度切換策略不要一上來就全流程替換。我當(dāng)時(shí)是先把采購入庫場景切到AI流程跑了兩周穩(wěn)定后再接發(fā)票識別。對賬場景則先讓系統(tǒng)“影子運(yùn)行”——也就是AI匹配結(jié)果只做展示不做自動(dòng)核銷財(cái)務(wù)人員按原流程手工對賬同時(shí)把AI的匹配結(jié)果拿來對照。跑了一個(gè)月驗(yàn)證準(zhǔn)確率到了可接受的95%以上才開放自動(dòng)核銷功能。驗(yàn)收指標(biāo)建議分三個(gè)階段。初期看識別率和功能完整度中期看業(yè)務(wù)效率提升和用戶反饋穩(wěn)定期看財(cái)務(wù)差錯(cuò)率和對賬周期。每個(gè)階段都要有明確的數(shù)字目標(biāo)達(dá)不到就回溯調(diào)整不要太早宣布成功。我踩過的坑是選錯(cuò)了驗(yàn)收的樣本時(shí)間。一開始我選了業(yè)務(wù)最繁忙的月底來測試結(jié)果用戶既要處理積壓的單據(jù)又要學(xué)習(xí)新系統(tǒng)體驗(yàn)很差。后來改為月初到中旬的平穩(wěn)期做灰度效果就好多了用戶接受度明顯提升。5. 常見問題與排查技巧實(shí)錄5.1 頁面假死、接口超時(shí)、字段識別率上不去怎么辦實(shí)際運(yùn)行中遇到過不少技術(shù)問題。比較有代表性的有三個(gè)。第一個(gè)是批量導(dǎo)入Excel時(shí)頁面假死。原因是同步處理大數(shù)據(jù)量阻塞了Web請求線程。后來把導(dǎo)入操作改成異步任務(wù)通過WebSocket推送進(jìn)度條用戶不用干等體驗(yàn)好了很多。中間還遇到過Excel里有合并單元格、隱藏行、公式緩存臟數(shù)據(jù)的情況清洗腳本里要專門處理。第二個(gè)是對賬接口在月底高并發(fā)調(diào)用時(shí)經(jīng)常超時(shí)。查下來是網(wǎng)銀系統(tǒng)那邊限流了。我們的對策是加熔斷重試機(jī)制設(shè)置超時(shí)時(shí)間和退避策略同時(shí)在本地緩存當(dāng)天的流水?dāng)?shù)據(jù)避免反復(fù)拉取。月底高峰期錯(cuò)開時(shí)段調(diào)度也能有效規(guī)避限流。第三個(gè)是手寫單據(jù)的識別率上不去。送貨單上供應(yīng)商的簽字、備注區(qū)域常有手寫內(nèi)容和印刷內(nèi)容混雜的情況。試過換模型、調(diào)顏色模式、做圖像預(yù)處理提升很有限。最終方案是把手寫區(qū)域單獨(dú)切出來做手寫體識別模型或者干脆讓倉管員在關(guān)鍵字段下拉選擇不要手寫。這個(gè)經(jīng)驗(yàn)是不要跟OCR死磕流程上避開它的短板才是最有效的方案。5.2 數(shù)據(jù)權(quán)限與審計(jì)合規(guī)的落地細(xì)節(jié)AI中臺動(dòng)了財(cái)務(wù)的敏感數(shù)據(jù)權(quán)限和審計(jì)一定要早做不能等出問題再補(bǔ)。我在設(shè)計(jì)時(shí)遵循了“角色-數(shù)據(jù)域-操作類型”三層權(quán)限模型。角色決定能看到哪些模塊數(shù)據(jù)域決定能看到哪些公司的數(shù)據(jù)操作類型決定能執(zhí)行查看、修改還是刪除。操作審計(jì)方面所有AI自動(dòng)完成的動(dòng)作都打上了system_ai的標(biāo)記方便追溯。每筆自動(dòng)核銷都會(huì)生成審計(jì)記錄包括流水ID、應(yīng)收單ID、匹配算法版本、匹配分?jǐn)?shù)、執(zhí)行時(shí)間。萬一出了錯(cuò)可以直接定位是哪條規(guī)則導(dǎo)致的不至于無從查起。審計(jì)日志的存儲也要考慮默認(rèn)保留三年。日志量一天大概幾十萬條建議按月分表存儲定期歸檔冷備。同時(shí)設(shè)置定期完整性校驗(yàn)任務(wù)防止日志被篡改。5.3 一張識別率提升的“排查對照表”下面這張表是根據(jù)實(shí)踐整理的常見識別不穩(wěn)定問題的處理方向可以直接照著排查。問題現(xiàn)象可能原因處理建議發(fā)票號碼識別錯(cuò)位發(fā)票布局旋轉(zhuǎn)、暗紋干擾增加圖像糾偏預(yù)處理訓(xùn)練時(shí)加入旋轉(zhuǎn)樣本表格線斷裂導(dǎo)致漏識別掃描件、壓線邊緣啟動(dòng)表格還原增強(qiáng)或調(diào)整二值化閾值同一字段中的中文夾雜英文供應(yīng)商名稱、城市名稱帶縮寫建立常用詞詞典識別后做規(guī)范化替換金額小數(shù)點(diǎn)和千分位混淆發(fā)票打印不清晰采用金額正則上下文校驗(yàn)識別后二次修正日期格式混亂各單據(jù)日期格式不一致統(tǒng)一解析為年月日標(biāo)準(zhǔn)格式清洗時(shí)做強(qiáng)校驗(yàn)多頁P(yáng)DF只識別了首頁分頁參數(shù)未正確配置檢查OCR服務(wù)的分頁開關(guān)和文檔轉(zhuǎn)換引擎相同發(fā)票被重復(fù)錄入多人同時(shí)提交增加唯一索引提交前實(shí)時(shí)去重查詢對賬建議匹配錯(cuò)誤相似度閾值設(shè)置過低降低自動(dòng)核銷量級提高閾值并補(bǔ)充人工復(fù)核排查問題的時(shí)候記得給自己的系統(tǒng)加一個(gè)“場景回放”功能。把每次處理的輸入輸出都留痕出了問題能直接回放當(dāng)時(shí)的條件和結(jié)果比拍腦袋猜測原因有效得多。最后再分享一點(diǎn)體會(huì)這套輕型AI中臺建設(shè)下來我個(gè)人最大的體會(huì)是AI在企業(yè)的落地難點(diǎn)從來不在技術(shù)本身而在于對業(yè)務(wù)流程的理解和改造。整個(gè)過程中最耗費(fèi)精力的不是模型調(diào)優(yōu)而是理解財(cái)務(wù)到底怎么對賬、倉庫到底怎么收貨、為什么會(huì)出現(xiàn)這么多不一致的數(shù)據(jù)。只有把這些問題吃透了技術(shù)方案才能真正見效。另一個(gè)建議是如果團(tuán)隊(duì)沒有專職的AI工程師優(yōu)先找成熟方案和開源的組件拼裝。不要迷信“自主大模型”能用規(guī)則解決的就不要上模型能讓機(jī)器判斷的精確匹配就不要引入概率匹配。AI中臺的核心目標(biāo)永遠(yuǎn)是提效降本而不是為了炫技。最后提醒一句這項(xiàng)建設(shè)不是一次性項(xiàng)目而是一個(gè)持續(xù)運(yùn)營的過程。每季度要根據(jù)實(shí)際運(yùn)行數(shù)據(jù)回頭調(diào)整規(guī)則閾值和識別模型。隨著業(yè)務(wù)的發(fā)展新出現(xiàn)的單據(jù)類型、新的打款方式都需要逐步納入中臺管理。但只要你把底子打好后面的擴(kuò)展會(huì)越來越順財(cái)務(wù)團(tuán)隊(duì)和業(yè)務(wù)團(tuán)隊(duì)都愿意主動(dòng)提需求。我現(xiàn)在的目標(biāo)是把這套中臺的能力擴(kuò)展到供應(yīng)商對賬和生產(chǎn)成本核算中去讓數(shù)據(jù)驅(qū)動(dòng)的賬務(wù)管理覆蓋更多環(huán)節(jié)。