Стратегія як документ — Сьомий розділ

Розділ 6 — Стратегія як документ, а не як код

Доходимо до інсайту, який найбільше згадується в розповідях тих, хто будував RAG з 2023 року і пізніше, як "те, що я хотів би зрозуміти з першого дня".

Традиційні фреймворки розглядають стратегію пошуку як код Python. Хочете, для технічних каталогів, спочатку шукати за кодом продукту, потім за ключовими словами, потім за семантичними векторами, і лише в останню чергу генерувати відповідь? Напишіть функцію. Хочете, для фотоальбомів, взагалі пропустити традиційний семантичний пошук і покластися на спеціалізований reranker для зображень? Напишіть іншу функцію. Хочете, для корпоративних відео, розділити аудіо від візуальної доріжки, транскрибувати їх окремо, обробляти як окремі джерела, а потім знову складати у фінальну відповідь? Ще одна функція. Кожен тип контенту, кожна сфера, кожен клієнт зрештою генерує гілку коду, яка відрізняється від інших, аж до того, що зміна стратегії вимагає випуску програмного забезпечення, перевірки коду, циклу тестування, розгортання. Час між "у мене є ідея, як покращити пошук у технічних посібниках" і "ідея в продакшені" вимірюється тижнями. Для кожної ідеї.

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

Ті, хто працював з цим підходом – назвемо його, без особливої вигадки, Meta-RAG – розповідають про зміну швидкості, яка виходить за межі інженерії. Типовий запит клієнта "додати пошук за кодами продукції, які містять абревіатури типу CMP40M або RH1M" більше не є двотижневим тікетом розробки. Це новий крок, доданий до JSON-процедури, гаряче протестований на staging-середовищі, перенесений у виробництво за один день. Питання "що зміниться, якщо ми використаємо інший reranker для фотографій, залишивши поточний для тексту?" вирішується шляхом зміни одного рядка конфігурації. Експеримент нічого не коштує, відкат нічого не коштує (достатньо відновити попередню версію документа), а накопичені знання – що добре працює для певного типу контенту – стають версійованим та переносним активом, а не негласним знанням того, хто написав конкретну гілку коду і зараз у відпустці.

Існує також цікавий соціальний ефект, який проявляється в організаціях, що впроваджують цей підхід. Зі стратегіями як документом розмивається межа між "розробником" і "досвідченим користувачем". Цифровий бібліотекар, корпоративний архіваріус, експерт у предметній області — керівник технічного відділу, відповідальний за документацію, продакт-менеджер, який як ніхто інший знає справжні запитання клієнтів — може прочитати стратегію, зрозуміти, що вона робить, запропонувати зміни, іноді навіть написати їх безпосередньо. Йому не потрібно проходити через воронку тікетів розробки, не потрібно пояснювати розробнику речі, яких він не знає (тому що це не входить в його професійні обов'язки). RAG перестає бути продуктом, який ви споживаєте, і стає інструментом, який ви моделюєте на основі ваших організаційних знань. Це, з досвіду тих, хто це спробував, змінює моральний дух проєкту ще до того, як зміниться динаміка метрик.

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

Завершення – сьомий розділ, через кілька місяців

На початку 2026 року, підсумовуючи уроки попередніх розділів — таблиці, які губилися, брехливі реранкери, успадковані галюцинації, рахунки за хмарні послуги, що росли швидше за цінність, перспективні, але жорсткі фреймворки — хтось в Італії почав будувати інший RAG-сервер. Написаний на Python, розрахований на роботу на доступному обладнанні, здатний спілкуватися з хмарними моделями, коли це вигідно, і з локальними моделями, коли цього вимагає конфіденційність або вартість не виправдовує себе. Сервер, в якому стратегії пошуку є редагованими документами, реранкер — це локальний процес на GPU, таблиці не губляться, тому що до них ставляться як до першокласних об'єктів, фотографії не успадковують об'єкти з запилених архівів інших епох, а вартість запиту — як у грошах, так і в даних, що вилучаються третіми сторонами — відома та контрольована до цента.

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

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

Тим часом, якщо ви дійшли сюди, ви вже провели більше «розтину», ніж 90% осіб, які приймають рішення, і які зараз підписують контракт на корпоративного чат-бота, не ставлячи жодного з питань, які ви поставили, читаючи ці розділи. Це краща відправна точка, ніж та, з якої вони починали. І в найближчі місяці різниця між тими, хто ставив ці питання, а тими, хто ні, стане дуже помітною на рахунках — і на відповідях, які ваш ШІ даватиме вашим клієнтам.

Це розслідування було підготовлено у квітні 2026 року на основі вісімнадцятимісячного досвіду проектування, побудови та оптимізації корпоративних систем RAG з кінця 2024 до початку 2026 року.