Чому впровадження Dify зупиняється на прототипі
Впровадження Dify зазвичай починається з демо: агент відповідає за базою знань, посилається на джерела, виглядає переконливо. Далі починається робочий контур — і запуск не відбувається.
Пілот агента не виходить у продукт, тому що все, що в показі трималося на ручних діях інженера, у промисловій експлуатації перестає триматися.
Перше вузьке місце — стик даних. Базу знань оновлюють вручну: хтось вивантажує документи, чистить і заливає заново. Індекс розходиться з реальністю вже за тиждень, агент цитує скасовані редакції й так само впевнено відповідає неправильно.
Ручні оновлення сценаріїв додають друге: правки промптів потрапляють прямо у бойову конфігурацію, без перевірки та історії, а відновити, що змінилося між двома різними відповідями, заднім числом неможливо — контролю версій промптів просто немає.
Третє — розбір звернень вручну. Поки запитів десятки, збої ловлять очима; на сотнях уже незрозуміло, де помилився агент, де підвів пошук, а де питання поставлено не до місця.
Доступи при цьому спільні: тестовий і робочий контури сидять на одних ключах, і будь-який експеримент може потрапити до живого користувача.
Розбираємо, як це закривається: версіонуємо промпти й індекс, розводимо середовища та права, ставимо перескладання бази знань за розкладом і розбір звернень за журналами.
Вимірювані ефекти під час перенесення агентів у робочий контур
Перенесення агента з прототипу в робочий контур вимірюється не фактом запуску, а набором стійких показників. Ми знімаємо їх до і після на одному й тому самому наборі звернень — інакше порівняння нічого не підтверджує.
| Показник | До перенесення | Після перенесення | За рахунок чого змінюється |
|---|---|---|---|
| Термін виведення сценарію | тижні ручного складання та погоджень | дні на складання, перевірку й публікацію | готові блоки та єдиний контур публікації |
| Частка ручних операцій | оператор доопрацьовує значну частину діалогів | на людину залишаються лише винятки | маршрутизація та перевірка відповідей за базою знань |
| Повторювані відмови | одні й ті самі помилки повертаються після кожної правки | причина фіксується в сценарії, відмова не повторюється | журнал прогонів і набір регресійних перевірок |
| Навантаження на операторів | пікова черга зростає швидше за штат | піки гасяться автоматично | агент закриває типові звернення |
| Стійкість під час оновлення | правка ламає сусідні гілки | зміни проганяються на наборі тестів | версіонування та відкат до попередньої збірки |
Цей ефект тримається на регламенті, а не на разовому запуску: набір перевірок проганяється під час кожного оновлення сценарію, тому повторювані відмови не повертаються, а навантаження на операторів не зростає разом із кількістю звернень.
Такий контур збирається на Dify з готових блоків — сценарій залишається керованим без правок у коді.
Підходи до впровадження Dify: порівняння трьох режимів роботи
Режим впровадження вибирають не за розміром компанії, а за тим, хто володіє логікою сценарію та наскільки чутливі дані. Три варіанти нижче не замінюють одне одного: вони дають різний рівень контролю й по-різному переживають зміни.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Готові шаблони сценаріїв | Типовий процес запускається за дні: відповіді за базою знань, розбір звернень, маршрутизація запитів | Логіку майже не змінюємо. Нестандартні гілки, власні формати даних і зовнішні перевірки не запрацюють без переробки |
| Налаштовувані сценарії | Бізнес-логіка специфічна: власні джерела, правила обробки, зв’язка з внутрішніми системами | Потрібен власний контур тестування та порядок правок — інакше зміни йдуть у роботу без перевірки |
| Ізольований контур із розмежуванням прав доступу | Дані не залишають периметр, потрібні ролі, журналювання та аудит дій | Потребує більше ресурсів на експлуатацію, а погодження змін відбувається повільніше |
Є й випадки, коли підхід не підходить. Готові шаблони безглузді там, де сценарій ухвалює рішення з юридичними наслідками й кожну дію потрібно обґрунтовувати. Ізольований контур надлишковий, якщо обмежень на дані немає: ви отримаєте супровід складніший, ніж саме завдання.
А налаштовувані сценарії не варто брати, коли процес ще не став усталеним — спочатку фіксуємо правила, потім переносимо їх у платформу.
Розбираємо завдання й говоримо прямо, який режим дасть результат, а який створить зайве навантаження.
Етапи інженерної роботи: від аудиту до передачі контуру
Роботу ведемо етапами, і кожен завершується артефактом, який можна перевірити: схемою, налаштованим контуром, протоколом прогону. Замовник бачить прогрес і на будь-якій межі розуміє, що саме вже отримав.
- Обстеження сценаріїв і даних. Розбираємо завдання й дивимося, чим вони забезпечені: які документи та сервіси є, у якому вони стані й як часто змінюються. На виході — перелік сценаріїв із пріоритетом та оцінкою готовності даних.
- Схема зв’язків із джерелами. Фіксуємо, звідки контур бере знання — файлові сховища, бази, зовнішні сервіси. Визначаємо розбиття документів на фрагменти та правила оновлення пошукового індексу.
- Налаштування контуру та ролей. Збираємо застосунок на Dify, підключаємо модель, описуємо сценарії діалогу й розділяємо права: хто ставить запитання, хто править базу знань, хто бачить журнал звернень.
- Перевірка на тестових даних. Проганяємо набір еталонних запитань з відомими відповідями: дивимося частку правильних, поведінку на неповних даних, якість посилань на джерело. Розбіжності правимо в запитах і розбитті.
- Навчання команди. Показуємо, як додавати документи, оновлювати індекс і читати журнал. Навчання відбувається на реальних сценаріях, щоб команда далі супроводжувала контур самостійно.
- Передача контуру. Віддаємо конфігурації, схему зв’язків, тестовий набір і документацію. Окремо фіксуємо, що можна змінювати власними силами, а що потребує повторного складання.
- Супровід. Стежимо за якістю відповідей, оновлюємо базу знань і правила, розбираємо звернення з помилками та повертаємо їх у тестовий набір.
Що передаємо після запуску: конфігурації, ролі, регламенти
Передача — це не архів із файлами, а робочий комплект, за яким ваша команда продовжує змінювати сценарій без нас. Ось що залишається у замовника на платформі Dify і в пов’язаній документації.
- Опис конфігурації. Склад вузлів сценарію, вибрані моделі, параметри генерації, змінні середовища та місця зберігання ключів — із позначкою, що змінюється без повторного складання, а що потребує повторного прогону тестів.
- Схема зв’язків із джерелами. Звідки надходить кожен масив даних, як часто переіндексується база знань, за якими полями відбувається зіставлення, що повертає агент при недоступності джерела.
- Політики доступу. Ролі користувачів і сервісних облікових записів, розмежування за відділами, які дані потрапляють у контекст запиту, що пишеться в журнал і на який термін зберігається.
- Регламент оновлення сценаріїв. Порядок правки промптів: чернетка, прогон на наборі запитань з еталонними відповідями, викочування, відкат до попередньої версії при зниженні якості.
- Інструкції для команди. Як додати документ у базу знань, як читати журнал діалогів, які збої лагодяться на місці, а які надходять до нас.
- Матриця відповідальності. Власник сценарію, той, хто погоджує правки промптів, і той, хто відповідає за актуальність джерел і доступи.
Приймання передачі просте: ваш інженер сам вносить правку в промпт і додає новий документ у базу знань. Якщо це виходить без нашої підказки — комплект повний, і супровід можна вести власними силами.
Кейс: як ми скоротили ручний розбір звернень
Звернення надходять на електронну пошту, у месенджер і форму на сайті, і кожне з них оператор розбирав вручну: визначав категорію, шукав відповідь у регламентах і в історії закритих звернень, збирав відповідь із частин.
На типове запитання йшло 10–15 хвилин, при піковому навантаженні черга розтягувалася на години, а якість залежала від того, хто з операторів на зміні.
Переносили не «чат-бота», а сам сценарій розбору. На Dify зібрали маршрут обробки: класифікація звернення, вибір джерела знань (регламенти, історія закритих звернень, документи продукту), генерація відповіді з обов’язковим посиланням на фрагмент, з якого її зібрано.
Якщо впевненість агента нижча за поріг або питання виходить за межі описаних тем, звернення переходить до оператора разом із причиною відмови.
Що змінилося
Частка звернень, які закриваються без людини, зросла з 12% до 68%. Час першої відповіді скоротився з 40 хвилин до хвилини, повторних звернень з тієї самої причини стало майже втричі менше: агент повертає не переказ, а точну витримку з регламенту.
Навантаження на підтримку перерозподілилося: пікова черга зменшилася вчетверо, оператори займаються нетиповими випадками та правками бази знань.
Раз на тиждень ми вибірково перевіряємо відповіді агента — частка коректних тримається вище 90%, а кожна розібрана помилка перетворюється на правило маршрутизації або новий фрагмент у базі.
Що робити, якщо прототип агента вже зібрано вручну?
Розбираємо прототип як специфікацію, а не як код, який потрібно перенести. Спочатку знімаємо з нього фактичну поведінку: порядок кроків, умови переходів, усі місця звернення до моделі та те, що відбувається при порожній або несподіваній відповіді. Такий розбір дає список вимог, із яким далі й звіряється готова збірка.
Зберігаємо те, що найдорожче відтворити заново: формулювання промптів, логіку сценарію цілком, набір реальних запитів для перевірки та накопичені дані — документи, історію звернень, зібраний індекс пошуку.
Саме на них прототип уже показує прийнятну якість, тому переносяться вони без втрат, а не збираються заново.
Переписуємо зв’язки між кроками. У ручній збірці маршрутизація, обробка помилок і повторні спроби склеєні в одному обробнику — перенесення один-в-один тут не працює.
У Dify ці ролі розділені: сам сценарій, база знань і виклики зовнішніх систем живуть окремо й налагоджуються частинами.
План міграції будується так: вивантаження в проміжний формат, нормалізація, завантаження в новий контур і звірка — кількість записів, розбиття на частини, результат пошуку на контрольних запитаннях до і після.
Старий контур залишається доступним лише для читання, поки новий не підтвердить збіг на всьому наборі тестових запитів.
Далі — паралельний прогон: однакові запити надходять до обох версій, відповіді порівнюються на вибірці спірних випадків. Перемикання робимо після того, як розбіжності буде пояснено, зі збереженою можливістю повернутися на прототип.
Обмеження платформи та часті технічні сумніви
Платформа Dify закриває збірку сценарію та підключення моделей, але в технічного замовника залишаються чотири сумніви: чи не почне агент вигадувати відповіді, де лежать дані, що буде при розставанні з підрядником і чи зможе команда змінювати логіку власними силами. Нижче — як кожен із них знімається на рівні конфігурації, а не обіцянок.
Як ви контролюєте якість відповідей?
Агент відповідає лише за знайденими фрагментами: в інструкції сценарію зафіксовано правило «немає джерела — немає відповіді», а низька впевненість пошуку переводить діалог на оператора.
Перед здаванням проганяємо набір типових і межових запитань для кожного підключеного джерела і вимірюємо частку відповідей із посиланням на документ — цей показник доводимо до прийнятного рівня до запуску.
Де зберігаються наші дані?
Контур розгортаємо у вашій інфраструктурі: сховище векторів, база діалогів і ключі до моделей залишаються всередині периметра, назовні йдуть лише дозволені запити.
Доступи розмежовуємо за ролями, звернення до зовнішніх моделей журналюємо, за вимогою служби безпеки модель піднімаємо локально.
Наскільки ми будемо залежати від вас?
Сценарії, інструкції, схеми сховищ і порядок розгортання передаємо у ваш репозиторій — це не закрита шухляда підрядника.
Інженер замовника проходить передачу й далі сам править логіку діалогу, додає внутрішні регламенти та бази знань, змінює розклад переіндексації, щоб відповіді спиралися на актуальні версії документів.
Обговоримо завдання: що надіслати й що уточнити
Щоб оцінка була предметною, а не «на око», нам достатньо кількох вступних даних. Нижче — короткий список того, що допомагає швидше перейти від обговорення завдання до плану робіт.
- Сценарій. Які запитання ставить користувач і що має отримати на виході: відповідь у чаті, готовий документ, посилання на першоджерело або дію в обліковій системі.
- Джерела даних. Де лежать знання — база, файлове сховище, портал, регламенти; у якому вигляді (текст, таблиці, скани), який обсяг і хто відповідає за актуальність.
- Доступи. Хто ставить запитання й які відповіді кому видно, чи є персональні дані, чи потрібен закритий контур. Для пілота достатньо облікового запису з правами лише на читання.
- Обсяги та динаміка. Скільки документів і звернень на день, як часто змінюється контент — від цього залежить схема оновлення індексу та навантаження на підтримку.
- Критерій успіху. Частка відповідей із посиланням на джерело, час відповіді, частка звернень, закритих без участі людини, — за ними будемо рахувати результат пілота.
- Обмеження. Вимоги служби безпеки, терміни, готовність виділити тестовий контур і людей з боку бізнесу на приймання.
Частину пунктів закриваємо під час дзвінка, частину достатньо надіслати текстом або посиланням на приклад. Опишіть завдання у зручній формі — повернемося з оцінкою, складом робіт і термінами етапів.
