Интерно хостован асистент за приступ знању

Контекст

У Делта Холдингу, једна од вреднијих интерних AI прилика била је израда асистента који би интерно знање учинио употребљивијим, а да се притом не занемаре оперативне реалности великог пословног окружења.

Проблем

Рад на интерном асистенту постаје озбиљан тек када систем после пуштања у рад мора да остане под контролом. Тада постају важни хостинг, управљање приступом, правила приступа, квалитет проналажења информација, административне контроле и увид у употребу, квалитет и трошкове. Основни четбот који уме да претражује документе лако је показати у демоу. Много је теже направити интерни систем који може одговорно да се води.

Ту се ломило да ли решење стварно може у продукцију. Систем је морао да ради као асистент за запослене, а да људима који после пуштања у рад воде садржај, дозволе, квалитет и трошкове не постане црна кутија.

Шта сам изградио

Имплементирао сам интерног асистента за приступ знању, хостованог у оквиру организације и намењеног стварној интерној употреби, на Flask/PostgreSQL стеку у Docker-у, уз проналажење информација засновано на pgvector-у, унос докумената уз помоћ LangChain-а и Azure AD SSO.

Практичан резултат био је интерни асистент који су запослени могли да користе над одобреним интерним знањем, док су администратори могли да прате повратне оцене, празнине у бази знања, коришћење, трошкове и стање система после пуштања у рад.

Оно што се може јавно рећи о коришћењу и повратним оценама сажето је у наставку.

Видљиви део били су чет и проналажење информација. Важнији је био административни део система око тога, укључујући:

• управљање ресурсима и базом знања за обухваћени скуп докумената
• контроле корисника и улога, са правилима приступа прилагођеним компанији и одељењу
• механизме повратних оцена и контролу квалитета, укључујући оцене одговора, сигнале негативних оцена, преглед празнина у бази знања и атрибуцију одговора
• аналитику коришћења и увид у трошкове ради праћења после пуштања у рад
• структурисано логовање, тестирање оптерећења, провере здравља система и администраторске прегледе за текући рад

Поента није била у набрајању инфраструктурних ознака. Поента је била да систем може да се води, прегледа и побољшава и после пуштања у рад.

Колико се може јавно рећи, модел рада изгледао је отприлике овако:

Зашто ово није био само четбот над документима?

Кључан није био чет интерфејс. Кључан је био модел рада око њега: управљање приступом, ограничен приступ, власништво над садржајем, преглед повратних оцена, увид у коришћење, праћење трошкова и провере стања система.

Те одлуке су од асистента направиле систем који организација може стварно да води, а не само нешто што запослени могу да испробају.

Контекст испоруке

Моја улога

Имплементирао сам асистента и административни део система око проналажења информација, приступа, сигнала квалитета и увида у рад система потребног за стварну интерну употребу.

Овај пројекат је урађен интерно у Делта Холдингу, где сам напредовао од AI Specialist до AI Innovation Lead, водио мали AI тим и остао непосредно укључен у дизајн и имплементацију система.

Облик тима

Пројекат је повезивао потребу за интерним приступом знању са оперативним очекивањима људи који би после пуштања у рад морали да воде, прегледају и подржавају систем.

Ограничења

Архитектура је морала да испоштује хостовање унутар организације, очекивања у погледу управљања приступом, правила приступа усклађена са организационом структуром и потребу да увид у употребу, квалитет и трошкове постоји већ од прве верзије.

Зашто је хостовање унутар организације било важно

То није била споредна техничка одлука, већ део начина на који је производ морао да ради. У оваквом окружењу управљање приступом, правила приступа, административне контроле, увид у коришћење и трошкове и оперативно власништво директно су везани за избор начина испоруке. Систем је зато био осмишљен да ради у тим ограничењима, а не да их заобилази ради лакшег демоа.

Оперативне одлуке

• Проналажење информација морало је да остане корисно у оквиру правила приступа, уместо да се понаша као општи слој претраге.
• Административни део система морао је да постоји од прве верзије, не да се накнадно дограђује.
• Механизми повратних оцена морали су после пуштања у рад да изнесу на видело проблеме са квалитетом одговора, празнине у бази знања и атрибуцију одговора.
• Увид у коришћење и трошкове морао је да покаже стварну употребу система, уместо да систем после увођења остане непрозиран.
• Оперативна спремност морала је да укључи провере стања система, логовање и увид у увођење, а не само апликацију која ради у развоју.
• Решење је морало да буде одрживо за стварну организацију и после прве верзије.

Сигнал коришћења

Више од 300 јединствених запослених користило је асистент током првог месеца после пуштања у рад, а експлицитне оцене одговора биле су више од 85% позитивне.

Период после пуштања у рад показао је и да техничка спремност сама по себи не ствара трајно коришћење. За наставак употребе потребни су јасно власништво над производом и садржајем, као и организован начин увођења запослених у употребу система. Утицај на време процеса није мерен у првој верзији. Оно што се може јавно рећи обухвата коришћење током првог месеца и експлицитне повратне оцене.

Зашто је овај случај важан

Овај случај показује интерни AI производ изван слоја прототипа: употребу за запослене, административни и оперативни део система, приступ усклађен са организационом структуром и начин увођења осмишљен да остане одржив и после првог демоа.