Google хэрхэн AI ашиглан төлбөрийн нэхэмжлэхээ автоматжуулж байна вэ?

Дэлхийн хэмжээнд үйл ажиллагаа явуулдаг томоохон корпорациудын хувьд нэхэмжлэх боловсруулалт нь маш их хүн хүч, цаг хугацаа шаардсан үйл явц байдаг. Google компани жил бүр дэлхийн өнцөг булан бүрээс, олон зуун мянган харилцагчдаас, төрөл бүрийн хэл дээр бичигдсэн, өөр өөр форматтай сая сая нэхэмжлэх хүлээн авдаг. Энэхүү нүсэр үйл явцыг уламжлалт OCR (Optical Character Recognition) технологиор шийдвэрлэх боломжгүй бөгөөд загвар дээр суурилсан (template-based) шийдэл нь урт хугацаанд тогтвортой ажиллаж чаддаггүй.

Энэ нийтлэлээр бид Google дотоод үйл ажиллагаандаа хиймэл оюун ухаан (AI) болон LLM ашиглан нэхэмжлэхийг хэрхэн автоматаар уншиж, ойлгож, баталгаажуулж байгаа техникийн архитектур, шийдвэр гаргагчдад зориулсан үнэлгээний шалгуурууд болон инженерийн багуудын анхаарах ёстой эрсдэлүүдийн талаар гүнзгийрүүлэн авч үзэх болно. Энэхүү туршлага нь зөвхөн Google гэлтгүй, санхүүгийн үйл ажиллагаагаа оновчлохыг зорьж буй CTO, технологийн багийнханд өөрийн байгууллагад тохирох системийг загварчлахад чухал суурь болох юм.

Үндсэн механизм ба өгөгдөл олборлолт

Нэхэмжлэх боловсруулах үйл явцын цөм нь бүтэцгүй (unstructured) эсвэл хагас бүтэцлэгдсэн (semi-structured) баримт бичгээс бүтэцлэгдсэн өгөгдөл (structured data) гаргаж авах явдал юм. Уламжлалт аргаар бол баримтын тодорхой хэсэгт байрлах координатыг зааж өгөн уншуулдаг байсан бол орчин үеийн AI технологи нь хүн шиг контекстийг ойлгож уншдаг болсон.

Google-ийн дотоод систем нь дараах үндсэн үе шаттайгаар ажилладаг:

1. Оруулах ба урьдчилсан боловсруулалт (Ingestion & Pre-processing): И-мэйл, портал эсвэл API-аар орж ирсэн PDF болон зургийн файлуудыг хүлээн авч, чанарыг сайжруулах, цэвэрлэх үйлдлүүдийг хийнэ.
2. AI өгөгдөл гаргаж авах (AI Data Extraction): Энэ шатанд компьютерийн хараа (Computer Vision) болон Natural Language Processing хосолсон загваруудыг ашигладаг. Систем нь нийлүүлэгчийн нэр, нэхэмжлэхийн дугаар, огноо, нийт дүн, татвар болон мөр тус бүрийн мэдээллийг гаргаж авдаг. Энэхүү технологийн суурь нь олон нийтэд нээлттэй байдаг Google Cloud Document AI үйлчилгээтэй ижил архитектур дээр суурилдаг.
3. Баталгаажуулалт ба Худалдан авалтын тушаалтай тулгах (PO Matching): Зөвхөн өгөгдөл унших нь хангалтгүй. AI-ийн олборлосон мэдээллийг ERP систем дэх (жишээ нь SAP эсвэл Oracle) Худалдан авалтын тушаал (Purchase Order) болон Хүлээн авсан баримттай (Goods Receipt) тулгах 3 талт тулгалт хийнэ.

AI загвар нь баримтаас олборлосон мэдээлэл бүр дээрээ Confidence score гаргадаг. Энэ оноо нь дараагийн алхамд хүний оролцоо шаардлагатай эсэхийг шийдвэрлэх гол хэмжүүр болдог.

Архитектурын загвар ба системүүдийн интеграци

Аливаа байгууллагад AI нэвтрүүлэхэд хамгийн хэцүү хэсэг нь загварыг сургах бус, харин түүнийг одоо байгаа бизнесийн процессуудтай холбох (integration) байдаг. Google-ийн хувьд нэхэмжлэх боловсруулах систем нь микросервис архитектур болон эвентд суурилсан (Event-driven) загварыг ашигладаг.

Хүний оролцоотой архитектур (Human-in-the-Loop эсвэл HITL)

Хиймэл оюун ухаан хэзээ ч 100% алдаагүй ажилладаггүй. Санхүүгийн үйл ажиллагаанд 1 долларын зөрүү ч ноцтой асуудал үүсгэдэг тул архитектурын дизайнд эрсдэлээс хамгаалах давхарга заавал байх шаардлагатай.

• Шууд боловсруулалт (Straight-Through Processing - STP): Хэрэв AI-ийн итгэлцлийн оноо маш өндөр (жишээ нь > 95%) бөгөөд ERP систем дэх PO-той бүх мэдээлэл болон дүн яг таарч байвал нэхэмжлэх шууд төлбөр рүү шилжинэ. Ямар ч хүний оролцоо шаардахгүй.
• Онцгой тохиолдлын удирдлага (Exception Handling): Хэрэв итгэлцлийн оноо босго дүнгээс бага (жишээ нь < 85%), эсвэл мэдээлэл хоорондоо зөрүүтэй (жишээ нь нэхэмжилсэн дүн PO-ийн дүнгээс өндөр) байвал уг баримтыг санхүүгийн мэргэжилтний хяналт руу илгээнэ. Мэргэжилтэн алдааг зассанаар систем уг мэдээллийг хүлээн авч, дараагийн удаа ижил төстэй баримт дээр илүү сайн ажиллахын тулд загварыг давхар сургахад (continuous learning) ашигладаг.

Технологийн стек ба урсгал

Инженерийн үүднээс харвал урсгал дараах байдалтай байна:

1. Cloud Storage-д баримт орох үед Pub/Sub trigger ажиллана.
2. Serverless функц эсвэл контейнер (Cloud Run) ажиллаж, Document AI руу API дуудлага хийнэ.
3. JSON өгөгдлийг баталгаажуулах бизнесийн логикийг шалгана (үнэ x тоо ширхэг = нийт дүн эсэхийг бүрэн шалгах).
4. Баталгаажсан өгөгдлийг интеграцийн давхаргаар дамжуулан үндсэн ERP систем рүү бичнэ. Хяналт шаардлагатайг нь тусгай вэб интерфэйс рүү илгээнэ.

Бизнесийн хэрэглээ

AI-д суурилсан баталгаажуулалтын систем нь бүх төрлийн нэхэмжлэх дээр ижил үр дүнтэй ажилладаггүй. Процессын үр ашиг нь нэхэмжлэхийн нарийн төвөгтэй байдлаас шууд хамаарна.

• Энгийн, өндөр давтамжтай нэхэмжлэх (SaaS захиалга, тээвэр, хангамж): Эдгээр нь ихэвчлэн цөөн хуудастай, мэдээллийн бүтэц ойлгомжтой байдаг. Энэ төрөл дээр AI системийн STP (Шууд боловсруулалт) түвшин 80-90%-д хүрэх боломжтой бөгөөд үйл ажиллагааны зардлыг үлэмж хэмжээгээр бууруулдаг.
• Олон хуудастай, нарийн нийлмэл үйлчилгээний нэхэмжлэх (Хуулийн үйлчилгээ, барилга угсралт): 50 хуудас үргэлжлэх, дотроо төсөл тус бүрээр задалсан тайлантай нэхэмжлэх дээр уламжлалт AI загварууд сааталд ордог. Ийм үед хуудас тус бүрийг салгаж ойлгодог LLM илүү сайн ажилладаг боловч боловсруулалтын өртөг болон зарцуулах хугацаа нэмэгддэг.

Дэлхийн хэмжээнд үйл ажиллагаа явуулдаг компанийн хувьд өөр нэг том сорилт бол хэл болон татварын хууль тогтоомжийн олон янз байдал юм. Япон эсвэл Солонгос хэл дээрх баримтыг англи хэлний загвараар уншуулах боломжгүй бөгөөд Олон хэлний дэмжлэгтэй AI архитектур ашиглах нь системийн уян хатан байдлыг тодорхойлогч гол хүчин зүйл болдог.

Эрсдэл, сул тал болон хязгаарлалтууд

Технологийн багийнхан AI шийдлийг нэвтрүүлэхдээ түүний сул тал, эрсдэлийг бодитоор үнэлэх нь чухал. Энэ төрлийн системд дараах нийтлэг хязгаарлалтууд гардаг.

• Хиймэл оюуны төөрөгдөл (Hallucinations): LLM заримдаа байхгүй тоог зохиож бичих эсвэл бүдэг хэвлэгдсэн '8' тоог '3' гэж андуурах эрсдэлтэй. Санхүүгийн бүртгэлд энэ нь маш аюултай тул AI-ийн гаргасан тоон мэдээллийг заавал математик дүрмийн шалгагчтай (Rule-based validation) хослуулах ёстой.
• API өртөг ба дэд бүтцийн зардал: Нэг хуудас нэхэмжлэхийг параметр өндөртэй LLM загвар (жишээ нь Gemini Pro) ашиглан боловсруулах нь уламжлалт OCR ашиглахаас хэд дахин илүү өртөгтэй байж болно. Тиймээс систем нь баримтын хэлбэрээс хамааран хөнгөн эсвэл хүнд загвар руу чиглүүлдэг intelligent routing ашиглах хэрэгтэй.
• Өгөгдлийн нууцлал ба аюулгүй байдал: Нэхэмжлэх нь байгууллагын худалдан авалтын стратеги, үнийн мэдээлэл болон харилцагчдын банкны дансны мэдээллийг агуулдаг. Нээлттэй API ашиглан 3-дагч талын AI руу өгөгдлөө илгээх нь хуулийн комплаенс (жишээ нь GDPR, SOC2) зөрчих эрсдэлтэй тул дотоод системдээ эсвэл виртуал хувийн үүлэн орчинд (VPC) тусгаарлагдсан загвар ашиглах нь зайлшгүй шаардлагатай.

Технологийн сонголт хийх шалгуурууд

CTO болон инженерийн багууд өөрсдийн орчинд AI нэхэмжлэх боловсруулах систем нэвтрүүлэхдээ Build vs Buy (Өөрсдөө бүтээх үү, бэлэн үйлчилгээ авах уу) гэсэн шийдвэртэй нүүр тулдаг. Доорх харьцуулалт танд туслах болно.

Уламжлалт OCR + Template engine

• Хэзээ ашиглах: Нэхэмжлэх илгээдэг харилцагчдын тоо цөөн (10-20), форматыг хянах боломжтой үед.
• Сул тал: Харилцагч бүр дээр шинэ загвар (template) зурах шаардлагатай, үйл ажиллагаа томрох тусам засвар үйлчилгээ хэцүү болно.

Урьдчилан сургасан Document AI ( Procurement DocAI)

• Хэзээ ашиглах: Олон зуун өөр төрлийн харилцагчтай, нэмэлт хөгжүүлэлт бага хийж хурдан нэвтрүүлэхийг зорьж буй үед.
• Давуу тал: Сургалтын дата шаардахгүй, стандарт талбаруудыг (огноо, дүн, нэр) шууд танина.

LLM суурьтай шийдэл

• Хэзээ ашиглах: Маш нарийн төвөгтэй, олон хуудастай баримтаас контекст ухаж ойлгох шаардлагатай үед.
• Анхаарах зүйл: Зардал өндөр, хариу өгөх хугацаа (latency) удаан.

Инженерийн багуудын гаргадаг түгээмэл алдаанууд

AI төслийг хэрэгжүүлэх явцад компаниуд дараах алдаануудыг түгээмэл гаргадаг бөгөөд ноцтой багууд эдгээрээс хэрхэн зайлсхийдгийг анхаарах нь зүйтэй.

• Хүнийг шууд 100% орлох гэж оролдох: AI-г нэвтрүүлэх эхний өдрөөс л бүх зүйлийг автоматжуулах гэж оролдох нь төслийг бүтэлгүйтэлд хүргэдэг. Зөв хандлага бол эхлээд AI-ийг зөвхөн хүнд туслах хэрэгсэл (co-pilot) болгон ашиглаж, өгөгдөл давхар оруулах процессыг хөнгөвчилж, систем хангалттай дата цуглуулсны дараа шат дараатайгаар бүрэн автоматжуулах явдал юм.
• Чанар муутай оролтын өгөгдлийг үл тоомсорлох: Буруу сканнердсан, бүдгэрсэн, үрчийсэн цаасны зураг оруулчихаад AI-аас гайхамшиг хүлээх хэрэггүй. Урьдчилсан боловсруулалт хийх (Image enhancement pipeline) нь AI олборлолтоос дутахгүй чухал.
• Програм хангамжийн инженерийн сахилга батыг орхих: AI багц (prompt) болон итгэлцлийн босго оноог дур мэдэн өөрчлөх нь системийн тогтвортой байдлыг алдагдуулдаг. Prompt болон загварын тохиргоонууд яг л код шиг version control болон CI/CD урсгалаар дамжиж тестлэх ёстой.
• AI-ийн гаргасан тоонд сохроор итгэх: Дээр дурдсанчлан заавал бизнесийн логикоор шалгах шатлал байх ёстой. AI-ийн таньсан татварын дүн болон цэвэр дүнгийн нийлбэр нь нийт дүнтэй тэнцүү байгаа эсэхийг баталгаажуулах энгийн код бичихгүй байх нь маш том алдаа юм.

Гол санаанууд ба хэрэгжүүлэлтийн зөвлөмж

Google зэрэг байгууллагууд AI ашиглан нэхэмжлэх боловсруулалтаа автоматжуулж, зардлаа үлэмж хэмжээгээр хэмнэж чадаж байгаагийн нууц нь ердөө л нэг ухаалаг AI загвар олж тавьсанд биш юм. Харин AI загварыг системийн найдвартай байдал, бизнесийн дүрэм болон хүний оролцоотой хэрхэн зөв уялдуулж чадсанд оршино.

Та өөрийн байгууллагад энэ чиглэлийн системийг төлөвлөхдөө дараах зүйлсийг анхаараарай:

• Уламжлалт OCR технологид гацалгүйгээр орчин үеийн Document AI болон LLM хосолсон архитектур руу шилжих нь урт хугацаанд хөгжүүлэлтийн цагийг хэмнэнэ.
• Системийн амжилтын шалгуурыг зөвхөн "AI хэр зэрэг ухаантай вэ" гэдгээр бус, "Шууд боловсруулалтын хувь (STP rate) хэр байна вэ", "Нэг баримт боловсруулах өртөг хэр буурсан бэ" гэдгээр хэмжих.
• Итгэлцлийн оноо (Confidence score) дээр суурилсан ухаалаг чиглүүлэлт болон Хүний оролцоотой (HITL) архитектурыг анхнаас нь системийн дизайнд тусгах.
• Өгөгдлийн нууцлалыг чанд баримталж, нээлттэй API-аас илүү хаалттай, виртуал орчинд ажилладаг загварыг (Private endpoints) сонгох.
• AI-г ид шид мэтээр төсөөлөхгүйгээр, математик болон худалдан авалтын тушаалтай тулгах хатуу логикууд (deterministic rules)-тай заавал хослуулан ашиглах.