Dify — это платформа, на которой ИИ-приложение для компании собирают из готовых блоков без программирования: бота для сайта, поиск ответов по документам, обработку заявок. Модель, промпт, данные и логика диалога соединяются в визуальном редакторе, а вся связка разворачивается на сервере внутри вашего контура. Инструмент открытый, но рабочий результат зависит от сценария и качества базы знаний — число блоков на схеме здесь вторично.
Что внутри платформы
Dify соединяет четыре вещи в одном окне: выбор модели, редактор промпта, базу знаний с документами и логику диалога — и публикует результат как чат-приложение или API, который подключается к сайту, Telegram или внутреннему сервису.
Классическая разработка ИИ-функции выглядит так: программист пишет код под API модели, прикручивает загрузку документов, делает веб-форму — и на каждую правку его зовут снова. Dify убирает из этой цепочки код: аналитик или руководитель отдела сам собирает приложение мышкой, проверяет на реальных вопросах и правит промпт без участия разработчика.
Под капотом — те же компоненты, что в ручной разработке: подключение к языковой модели, векторный поиск по документам, память диалога, журнал запросов. Разница в упаковке: всё это уже собрано и настраивается через веб-интерфейс, а изменения видны сразу, без выкатки новой версии сервиса.
В команде роли при таком подходе делятся понятно: владелец процесса описывает сценарий и принимает результат, аналитик собирает и настраивает приложение, администратор следит за сервером. Программист нужен точечно — на первом развёртывании и нестандартных интеграциях.
Что собирают без кода
Три сценария закрывают большинство запросов малого и среднего бизнеса.
- Бот-консультант на сайте или в Telegram: отвечает на типовые вопросы клиентов по базе знаний компании
- Поиск по документам: регламенты, инструкции, каталоги — сотрудник спрашивает своими словами, приложение находит ответ с цитатой из документа
- Обработка заявок: форма принимает обращение, модель извлекает суть, ставит категорию и готовит черновик ответа менеджеру
Второй пункт — это механика RAG, разобранная в статье про базу знаний для компании: документы индексируются, ответ строится на найденных фрагментах, а модель лишь формулирует его человеческим языком.
- Описать сценарий: кто спрашивает, что отвечает приложение, где граница ответа
- Загрузить документы в базу знаний и проверить качество поиска по ним
- Написать системный промпт и прогнать двадцать реальных вопросов из почты отдела
- Подключить канал — виджет на сайт или Telegram-бота — и открыть доступ пилотной группе
Прогон на реальных вопросах — обязательный этап, его называют золотым набором: двадцать реальных вопросов из почты отдела с правильными ответами, выверенными владельцем процесса. Каждую правку промпта и пополнение базы проверяют на этом наборе заново: улучшение ответа на один вопрос ломает ответы на трёх других чаще, чем кажется.
Свой хостинг
Dify — открытый проект, и его рабочее место для компании выглядит одинаково: сервер в вашем контуре, развёртывание через Docker, доступ для сотрудников из офисной сети или по защищённому каналу. Документы и история запросов при такой схеме физически лежат у вас.
Модель к приложению подключается двумя путями. Первый — локальная модель на своём сервере, например через Ollama: запуск разобран в статье про локальную модель для компании, тогда в контуре остаются и данные, и сами ответы. Второй — API внешнего вендора: тексты запросов уходят наружу, и этот вариант требует отдельного решения про данные.
Если сценарий понятен, а рук на развёртывание и поддержку в контуре нет, приходите на страницу про внедрение ИИ в компании: поднимем платформу на вашем сервере, соберём первое приложение и передадим регламент обновлений.
Эксплуатация платформы — привычный набор: резервные копии базы знаний и настроек, обновления сначала на тестовой копии, контроль места на диске. База документов растёт быстро, особенно когда отделы начинают грузить архивы «на всякий случай», — квоты на коллекции экономят и место, и нервы администратора.
Где границы
Конструктор закрывает типовые сценарии, но у него есть край. Как только логика выходит за рамки блоков — хитрая интеграция с учётной системой, собственный алгоритм расчёта, нестандартная выгрузка — приложение требует код, и дальше работает программист, а редактор остаётся оболочкой.
Второй предел — нагрузка. Пропускная способность связки зависит от модели, железа и настроек, поэтому перед выводом на весь отдел её гоняют нагрузочным тестом, а лимиты сверяют с документацией выбранной версии. Обновления платформы — тоже отдельная работа: версии выходят часто, и накатывать их без проверки на копии рискованно.
Третий предел — экономика. Полная стоимость контура складывается из сервера, модели, времени на сборку и сопровождение: конструктор убирает из сметы разработку, зато остальные части остаются. Поэтому экономику считают до пилота, сравнивая с ручным процессом, а после пилота пересчитывают по факту.
Поэтому перед сборкой полезно честно ответить себе: задача у нас типовая или с сюрпризами.
Какой процесс вы бы отдали ИИ-приложению первым?
Dify и n8n
Частый вопрос — чем Dify отличается от n8n, ведь оба рисуют стрелочки между блоками. Отвечаем по сути: n8n автоматизирует потоки между сервисами — почта, таблицы, CRM, уведомления, — а Dify собирает само ИИ-приложение: модель, промпт, данные, диалог. Инструменты соседние, и в реальных контурах они дружат: n8n переносит данные и запускает события, Dify думает над содержанием.
| Задача | Инструмент | Почему он |
|---|---|---|
| Переслать заявку из формы в CRM и уведомить менеджера | n8n | Поток между сервисами без диалога с клиентом |
| Бот, отвечающий по базе знаний | Dify | Ядро — модель плюс документы, цепочка шагов короткая |
| Заявка, разбор моделью, письмо клиенту, задача в CRM | Оба вместе | n8n ведёт процесс, Dify обрабатывает текст |
В зрелых контурах связка выглядит так: n8n следит за почтой и формами, передаёт обращение в Dify, получает структурированный разбор и раскладывает результат по CRM и мессенджерам. Граница ответственности ясная: за транспорт отвечает n8n, за смысл — Dify, за решение — человек.
Справедливости ради: есть задачи, где Dify избыточен. Разовый вопрос к модели решается в обычном чате, а прямая пересылка данных между двумя сервисами — в n8n. Конструктор окупается там, где приложением пользуются регулярно и его нужно менять без разработчика.
Возьмите один канал и один сценарий: например, бота, который отвечает на пять самых частых вопросов клиентов из вашей почты. Замерьте долю обращений, закрытых без менеджера, — эта цифра решит, расширять контур или пересобирать сценарий.