Технологи хариуцсан захирлуудын заавал мэдэх 5 хиймэл оюуны (AI) агентийн ойлголтууд

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

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

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

1. Уламжлалт → Бие даасан байдал руу шилжих нь

Ихэнх байгууллагууд автоматжуулалт гэхээр Robotic Process Automation (RPA) эсвэл шугаман скриптүүдийг төсөөлдөг. Уламжлалт автоматжуулалт нь `If-Then` буюу яг заасан дүрмийн дагуу л ажилладаг. Харин AI агент нь зорилгод чиглэсэн байдлаараа ялгаатай.

Үндсэн ажиллагаа

AI агентэд дүрмийн жагсаалт бус, харин хүрэх ёстой зорилго болон ашиглаж болох багаж хэрэгслийг (tools) нь өгдөг. Загвар өөрөө өгөгдсөн нөхцөл байдлыг үнэлж, зорилгодоо хүрэхийн тулд ямар алхмуудыг ямар дарааллаар хийхээ бие даан төлөвлөдөг. Жишээ нь: "Хэрэглэгчийн гомдлын дагуу буцаан олголт хийх боломжтой эсэхийг шалгаж, хэрвээ боломжтой бол гүйлгээг хийгээд имэйл илгээ" гэсэн даалгаврыг агент өөрөө жижиг алхмуудад хуваана.

Архитектурын нөлөө

Энэхүү бие даасан байдал нь системийн дизайнд хоёр том өөрчлөлт авчирдаг:

• Уян хатан байдал: Системд бага зэргийн өөрчлөлт ороход (жишээ нь, API-ийн хариу бага зэрэг өөрчлөгдөх) уламжлалт скрипт гацдаг бол, сайн зохион бүтээгдсэн агент өөр хувилбар турших, алдаагаа засах оролдлого хийх чадвартай.
• Таамаглах аргагүй байдал: Агент яг ямар замаар зорилгодоо хүрэхийг 100% урьдчилан таамаглах боломжгүй. Тиймээс хөгжүүлэлтийн багууд зөвхөн "амжилттай ажиллах" хувилбарыг бус, алдааны хязгаарлалтын орчныг (sandbox) илүү анхаарах шаардлагатай болдог.

2. Агент суурьтай ажлын урсгал ба удирдамж

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

Агентийн дизайны загварууд

Шийдвэр гаргагчид дараах үндсэн архитектурын загваруудыг ойлгох хэрэгтэй. Жишээ болгон Anthropic-ийн агент суурьтай архитектурын судалгаа-нд дурдсан үр дүнтэй загваруудыг авч үзэж болно:

1. Routing (Чиглүүлэх загвар): Орж ирж буй хүсэлтийг төрлөөр нь ангилж, хамгийн тохиромжтой, тусгайлсан үүрэгтэй бага оврын загвар эсвэл систем рүү шилжүүлнэ. Энэ нь зардал болон хоцрогдлыг бууруулдаг.
2. Orchestrator-Workers (Удирдагч ба гүйцэтгэгчид): Нэг гол агент төслийн менежерийн үүрэг гүйцэтгэж, даалгаврыг жижиглэн бусад агентуудад хуваарилж, эцэст нь үр дүнг нэгтгэдэг.
3. Evaluator-Optimizer (Үнэлэгч ба сайжруулагч): Нэг агент үр дүн гаргах бөгөөд нөгөө агент нь түүнийг шалгаж, шаардлагатай бол буцаан засварлуулдаг. Энэ нь код бичих, баримт бичиг боловсруулах зэрэг өндөр нарийвчлал шаардсан ажилд нэн тохиромжтой.

Хэзээ юуг сонгох вэ?

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

3. Санах ой ба контект удирдлага

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

Санах ойн төрлүүд

• Богино хугацааны санах ой: LLM-ийн нөхцөл байдлын цонх (Context window). Энэ нь маш хурдан боловч хэмжээний хязгаартай (жишээ нь 128k - 1M+ tokens). Мэдээлэл ихсэх тусам загварын анхаарал сарних (Lost in the middle) үзэгдэл гарч болно.
• Урт хугацааны санах ой: Өгөгдлийг вектор сан эсвэл Граф өгөгдлийн санд хадгалах аргачлал. Агент хэрэгтэй үедээ хайлтын системээр дамжуулан өмнөх туршлага эсвэл баримтуудаа эргэн санах боломжтой болно.

Санах ойг хэрэгжүүлэхдээ зөвхөн RAG (Retrieval-Augmented Generation) хэрэгжүүлэх нь хангалтгүй. Агентийн төлөвийг хянахын тулд өгөгдлийн санд хэзээ бичилт хийх, хэзээ хуучирсан мэдээллийг устгах дүрмийг кодчилж өгөх шаардлагатай. Үгүй бол агент хоцрогдсон мэдээлэлд үндэслэн буруу үйлдэл хийх өндөр эрсдэлтэй.

4. Багаж ашиглах ба системтэй холболт хийх

AI агентийн хамгийн хүчирхэг шинж чанар нь зөвхөн мэдээлэл унших биш, харин үйлдэл хийх чадвар юм. Үүнийг техникийн хувьд Function Calling буюу функц дуудах гэж нэрлэдэг.

Ажиллагаа ба интеграци

Хөгжүүлэгчид агентэд зориулж дотоод системүүдийн (Jira, Salesforce, ERP гэх мэт) API-уудын тайлбарыг (OpenAPI specification зэрэг) өгнө. Агент хэрэглэгчийн хүсэлтийг ойлгоод, аль API-г ямар параметрүүдтэйгээр дуудах ёстойг JSON форматаар буцаадаг. Дуудлагын хариуг эргүүлэн агентэд өгснөөр, тэрээр дараагийн алхмаа төлөвлөнө.

Хамгийн том эрсдэл: Давхардал ба алдааны удирдлага

Үйлдэл хийдэг агент нэвтрүүлэхэд тулгардаг хамгийн ноцтой эрсдэл бол санаандгүй давхардал болон хяналтгүй давталт юм. Үүнээс сэргийлэхийн тулд:

• Давтагдах үед алдаагүй байх: Агент сүлжээний алдаанаас болоод нэг API-г хоёр удаа дуудсан ч, жишээ нь, хэрэглэгчийн данснаас хоёр удаа мөнгө хасагдахгүй байх архитектурын түвшний баталгаа байх ёстой.
• Загвар хэзээ ч API-г шууд өөрөө дуудах ёсгүй. Загвар зөвхөн "юу хийхийг" санал болгох бөгөөд танай системийн найдвартай код тухайн API-г ажиллуулах ёстой.

5. Аюулгүй байдал, хязгаарлалт ба хяналт

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

Хамгаалалтын түвшнүүд

1. Хүний оролцоотой хяналт: Мэдээлэл унших үйлдлүүдийг агент бие даан хийж болох ч, өгөгдөл устгах, имэйл илгээх, мөнгөн гүйлгээ хийх зэрэг эргүүлэн буцаах боломжгүй үйлдлүүдийн өмнө заавал хүнээс зөвшөөрөл авах интерфэйс шаардлагатай.
2. LLM Firewall ба Guardrails: Агентийн гаргаж буй төлөвлөгөө эсвэл хариултыг үндсэн загвараас тусдаа, өөр хурдан LLM эсвэл дүрмийн системээр шалгуулж, компанийн бодлого зөрчсөн эсэхийг нягтлах.
3. Хандалтын хяналт: Агентуудад системийн "супер-админ" эрх хэзээ ч өгөх шаардлагагүй. Агент нь зөвхөн тухайн хүсэлт илгээсэн хэрэглэгчийн хандах эрхийн хүрээнд л системд хандах (Least privilege) зарчмыг баримтлах нь аюулгүй байдлын шилдэг туршлага юм.

Телеметри ба Мониторинг чадвар

Агент яагаад тодорхой нэг шийдвэр гаргасныг ухрааж харах боломжгүй бол системээ debug хийх аргагүй болно. Агентийн алхам бүрийг (төлөвлөлт, API дуудлага, хариу, дахин оролдлого) нарийвчлан бүртгэдэг tracing систем нэвтрүүлэх нь заавал хийх ёстой зүйлсийн нэг юм.

Үнэлгээ ба шийдвэр гаргах шалгуурууд

Танай баг шинэ боломж нэвтрүүлэхдээ дараах шалгуураар ямар арга барил сонгохоо шийдэх боломжтой:

• Уламжлалт код / RPA: Даалгавар 100% урьдчилан таамаглахуйц, хатуу дүрмээр ажиллах ба алдааны хүлцэл тэг (0) байх үед. (Жишээ: Цалин бодолт)
• RAG (Мэдээлэл хайлт): Хэрэглэгчид их хэмжээний текст дундаас мэдээлэл олох шаардлагатай, гэхдээ системд өөрчлөлт (бичилт) хийхгүй үед. (Жишээ: Дотоод дүрэм журмын туслах)
• AI Агент: Даалгавар нь олон алхамт төлөвлөлт шаардсан, гадны хэд хэдэн системээс өгөгдөл татаж нэгтгээд, эцэст нь ямар нэг үйлдэл (API бичилт) гүйцэтгэх шаардлагатай үед. (Жишээ: Хэрэглэгчийн техникийн хүсэлтийг (ticket) шинжилж, серверийн лог шалгаад, асуудлыг анхан шатны түвшинд засах оролдлого хийх)

Түгээмэл алдаанууд ба түүнээс хэрхэн сэргийлэх вэ?

• Хэтрүүлэн инженерчлэл хийх: Эхний ээлжинд шууд л олон агенттай цогц систем бичих гэж оролдох. Үүний оронд сайн промпт болон ганц хоёр энгийн функц дууддаг хялбар архитектураас эхлэх хэрэгтэй.
• Хэмжигдэхүүн байхгүй байх: Агентийн амжилтыг хэрхэн хэмжих тал дээр үнэлгээний систем (LLM-as-a-judge эсвэл алтан стандарт өгөгдлийн сан) бүрдүүлээгүйгээс болж, загвар шинэчлэгдэх бүрт систем унаж байгаа эсэхийг мэдэх боломжгүй болдог.
• Хязгааргүй давталт дуудах: Агент алдаа гарсан үедээ алдаагаа засах гээд ижил буруу үйлдлээ тасралтгүй давтах эрсдэл. Үүнээс сэргийлж, нэг даалгавар дээр хийх дээд алхмын тоог (Max iteration depth) үргэлж хатуу зааж өгөх шаардлагатай.

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

• Зөв асуудлаа сонгох: Агентийг хэрэглэгчтэй шууд харилцах системд нэвтрүүлэхээсээ өмнө, байгууллагын дотоод үйл ажиллагааны ажлын урсгалын автоматжуулалт дээр эхэлж турших нь эрсдэлийг бууруулна.
• Найдвартай суурь бүтцэд хөрөнгө оруулах: Агент хэдий ухаантай байсан ч түүний холбогдож буй танай байгууллагын API болон өгөгдлийн сан найдваргүй бол үр дүн гарахгүй. Цэвэр өгөгдөл, баримтжуулсан API бол агент нэвтрүүлэх хамгийн эхний алхам юм.
• Эзэмшил ба хариуцлагыг тодорхойлох: Уламжлалт програм хангамжийн багт QA (чанарын шалгагч) байдаг бол, агент суурьтай системд "Промпт болон загварын үнэлгээ" хариуцсан тусгай үүрэг хэрэгтэй болно. Багийн бүтцээ үүнд уялдуулан шинэчлэх хэрэгтэй.
• Тасралтгүй хэмжилт ба сайжруулалт: Агентийн гаргаж буй шийдвэрийн нарийвчлал, хоцрогдол, болон токен ашиглалтын зардлыг байнга хэмжих хэрэгтэй. Загварууд маш хурдан шинэчлэгдэж байгаа тул өнөөдрийн архитектур 6 сарын дараа солигдох бүрэн боломжтойг системээ дизайн хийхдээ тооцоолоорой.