Вътрешен асистент за знания: кога извличането от източници работи и кога не

Асистентът не поправя лошата база знания

В растяща компания отговорът на въпроса „Как одобряваме отстъпка?“ може да е в Notion, стар документ, разговор в Slack и главата на търговския директор. Екипът губи време в търсене, а новите хора питат едни и същи колеги. Идеята за вътрешен асистент с изкуствен интелект изглежда логична: задавате въпрос и получавате кратък отговор с посочен източник.

Рискът е, че убедително написаният отговор може да стъпи върху грешна версия, да смеси правила за две държави или да покаже кадрова информация на човек без право за достъп. Извличането от източници не определя кое знание е вярно. То намира части от достъпните материали и ги дава като контекст на модела. Ако входът е хаотичен, системата просто намира по-релевантен хаос.

Затова проектът не започва с векторна база данни. Започва с една оперативна област, конкретни потребители, повтарящи се въпроси и официални източници. Ако още няма документиран правилен начин на работа, първата стъпка е стандартна процедура и отговорник, а не разговорен бот.

Извличането намалява разстоянието до знанието. То не създава отговорност, актуалност или право за достъп вместо вас.

Как работи извличането от източници на разбираем език

Подсиленото с извличане генериране свързва два процеса: търсене и създаване на отговор. При индексирането документите се извличат, почистват, разделят на смислени части, описват с метаданни и се добавят в индекс за търсене. При въпрос системата намира относимите части, добавя ги към инструкцията и моделът формулира отговор, който трябва да сочи използваните източници.

Семантичното търсене намира близък смисъл дори когато потребителят и документът използват различни думи. Това е полезно при въпрос „Колко отпуск има колега, който работи от разстояние?“, когато политиката използва други формулировки. За имена, кодове, номера на договори и точни термини търсенето по ключови думи или съчетаването на двата подхода често е по-надеждно. Добрата система избира метода според въпроса.

Всеки етап има оперативен отговорник. Отговорникът за процеса одобрява съдържанието. Отговорникът за системата управлява връзките, индексирането и достъпа. Експертите по областта решават дали отговорът и доказателството са приемливи. Без тези роли асистентът може да работи технически, но никой не носи отговорност за знанието.

Изберете най-простия подход, който решава проблема

„Да построим система за извличане“ не е бизнес изискване. Бизнес изискването може да бъде нов служител да намира актуалното правило за две минути или сервизният екип да проверява процедура, без да прекъсва оперативния ръководител. Сравнете вариантите по обем и разнообразие на знанието, честота на промяна, права за достъп, нужда от цитирани източници и ресурс за поддръжка.

Започнете отляво надясно в таблицата. Преминавайте към по-сложен вариант само когато по-простият не покрива реалните въпроси или изискванията за управление. Поддържаните решения могат да спестят голяма част от работата по приемане и извличане на съдържанието; специално разработеното решение дава повече контрол, но създава повече компоненти за наблюдение и поддръжка.

Проверка на готовността на знанията преди първия прототип

Оценете първия набор от документи по пет критерия с 0, 1 или 2 точки. Авторитетност: има ли един одобрен източник за всяко правило? Актуалност: има ли отговорник, версия и дата за преглед? Структура: може ли документът да се раздели на части, които имат смисъл сами? Метаданни: знаете ли отдела, държавата, аудиторията, вида и състоянието на документа? Достъп: можете ли да приложите същите права и в слоя за извличане?

При 8–10 точки има основа за ограничен пилот. При 5–7 първо коригирайте най-слабите полета и тествайте малък набор от документи. Под 5 прототипът ще измерва предимно качеството на хаоса. Тази скала е диагностична, а не индустриален стандарт; адаптирайте тежестите към риска на областта.

Не индексирайте целия Google Drive „за всеки случай“. Започнете с 50–200 одобрени страници от една област, премахнете дубликатите и архивните версии и добавете адрес на източника, заглавие, отговорник, дата на последния преглед, група за достъп и дата на влизане в сила. Документ без отговорник може да бъде полезна следа за човек, но не трябва автоматично да бъде авторитет за асистента.

Сканираните документи, сложните таблици и презентациите изискват проверка на извличането. Отворете реално извлечения текст, не само оригиналния файл. Загубена колона, заглавен ред или бележка под линия може да промени смисъла, преди моделът изобщо да види съдържанието.

• Официален източник и отговорник от бизнеса за всяко правило или процедура.
• Една активна версия и видимо правило за архивиране.
• Самостоятелни раздели с описателни заглавия, а не един монолитен документ.
• Метаданни за версия, дата на влизане в сила, език, аудитория и група за достъп.
• Условие за обновяване при промяна на процес, система, продукт или регулация.

Тествайте извличането отделно от красивия отговор

Когато асистентът греши, първият въпрос е дали е намерил правилното доказателство. Ако не е, промяната на инструкцията рядко решава проблема. Проверете разчитането на файловете, границите между откъсите, филтрите по метаданни, преформулирането на заявката, баланса между ключови думи и семантично търсене и подреждането на резултатите. Ако правилният откъс е намерен, но отговорът е грешен, тогава преглеждате инструкциите, сглобяването на контекста и модела.

Създайте проверочен набор от 50–100 реални въпроса: лесни, двусмислени, обхващащи няколко документа, остарели, извън обхвата и зададени с думите на потребителите. За всеки запишете очаквания източник, позволената аудитория, приемливия отговор и кога системата трябва да каже „не знам“. Експерт по областта одобрява набора; техническият екип не трябва сам да определя бизнес истината.

Следете дела на намерените правилни източници, точността на доказателствата и цитатите, дела на обоснованите отговори, правилните откази, отговорите по остарели данни, нарушенията на достъпа, времето и разхода за приет отговор. Един общ процент за точност скрива най-опасните грешки. Достъпът до забранен документ е безусловен провал дори при отличен среден резултат.

Пазете корекциите като регресионни случаи. Бутон за обратна връзка без опашка, отговорник и срок не подобрява системата. Всеки потвърден пропуск трябва да доведе до една от четири ясни промени: изходното съдържание, метаданните и правата, настройката за извличане или инструкцията за отговор.

Първо оценявайте дали е намерено правилното доказателство. После оценявайте дали моделът го е използвал правилно.

Права за достъп и защита на документите

Слоят за търсене не трябва да разширява достъпа. Ако служителят няма право да отвори документ за възнаграждения в изходната система, той не трябва да получава откъс или обобщение от него. Филтърът за права се прилага преди извличането, а не като инструкция към модела да пази тайна. При смесване на отдели, клиенти или държави прилагайте ограничения на ниво документ и тествайте всяка роля отделно.

OWASP посочва изтичането на данни, смесването на контекст и отравянето на данни като специфични рискове при векторните системи. Използвайте списък с одобрени източници, проверявайте файловете при приемане и не добавяйте автоматично документи от външни хора към доверения набор. Скрити инструкции в автобиография, заявка за поддръжка или клиентски файл не са фирмени правила и не трябва да променят поведението на асистента.

Записвайте идентификатора на заявката, ролята на потребителя, приложените филтри, идентификаторите на документите, оценките от извличането, версията на модела и настройките и резултата от обратната връзка. Минимизирайте чувствителното съдържание в дневниците и определете срок за съхранение и достъп. Векторното хранилище не е безопасна зона по подразбиране; то съдържа производна форма на фирменото знание и изисква същото внимание към управлението.

• Наследена самоличност или надеждно съпоставяне между потребител и групи за достъп.
• Извличане според правата, преди контекстът да стигне до модела.
• Одобрени връзки за приемане и карантина за нови или външни файлове.
• Тестове срещу изтичане между екипи, клиенти и архивирано съдържание.
• Ясен процес за изтриване и повторно индексиране при отнет достъп или нова версия.

Кога извличането няма да реши проблема

Извличането не е нужно за еднократен въпрос върху един кратък документ; качен файл или обикновено търсене може да е достатъчно. То не е правилният слой и за точно текущо състояние, наличност, цена или баланс — тези отговори трябва да идват от изходната система чрез заявка или контролиран инструмент. Документ от миналата седмица не е надежден заместител на текущия запис в системата за управление на клиенти или ресурсите.

Извличането не лекува лошо написани правила, конфликтни стандартни процедури или решения, които никога не са документирани. Не го използвайте и като заместител на допълнително обучение на модела или добра инструкция, когато целта е постоянен формат, тон или специфично поведение, а не достъп до променящо се знание.

При правни, финансови, кадрови решения или решения за безопасност извличането може да покаже относимото правило, но човек с правомощия трябва да прецени конкретния случай. Изречението „според документ Х“ не превръща общото указание в професионално решение и не премахва нуждата от ескалация.

• Няма официални източници или отговорник за знанието.
• Има твърде малко съдържание и обикновеното търсене решава задачата.
• Търси се точна транзакционна стойност от структурирана система.
• Правата не могат да бъдат пренесени до ниво документ или откъс.
• Няма експерт по областта, набор за оценяване и процес за корекции след пускането.

Практически пример: 30-дневен пилот за сервизен екип

Представете си фиктивна 35-членна инженерна сервизна компания. Координаторите на проекти прекъсват старшите инженери с въпроси за предаване на обект, достъп до площадката, шаблони за отчети и гаранционни процедури. Знанието е в 480 файла в Google Drive, но първият пилот не индексира всичко. Екипът избира областта „предаване на обект“, определя оперативен ръководител за отговорник и одобрява 120 активни страници.

През първата седмица премахва 34 дублирани или архивирани файла, добавя метаданни и проверява извличането на таблиците. През втората създава 70 проверочни въпроса от реални търсения и интервюта. Въпросите включват липсваща информация, стара терминология, друг тип обект и роли без достъп.

През третата седмица поддържаният прототип връща отговор само когато има поне една видима връзка към източник. Примерните критерии са: правилният документ да е сред първите резултати за поне 90% от проверочните въпроси; нула нарушения на достъпа; 95% коректни цитати в дадените отговори; и правилен отказ при всички въпроси извън одобрения набор. Това са илюстративни прагове, не универсален показател.

През четвъртата седмица петима координатори използват асистента паралелно със сегашния процес. Екипът измерва приетите отговори, времето до проверен отговор, въпросите към старши инженер, корекциите и цената. Решението след пилота е едно от три: разширяване към втора област, допълнително почистване на съдържанието или спиране. Демонстрация, която отговаря красиво на пет подбрани въпроса, не е четвърта възможност.

Примерът, обемите и праговете са илюстративни. Вашият пилот трябва да използва реалните въпроси, роли, източници и цена на грешката.

Следващото решение: преглед на готовността на знанията

Съберете отговорника за процеса, отговорника за знанията, специалистите по технологии и сигурност и двама реални потребители. Изберете една област и прегледайте въпросите, официалните източници, версиите, метаданните, правата и цикъла за корекции. Резултатът трябва да е: готовност за поддържан пилот, първо почистване на съдържанието или решение, че извличането не е подходящият подход.

1→10 може да включи този преглед в системен одит или проект за внедряване на изкуствен интелект: картографираме потока на знанията, избираме най-простата работеща архитектура, определяме документите и модела за достъп и изграждаме измерим списък със задачи за пилота. Целта не е още един разговорен бот. Целта е по-малко прекъсвания и по-бързи решения с видимо доказателство.