Двигун, який мав шість полюсів — Міф про десять рядків коду

Розслідування у шести частинах про причини, через які документальний чат-бот, який вам продали, продовжує вигадувати — та про інший напрямок, яким на початку 2026 року хтось почав рухатися.

Розслідування у шести частинах про причини, через які документальний чат-бот, який вам продали, продовжує вигадувати — та про інший напрямок, яким на початку 2026 року хтось почав рухатися.

Вступ — Двигун, який мав вісім полюсів (але мав шість)

Мілан, березень 2026. Менеджер відкриває внутрішній корпоративний чат-бот, з тих, що змонтовані «за два тижні» з великим енту{{ m{узіазмом}}} та невеликою недовірою. Дуже просте запитання: «Скільки полюсів у двигуні CMP40M?». Чат-бот відповідає з усією впевненістю, яку вміють демонструвати великі мовні моделі: «Двигун CMP40M має вісім полюсів.»

Неправильно. У нього шість. Правильна відповідь не була в каталозі на 422 сторінки, який хтось, кілька місяців тому, з повною довірою завантажив у векторну базу даних, переконаний, що відтепер система "все знатиме". Цих даних у каталозі просто не було. Вони знаходилися в PDF-файлі, доданому до електронного листа технічних фахівців SEW, який був збережений у папці, яку ніхто не потурбувався індексувати.

Ця сцена, з варіаціями в залежності від галузі та діалекту, повторюється у сотнях італійських офісів. Обіцянка була простою та привабливою: надайте вашому AI-асистенту всі корпоративні документи, і він зможе відповісти на будь-яке питання щодо них. Реальність набагато прозаїчніша: чат-бот читає, але не розуміє, шукає, але не знаходить, і коли не знаходить — замість того, щоб сказати про це, вигадує. Вигадує плавно, з бездоганною граматикою, з правдоподібними цифрами. Що набагато гірше, ніж не відповідати взагалі.

З кінця 2024 до початку 2026 року ми витратили місяці на розтин цих невдач. Не для розпалювання суперечок, а щоб зрозуміти одну річ: чому така лінійна ідея — "дайте йому документи, а потім запитуйте" — стає настільки складною, коли вона сходить зі сцени демонстрації та потрапляє в кімнату з реальними серверами.

Це розслідування з шести розділів розповідає про те, що ми знайшли: тихі помилки, які видаляли цілі каталоги, хмарні переранжувальники з неправильними балами, галюцинації, що виникли не через модель, а через забруднені дані, накопичені роками, рахунки на вихід, які робили кожен запит дорожчим за його вартість, і "популярні" фреймворки, які обіцяють все в десять рядків коду, за умови, що не вимагати від них занадто багато. І в останньому розділі – інший напрямок, який хтось почав тихо прокладати на початку 2026 року – архітектура, в якій стратегія пошуку перестає бути кодом і стає документом, який будь-хто в компанії може читати та змінювати.

Кожен розділ є самостійним. Якщо ви хочете почати з історії про 342 зниклі таблиці або з історії брехливого переранжувальника, ви вільні це зробити. Але розповідь в цілому має мораль, яка виникає лише в кінці: корпоративний RAG – цей технічний акронім, що означає Retrieval-Augmented Generation, тобто "генеруй відповіді на основі документів, які ти спочатку отримуєш" – ще не є готовим продуктом. Це фронтир. І як усі фронтири, досі його розповідали переважно продавці. Настав час послухати тих, хто жив у ньому.

Розділ 1 — Міф про десять рядків коду

Слайд ідентичний на кожній конференції про ШІ з 2023 року: "Ваш корпоративний помічник з документацією в 10 рядках коду." Під заголовком – блок Python у пастельних тонах, який демонструє бібліотеку з відкритим кодом – зазвичай одну з тих відомих американських, назва якої викликає асоціації з ланцюгами дерев або тибетськими ламами – яка завантажує PDF-файли, розбиває їх, вставляє в векторну базу даних і запитує за допомогою мовної моделі. За п’ять хвилин у вас є чат-бот. За п’ять хвилин – оплески. За п’ять хвилин італійська компанія середнього розміру переконується, що проблему вирішено, і що її ІТ-відділ може впоратися з цим за два тижні.

Проблема – те, чого слайд не говорить – полягає в тому, що демонстрація побудована з трьох добре форматованих PDF-файлів, запитання, яке було спеціально підібране для відповідності вмісту, сцени без реальної затримки та доповідача, який пробував все це двадцять сім разів, перш ніж вийти на сцену. У реальності корпоративні документи – це геологічний хаос: скани сканів, таблиці, що накладаються на текст, виноски, які вклинюються в абзаци, альфачислові коди типу "RH1M", які чоппер розрізає навпіл, вважаючи їх словами, зображення, які містять сімдесят відсотків корисної інформації, але ніхто насправді не витягує, і макети настільки креативні, що вимагають археолога, а не парсера.

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

Open-source фреймворки, які популяризували RAG, створені для демонстрації, а не для виробництва. Це надзвичайно елегантні ланцюжки абстракцій, де кожен шар приховує негласне припущення: що ваші PDF мають пристойне OCR, що ваші фотографії вже були описані, що ваші таблиці відповідають певній конвенції, що модель вбудовування дійсно розмовляє вашою мовою (спойлер: багато добре володіють лише англійською), що ваш архів вже очищений від дублікатів. Коли одне з цих припущень не справджується — а принаймні одне не справджується завжди, майже завжди три — система не перестає працювати. Навіть гірше: вона перестає працювати добре, але продовжує давати відповіді. Плавні, впевнені, і часто не пов’язані з правдою.

Існує фраза, яка поширена серед тих, хто професійно будує ці системи, і яку ви ніколи не знайдете в навчальних посібниках: "RAG легко зробити, але важко зробити добре." Між першою демонстрацією та виробничим сервісом існує прірва, яку неможливо подолати, додаючи GPU або змінюючи модель. Її можна подолати, зрозумівши одну неприємну річ: коли ви будуєте корпоративний RAG, ви не пишете код. Ви проєктуєте невеликий, впертий пошуковий рушій, адаптований до ваших документів, з усіма редакційними рішеннями, які це передбачає — що є шумом, що є сигналом, що потрібно індексувати двічі, а що потрібно викинути. Просто в навчальних посібниках із десяти рядків ці рішення приймаються за вас один раз кимось, хто ніколи не бачив ваших документів. І майже завжди це неправильні рішення для вашого випадку.