让 AI 生产可用的三层模式：AI 提议、确定性逻辑裁决、人工兜底
AI proposes, deterministic logic disposes: the pattern that keeps AI production-ready
一种让 AI 生产可用的三层模式：AI（OCR、语言模型、信息抽取）只负责提议并为每条结果附上置信度分数，绝不直接写数据库；由普通代码构成的确定性业务规则层校验格式、与既有参考数据的一致性和业务阈值，未通过者被拦截；低置信度、违规或未见过的案例进入人工审核队列，人工决策被存储并反馈回系统。模型幻觉由此变成被校验层拒绝的提议，而非流入生产库的错误数据。
TL;DR
- Three layers: AI proposes with a confidence score, deterministic business rules validate, a human settles what is left.
- AI never writes to the database directly. A hallucination becomes a rejected proposal, not wrong data in production.
- The useful question is not which model is used, it is what happens when that model gets it wrong.
AI in production does not decide. It proposes, to a system that has the right to say no. Every AI system I have put into production shares this same three-layer pattern.
The three layers of the pattern
AI proposes. OCR, a language model, extraction: it reads the document or the input data, detects, extracts, and attaches a confidence score to every proposal it makes. It never writes directly to the database.
Business rules validate. A deterministic layer, made of ordinary code, testable and auditable, checks every proposal the AI makes: expected formats, consistency against existing reference data, business thresholds. What passes these checks gets accepted. What fails is blocked before it reaches the system.
A human decides. A confidence score that is too low, a business rule that gets violated, a case never seen before: the proposal goes into a validation queue, and a person decides. Every human decision is stored and fed back into the system, which improves with use this way, without heavy model retraining.
What this pattern actually changes
In this architecture, a model's hallucination is no longer a diffuse, uncontrollable risk. It is an explicitly handled case. An AI that gets something wrong becomes a proposal rejected by the validation layer, never wrong data reaching a production database directly.
This is exactly how the document pipeline I delivered in a demanding industrial context runs day to day. It holds up over time not because the AI never makes a mistake, but because its mistakes structurally have nowhere to go without passing through a check.
A detail that is not really a detail
In a system like this, the part actually occupied by artificial intelligence is small. Everything that makes the system trustworthy comes down to ordinary software engineering: tested .NET code, a structured SQL database, explicit business rules, automated tests. That is what I build in a .NET AI integration: AI inside the existing code, under its rules.
The question worth asking
I am often asked which model I use for a given project. That is almost never the most useful question. The question that actually matters is: what happens when this AI gets it wrong? Sometimes the answer allows full automation, as on the Convention Online AI chain, where a mistake is fixed on the next pass. If the answer is not clear before the first deployment, the system is not yet ready for production.
Originally published on gilabs.fr.
I'm Yann Gilliot, founder of GiLabs. GiLabs helps SMEs, mid-caps and professional firms succeed in their AI transformation: process mapping, a costed roadmap, then building the agents and applications that run in production, wired into what you already have.
来源：Google AI：DEV 作者专属（RSS） · dev.to