Побудував внутрішній RAG для компанії і випадково знайшов 147 застарілих SOP-документів

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

За останній рік я зустрічав десятки статей про корпоративні AI-асистенти. Майже всі вони концентрувалися на однакових речах: яку модель обрати, яку векторну базу використовувати, як налаштувати retrieval або який фреймворк краще підходить для побудови RAG-систем. Таке враження, що основні ризики таких проєктів завжди лежать у технічній площині.

Коли я почав експериментувати з побудовою RAG поверх великої бази внутрішніх документів, то також очікував побачити саме такі проблеми. Мене зацікавило, наскільки добре система буде знаходити потрібний контекст, чи не почне модель галюцинувати та як зміниться якість відповідей при різних підходах до індексації документів. Проте вже через 2 тижні стало зрозуміло що проблема знаходиться зовсім не там, де я шукав.

На початку експеримент був доволі простим. Я взяв велику кількість внутрішніх документів, серед яких були SOP-и, регламенти, інструкції, шаблони та різні нотатки, накопичені протягом тривалого часу. Після індексації документів і побудови звичайного retrieval-пайплайну система почала відповідати на запитання та шукати потрібну інформацію значно швидше, ніж це можна було зробити вручну.

Початкові результати виглядали достатньо обнадійливо. AI знаходив потрібні інструкції, цитував документи та найчастіше давав цілком правильні відповіді. Але через малий проміжок часу почали траплятися дивні ситуації. Наприклад, система могла пояснювати певний процес, хоча я точно знав, що він давно працює інакше. В інших випадках відповідь посилалася на правила, які вже давно ніхто не використовував.

Спочатку це виглядало як звичайна проблема моделей. Багато хто звик списувати подібні речі на галюцинації LLM, тому моя перша реакція була такою ж. Але коли я почав перевіряти джерела відповідей, картина виявилася значно цікавішою. Практично в усіх випадках модель працювала абсолютно коректно. Вона знаходила релевантний документ і чесно використовувала його як джерело інформації. Помилка була в іншому — у самій документації.

Саме після цього я вирішив провести невеликий аудит усіх документів, які найчастіше потрапляли в результати пошуку. Те, що спочатку виглядало як кілька окремих випадків, дуже швидко перетворилося на системну проблему. Один SOP описував процес, який був актуальним два роки тому. Інший посилався на сервіс, який давно перестали використовувати. Десь одна й та сама задача була описана трьома різними способами. В деяких документах зустрічалися посилання на людей, які вже давно не працювали над цими процесами.

Чим більше я перевіряв документацію, тим більше накопичувалося подібних прикладів. Найцікавіше полягало в тому, що жоден із цих документів окремо не виглядав критично проблемним. Якби я відкрив їх вручну, то, швидше за все, просто не звернув би уваги. Але коли система почала одночасно працювати з усією базою знань, суперечності стали помітними. Виявилося, що багато документів роками залишалися без перегляду просто тому, що ніхто не мав причини та сенсу їх відкривати.

Коли аудит завершився, я вирішив порахувати масштаб проблеми. У базі знайшлося 147 SOP-документів, які потребували оновлення, об’єднання або повного видалення. Частина з них містила застарілу інформацію, частина дублювала інші інструкції, а деякі суперечили актуальним процесам. До запуску RAG-системи я навіть приблизно не уявляв, що таких документів настільки багато.

Після цього виникло інше питання: чому люди не помічали проблему раніше? Чим довше я над цим думав, тим очевиднішою ставала відповідь. У більшості компаній документація накопичується швидше, ніж переглядається. Нові інструкції створюються постійно, а ось видаленням або оновленням старих документів займаються рідше. У результаті база знань поступово збільшується, але її якість погіршується.

Люди рідко працюють із документацією як із єдиною системою. Зазвичай відкривається один конкретний документ для вирішення конкретної задачі. Через це суперечності між різними джерелами можуть залишатися непоміченими роками. RAG поводиться інакше. Він постійно аналізує весь доступний масив знань і тому дуже швидко виявляє слабкі місця, які раніше були приховані, або їх ніхто не помічав.

Після цього експерименту я почав дивитися на корпоративні AI-системи трохи по-іншому. Більшість обговорень навколо RAG зводиться до моделей, embeddings, reranking або оцінки retrieval-якості. Усе я вважаю, що значна частина успіху таких систем залежить від набагато менш популярної теми — якості самих знань.

Якщо документація містить помилки, дублікати або процеси, які вже застаріли — жодна сучасна LLM не зможе це виправити. Навпаки, вона буде масштабувати ці проблеми так само ефективно, як і корисну інформацію. Тому найбільшим результатом цього експерименту для мене став не AI-асистент і навіть не швидший пошук інформації, а те, що система фактично змусила провести аудит знань, який навряд чи відбувся б за звичайних умов.

Мабуть, це і стало головним висновком. Коли ми говоримо про впровадження AI, то часто думаємо про можливості моделей. Насправді ж такі системи дуже швидко показують якість даних, на яких вони працюють. Отже інколи найцікавіші знахідки знаходяться не в коді, не в архітектурі та не в LLM, а в документах, на які роками ніхто не звертає уваги.