Dify с Ollama: как собрать локальный RAG-пилот и проверить ответ

Какой результат должен получиться?

Создайте маленький документ с вымышленным фактом, например «В тестовой инструкции версии A-17 код проверки — ЯНТАРЬ». Задайте вопрос о коде и второй вопрос, ответа на который в документе нет. Пилот проходит только если поиск возвращает нужный фрагмент для первого вопроса, ответ совпадает с текстом источника, а на второй вопрос система не выдаёт уверенную выдумку. Это план проверки, не измерение качества модели и не гарантия безопасности.

Маршрут: тестовый документ → embedding-модель Ollama → индекс базы знаний Dify → поиск нужного фрагмента → chat-модель Ollama → ответ с проверяемой ссылкой на источник. Плагин Dify отдельно настраивает Chat и Text Embedding; в Knowledge Retrieval результаты поступают в контекст последующего LLM-узла s1 s3 s6.

Что подготовить до подключения?

Нужны отдельный тестовый экземпляр Dify, работающая Ollama, две выбранные локальные модели — для диалога и для embeddings — и файл без персональных данных. Официальный Docker Compose Dify запускает не один контейнер, а несколько основных и зависимых сервисов; проверьте статус через docker compose ps и завершите настройку администратора до теста. Документация Dify указывает системные требования для платформы (от 2 CPU и 4 GiB RAM), но это не минимум памяти для вашей chat- или embedding-модели: их параметры и размещение проверяются отдельно s2 s1.

Для Dify используйте закреплённый релиз из официальной инструкции, скопируйте docker/.env.example в docker/.env, поднимите docker compose up -d из каталога docker и проверьте состояние всех сервисов через docker compose ps. Выход init_permissions после однократной настройки ожидаем. Неподготовленный Docker Compose и открытый в интернет административный интерфейс не следует считать защищённым корпоративным развёртыванием s2.

На стороне Ollama сначала проверьте фактический список локальных моделей запросом к /api/tags; в API Ollama указаны отдельные endpoints для генерации, списка моделей и embeddings. Не выбирайте облачный тег в предположении, что название провайдера гарантирует локальность, и не приписывайте размеру скачанных весов смысл системного требования s8 s1. Если модель для embeddings отсутствует, официальный README плагина приводит ollama pull embeddinggemma как пример загрузки; это не обещание качества для русского корпуса — проверяйте на своём наборе s1.

Как подключить Ollama к Dify без ошибки адреса?

В Dify откройте Integrations → Model Provider, установите официальный Ollama-плагин из Marketplace и добавьте выбранную chat-модель. Затем добавьте отдельную модель типа Text Embedding и назначьте её в Default Models как Embedding Model, если приложение использует настройку по умолчанию. Тип модели и точное имя должны совпадать с тем, что действительно доступно в Ollama; Dify различает default reasoning и embedding models s3 s1.

Укажите Base URL корня хоста вида http://<доступный-хост>:11434, без /api: плагин сам добавляет /api/chat, /api/generate или /api/embed. Адрес должен быть доступен из контейнера Dify, а не только из браузера автора. localhost внутри контейнера Dify не равен localhost машины с Ollama; README плагина предлагает достижимый host address, например host.docker.internal или адрес локальной сети, но конкретный адрес нужно проверить в своей Docker-схеме. Локальный Ollama не требует облачного API-ключа; для Ollama Cloud плагин требует ключ, а облако здесь не является частью пилота s1.

Если Dify сообщает connection refused, не отключайте защиту и не публикуйте Ollama API наружу. Сначала сверяйте: процесс Ollama, порт, адрес из сети контейнера, правила доступа и фактический URL без повторённого /api. Исправление сетевого пути не равняется доказательству отсутствия других исходящих соединений s1 s8.

Как проверить базу знаний до ответа модели?

В Knowledge → Create сделайте готовую базу знаний и загрузите только тестовый файл. Посмотрите предварительную разбивку на фрагменты, задайте режим индексации и дождитесь завершения обработки. Для этих шагов Dify отдельно описывает upload, chunk settings, indexing и статус обработки; успешная загрузка файла ещё не означает успешный поиск s4.

Откройте Retrieval Testing и введите вопрос «Какой код проверки указан для A-17?». Сохраните точный запрос, найденный фрагмент, заголовок документа и использованные параметры. Затем спросите о несуществующем коде B-99. Если нужный фрагмент не найден, меняйте разбиение, индекс или настройки поиска и повторяйте тест; настройка, изменённая в Retrieval Testing, временная и не переносится в приложение автоматически s5 s4. Не называйте отсутствие релевантного фрагмента «галлюцинацией LLM»: на этом этапе ошибается или пустует поиск, модель ещё не получала правильный контекст.

Как получить ответ с проверяемым контекстом?

Для простого пилота создайте приложение Chatbot, подключите базу знаний в Context, включите Citation and Attribution и проверьте вопросы в Debug and Preview до публикации приложения — это последовательность, описанная Dify s7. Если нужен явный Chatflow, соберите User Input → Knowledge Retrieval → LLM → Answer: в Knowledge Retrieval выберите запрос и базу знаний, а переменную result передайте в Context узла LLM. В chatflow цитирование ответов по базе знаний включено по умолчанию, но может быть отключено в Features; наличие красивого ответа без проверенного result не подтверждает RAG s6.

Задайте модели ограничение: отвечать только по найденному фрагменту и прямо говорить, если данных недостаточно. Затем сравните три артефакта: текст исходного документа, выдачу Retrieval Testing или результат Knowledge Retrieval, и финальный ответ с указанием источника. Если ответ верный, но нужного фрагмента нет среди результатов, пилот не засчитывается: модель могла воспользоваться общей памятью или угадать демонстрационное слово. Повторите с другим случайным кодом, которого модель не могла знать заранее. Это собственный критерий редакции, а не документированная гарантия Dify.

Что остаётся неподтверждённым?

Положительный ответ на одном вымышленном документе не подтверждает качество русского поиска, безопасность корпоративных документов или полную офлайн-изоляцию. Плагин поддерживает локальные и облачные модели, а развертывание Dify включает отдельные сервисы и плагины; происхождение каждого вызова проверяйте в журнале и сетевом тесте, а не по слову «local» в UI s1 s2. Реальные права доступа, обновление документов, проверку цитат и отказ на запрос без ответа нужно тестировать на данных и в пределах политики организации. Modelium здесь не запускал стек и не измерял его скорость, качество или потребление памяти.

Следующий шаг: перенесите два вопроса в маленький набор с ручной разметкой релевантных фрагментов и пройдите протокол проверки качества RAG. По отдельному гайду проверки офлайн-контура можно исследовать сетевой выход, но он не заменяет оценку поиска и ответа s5 s6.