Хэрэглэгчийн туслахыг хиймэл оюун ашиглаж бизнесдээ хөгжүүлэх нь

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

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

Хиймэл оюунд суурилсан туслах

Уламжлалт чатботууд нь урьдчилан тодорхойлсон дүрмийн мод (decision tree) дээр суурилдаг тул хэрэглэгчийн асуудал бага зэрэг өөрчлөгдөхөд л гацаанд ордог. Харин орчин үеийн LLM-д суурилсан хиймэл оюунт туслах нь агуулгыг ойлгож, динамикаар хариулах чадвартай.

Гэхдээ байгууллагын түвшинд зөвхөн LLM ашиглах нь хангалтгүй бөгөөд дараах хоёр үндсэн механизмыг хослуулах шаардлагатай болдог.

1. Retrieval-Augmented Generation (RAG) буюу Мэдээлэл татаж баяжуулах: LLM нь өөрийн сургагдсан хуучин мэдээллээр бус, харин тухайн байгууллагын дотоод мэдээллийн сангаас (гарын авлага, дүрэм журам, хэрэглэгчийн түүх) хайлт хийж, олдсон мэдээлэлд үндэслэн хариулт боловсруулах үйл явц юм. Энэ нь хуурмаг хариулт (hallucination) өгөх эрсдэлийг эрс бууруулдаг.
   
2. Tool Calling буюу Үйлдэл гүйцэтгэх чадвар: Хэрэглэгчийн асуултад зөвхөн хариулаад зогсохгүй, API ашиглан CRM системээс мэдээлэл шалгах, төлбөрийн системд буцаалт хийх, эсвэл тикет үүсгэх зэрэг бодит үйлдэл хийх чадварыг хэлнэ.

Эдгээрийг нэгтгэснээр хэрэглэгчийн туслах нь зүгээр нэг "мэдээллийн лавлах" биш, харин тодорхой хэмжээнд бие даан шийдвэр гаргаж, ажлын урсгалыг автоматжуулах (workflow automation) жинхэнэ туслах болж хувирдаг.

Архитектур ба үйл ажиллагааны загвар: Google-ийн туршлага

Google өөрийн бүтээгдэхүүнүүд болон үйлчилгээндээ AI-ийг нэвтрүүлэхдээ аюулгүй байдал, өргөтгөх боломж (scalability) болон үнэн зөв байдлыг нэн тэргүүнд тавьдаг. Тэдний архитектурын гол цөм нь хэрэглэгчийн хүсэлт, өгөгдлийн сан, хиймэл оюуны загвар хоорондын урсгалыг нарийн зохион байгуулахад оршдог. Энэхүү хандлагыг Google Cloud-ийн Contact Center AI архитектурын жишээ зэрэг нээлттэй эх сурвалжуудаас харж болно.

Практик хэрэгжүүлэлтийн архитектур нь ихэвчлэн дараах давхаргуудаас бүрдэнэ:

1. Хүсэлт хүлээн авах ба чиглүүлэх давхарга (Orchestration Layer)

Хэрэглэгчээс ирсэн мессежийг хамгийн түрүүнд хүлээн авч, тухайн хүсэлтийн зорилгыг (intent) тодорхойлно. Хэрэв маш энгийн асуулт байвал шууд RAG систем рүү, харин үйлдэл шаардсан хүсэлт байвал тохирох API рүү чиглүүлэх шийдвэрийг orchestrator гаргана.

2. Өгөгдөлд тулгуурлах буюу Grounding

Google-ийн хамгийн их анхаардаг зүйлсийн нэг бол Grounding юм. Энэ нь LLM-ийн хариултыг заавал баталгаат эх сурвалжтай холбох үйл явц бөгөөд Vertex AI-ийн Grounding механизм нь үүний тод жишээ юм. Байгууллагууд өөрийн вектор өгөгдлийн сан (Vector Database) эсвэл дотоод хайлтын системийг ашиглан LLM-ийг зөвхөн тухайн контентын хүрээнд хариулахыг албаддаг.

3. Хүн-системийн хамтын ажиллагаа (Human-in-the-loop)

Бүрэн бие даасан AI нь эрсдэлтэй байдаг тул системийн архитектурт заавал "Хүн рүү шилжүүлэх" (Human Escalation) замыг тусгадаг. Жишээлбэл, хэрэглэгчийн сэтгэл ханамж огцом унах, эсвэл AI тодорхой бус байдалд орох үед бүх харилцан ярианы түүхийн хамт амьд оператор руу шилжүүлдэг.

Бодит хэрэглээ ба нийтлэг ашиглалт

AI туслахыг хаана ашиглах нь таны бизнесийн салбараас үл хамааран дараах нийтлэг ашиглалтын тохиолдлуудад (use cases) хамгийн өндөр үр өгөөжтэй байдаг.

• Техникийн үйлчилгээний анхан шатны шийдвэрлэлт (L1 Support Triage): Хэрэглэгчээс ирсэн алдааны мэдээллийг хүлээн авч, лог файл унших, алдааны кодыг дотоод Confluence эсвэл Jira сангаас хайж, шийдэх боломжтой бол зааварчилгаа өгөх, боломжгүй бол хэрэгцээт бүх мэдээллийг цуглуулан L2 инженер рүү тикет үүсгэн илгээх.
• Цахим худалдааны захиалга, буцаалтын удирдлага: Хэрэглэгч "Миний захиалга хаана байна?" гэж асуухад AI нь шууд ERP/Ложистикийн системтэй API-аар холбогдож төлөвийг шалгах, мөн буцаалтын нөхцөлийг шалган баталгаажуулах.
• B2B харилцагчийн үйлчилгээ ба Account Management: Байгууллагын харилцагчдад зориулсан үйлчилгээнд AI нь гэрээний нөхцөл, нэхэмжлэхийн түүх, SLA (Service Level Agreement) зэрэг өндөр нарийвчлал шаардсан мэдээллүүдийг тусгай хандалтын эрхийн дагуу татаж авч, хариулах.

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

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

1. Хариу өгөх хурд буюу Latency (TTFB)

LLM ашиглах үед уламжлалт API-тай харьцуулахад хариу өгөх хугацаа (Time To First Token) урт байдаг. Ялангуяа RAG ашиглан вектор сангаас хайлт хийж, мэдээллийг нэгтгэн боловсруулах үед 3-5 секунд хүртэл хугацаа шаардагдах нь хэрэглэгчийн туршлагад (UX) сөргөөр нөлөөлж болзошгүй. Тиймээс streaming хариулт ашиглах, кэш (Semantic Caching) нэвтрүүлэх зэрэг инженерийн шийдлүүд шаардлагатай.

2. Өгөгдлийн аюулгүй байдал ба Хандлагын хяналт (Access Control)

AI туслах нь хэрэглэгч А-ийн мэдээллийг хэрэглэгч Б-д өгөхөөс сэргийлэх ёстой. RAG систем хөгжүүлэх үед өгөгдлийн сан дахь баримт бичиг бүр дээр хандалтын эрхийн хяналтыг (ACL) хэрэгжүүлэх нь технологийн хувьд нэлээд төвөгтэй байдаг. Хэрвээ зөв тохируулахгүй бол өгөгдөл алдагдах маш том эрсдэлтэй.

3. Зардлын өсөлт ба Токен хязгаар

AI туслахын үйл ажиллагааны зардал нь ашиглаж буй LLM загварын токен тутамд тооцогддог. Хэрэглэгчийн урт ярианы түүх, RAG-аас татсан олон хуудас баримт бичгийг загвар руу илгээх бүрт зардал өснө. Тиймээс харилцан ярианы түүхийг хураангуйлах (summarization memory), контекст цонхыг (context window) оновчтой удирдах шаардлага тулгардаг.

4. Хиймэл оюуны төөрөгдөл буюу Hallucination

Grounding ашигласан ч 100% төөрөгдлөөс сэргийлэх боломжгүй. AI заримдаа өгөгдлийн санд байгаа хоёр өөр мэдээллийг хооронд нь буруу холбох, эсвэл хэт үнэмшилтэйгээр худал мэдээлэл өгөх эрсдэлтэй байдаг. Үүнийг хянахын тулд хариултын нарийвчлалыг үнэлэх нэмэлт шүүлтүүр (Guardrails) байрлуулах хэрэгтэй.

Шийдвэр гаргах шалгуур үзүүлэлтүүд

AI туслахыг хэрхэн нэвтрүүлэх талаар шийдвэр гаргахдаа дараах харьцуулалтыг анхаарч үзэх нь зүйтэй.

Бэлэн SaaS шийдэл (Buy) vs. Өөрсдөө хөгжүүлэх (Build)

• Хөгжүүлэлтийн хугацаа: Бэлэн шийдэл нь хэдхэн долоо хоногт хэрэгжих боломжтой бол, дотооддоо хөгжүүлэхэд 3-6 сар шаардагдана.
• Уян хатан байдал: Бэлэн шийдэл нь тухайн платформын хязгаарлалтад баригддаг (API холболт хязгаарлагдмал байх гэх мэт). Харин өөрсдөө хөгжүүлснээр байгууллагын хуучин ERP буюу Legacy системүүдтэй гүнзгий интеграци хийх боломжтой.
• Зардлын бүтэц: Бэлэн шийдлүүд ихэвчлэн хэрэглэгч эсвэл харилцан яриа (conversation) тутамд суурь хураамж авдаг бол, өөрсдөө хөгжүүлсэн үед үүлэн тооцооллын дэд бүтэц (GCP, AWS) болон LLM-ийн API ашиглалтын зардлыг л төлнө.

Энгийн RAG vs. Multi-Agent систем

• Энгийн RAG: Зөвхөн унших зориулалттай (Read-only). Дотоод баримтаас хайлт хийж асуултад хариулах үед тохиромжтой. Хөгжүүлэхэд харьцангуй хялбар, эрсдэл багатай.
• Multi-Agent систем: Унших болон бичих (Read/Write) үйлдэл хийх чадвартай. Хэд хэдэн жижиг AI туслахууд өөр өөрийн үүргийг гүйцэтгэж (жишээ нь: нэг нь баримт шалгах, нөгөө нь төлбөр шалгах) хоорондоо мэдээлэл солилцдог. Архитектурын хувьд маш нарийн төвөгтэй боловч жинхэнэ автоматжуулалтыг бий болгоно.

Нийтлэг алдаа ба түүнээс зайлсхийх нь

Бодит төслүүд дээр багууд дараах нийтлэг алдаануудыг гаргадаг.

1. Нэг дор бүхнийг шийдэх гэж оролдох (Big Bang Launch):
   Хэрэглэгчийн бүх төрлийн асуултыг шийдэж чадах төгс AI хийхээр хэтэрхий удаан хөгжүүлж, зах зээлд гаргах хугацааг алддаг.
   
   Шийдэл: Хамгийн их давтагддаг 2-3 асуудлыг (жишээ нь: нууц үг сэргээх, захиалгын төлөв шалгах) сонгон авч, эхний хувилбарыг гарган, бодит өгөгдөл дээр тулгуурлан тасралтгүй сайжруулах.
2. Хяналт шинжилгээ, телеметрийг орхигдуулах (Lack of Telemetry):
   AI туслах хэрхэн хариулж байгааг хянах тогтолцоо (LLM Observability) үүсгээгүйгээс болж, хэрэглэгчид буруу хариулт авч байгааг оройтож мэддэг.
   
   Шийдэл: Хэрэглэгчийн өгсөн үнэлгээ (Thumbs up/down), хариу өгөх хурд, алдаа заасан тохиолдлуудыг бүртгэх системийн лог (logging) механизмыг эхнээс нь суулгах.
3. Өгөгдлийн чанарт анхаарахгүйгээр AI-д найдах:
   Байгууллагын мэдээллийн баазад (Knowledge base) байгаа хуучирсан, хоорондоо зөрчилтэй мэдээллийг шууд RAG-д холбох.
   
   Шийдэл: AI нэвтрүүлэхээс өмнө дотоод баримт бичгүүдийн бүтцийг сайжруулж, хоцрогдсон мэдээллийг устгах, цэвэрлэх нь архитектураас дутахгүй чухал алхам юм.

Гол дүгнэлтүүд

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

• Grounding буюу өгөгдөлд суурилах нь хамгийн чухал: AI-ийг өөрийн байгууллагын үнэн зөв мэдээллээр тэжээхгүй бол бизнест ашиглах боломжгүй. Вектор хайлт болон өгөгдлийн шинэчлэлд хөрөнгө оруулах хэрэгтэй.
• Хүнд шилжүүлэх замыг тодорхой байлгах: AI нь хэрэглэгчийн үйлчилгээний багийг 100% орлохгүй. Харин тэдний ажлын ачааллыг 30-50% бууруулж, илүү төвөгтэй асуудлуудад төвлөрөх боломжийг олгох хэрэгсэл юм.
• Уян хатан интеграци: AI туслахын үнэ цэнэ нь танай байгууллагын дотоод системүүдтэй (CRM, ERP, Database) хэр зэрэг сайн уялдан ажиллаж, бие даан үйлдэл (Action) хийж чадаж байгаагаар хэмжигдэнэ.
• Аажмаар өргөжүүлэх хандлага: Эхний ээлжинд дотоод ажилчдын туслах (Agent Assist) хэлбэрээр туршиж, эрсдэл болон өгөгдлийн хандалтыг жигдрүүлсний дараа хэрэглэгчид рүү чиглэсэн (Customer-facing) горимд шилжих нь үйл ажиллагааны эрсдэлийг хамгийн сайн бууруулдаг.