Безопасный интеллект: как подружить Drupal с Ollama

Ollama – это open source платформа для локального развертывания и запуска больших языковых моделей (LLM) без отправки данных на сторонние серверы.

Мы в Initlab используем Ollama для автоматизации задачи категоризации тикетов, саммаризации логов в нашем хелпдеске на Drupal. Ollama в нашем случае помогает выполнять всю обработку данных в LLM на нашем выделенном сервере без привлечения сторонних сервисов и отправки чувствительных данных в облако. В статье описан наш опыт внедрения Ollama через NoCode конструктор бизнес-процессов ECA, опыт использования различных LLM для автоматизации работы нашей поддержки, даны примеры промптов. Аналогичный подход может быть использован для автоматизации работы с помощью локальных LLM на любых других платформах, например CRM Битрикс 24 и AMO CRM, 1C: Предприятие и т.д.

Опустим детали установки и настройки LLM-сервера и Ollama и остановимся на том как она может быть интегрирована и использована вместе с Drupal.

Для интеграции Ollama с Drupal мы используем модуль Ollama Provider, который в свою очередь интегрирован с основным модулем AI. Модуль определяет одноимённого провайдера моделей, реализуя интерфейс из основного модуля, а также предоставляет API для прямого взаимодействия с сервером Ollama.

На момент написания модуль имеет версию 1.2.0-rc2 (Release Candidate) и не содержит критических ошибок.

Ollama Provider не настолько популярный модуль как, например, OpenAI Provider, что можно видеть по числу установок. Однако, учитывая темпы развития AI модулей в Drupal, активных обновлений стоит ожидать и в этом случае. Тем не менее, для адаптации модуля под наши нужны нам потребовалось написать два патча:

1. ai_provider_ollama/issues/3570300 - дополнительные настройки подключения. Добавляет возможность указания дополнительных HTTP заголовков для запроса, а также возможность игнорирования SSL сертификата при подключении в целях тестирования. Данный патч опционален в общем случае и его необходимость зависит от особенностей настройки самой Ollama и сервера, на котором она развёрнута.
2. ai_provider_ollama/issues/3571947 - улучшения и исправления для процесса получения списка установленных моделей. Патч предотвращает частые запросы к Ollama API, а вместо состояний использует кэш для хранения полученного списка. Также патч исправляет логическую ошибку в одном из методов провайдера, которая приводит к ошибкам вида «модель не найдена».

После сохранения и успешного подключения будут загружены доступные модели, они отобразятся в разделе расширенных настроек.

В процессе разработки мы тестировали две модели:

• GLM-4.7-Flash - мультимодальная языковой модель от компании Zhipu AI, оптимизированная для высокой скорости работы и эффективности при сохранении интеллектуальных возможностей.
• T-lite-it-2.1 - языковая модель от T-Банка, построенная на архитектуре Qwen 3 и оптимизированная для выполнения инструкций и вызова инструментов.

По результатам тестирования стало понятно, что в задачах, где не требуются сложные рассуждения, модель T-lite-2.1 является лучшим выбором по соотношению качества ответа к времени его генерации. Модель GLM-Flash, в свою очередь, планируем в дальнейшем тестировать в более комплексных задачах.

Пожалуй, основным достоинством модели T-lite-2.1 является её способность точно и последовательно выполнять заданные инструкции. Это особенно важно при встраивании модели в виде компонента системы для решения задач автоматизации без фактического общения с реальным пользователем. На первый план здесь выходит не столько точность итогового ответа, сколько его соответствие определённому формату, который ожидают другие компоненты системы. В рамках модели T-lite-2.1 основное внимание разработчиков как раз было уделено этому моменту.

Мы не стали отдельно экспериментировать с параметрами генерации и воспользовались рекомендуемыми параметрами, указанными в описании модели.

Результат работы модели при решении задачи категоризации тикета при тестировании в интерфейсе модуля AI API Explorer. В качестве альтернативы можно использовать приложение Postman, запрос в этом случае можно будет настроить детальнее.

Для встраивания модели в нашу систему хелпдеска мы решили использовать надёжный и хорошо проверенный инструмент в виде модуля ECA. Благодаря интеграции с модулем AI функции искусственного интеллекта можно легко встраивать в ECA модели (не путать с ИИ моделями).

При использовании модели T-lite-2.1 в задаче категоризации нужный результат удалось получить практически сразу. Понадобилось лишь немного поэкспериментировать над промптом, в итоге остановились на следующем:

Это название задачи: «[ticket:name]»

Это описание задачи: «[ticket:field_body]»

Тебе нужно определить категорию для этой задачи. Варианты категорий: feature request, bug report, support request, content changes, undefined. Укажи в ответе только итоговую категорию задачи.

Структура промпта:

1. Входные данные.
2. Описание задачи.
3. Условия, ограничения, формат ответа.

Здесь ticket:name] и [ticket:field_body] - это стандартные токены Drupal, которые ECA поддерживает и расширяет. При использовании ИИ в связке с ECA токены позволяют создавать динамические промпты в зависимости от контекста выполняемого процесса.

В задаче суммаризации выполненных работ по тикету подбирать промпт пришлось тщательнее. Задача состоит из двух подзадач:

1. Определить категории, которые подходят задаче по смыслу.
2. Написать текстсаммари, исходя из текста самой заявки и логов разработчика о выполненных работах.

Первый подход предполагал одновременное решение обеих подзадач в рамках одного промпта. В этом случае в итоговом ответе приходится использовать уникальный разделитель, позволяющий системе разграничить подзадачи между собой.

Структура промпта:

1. Входные данные.
2. Определение разделителя.
3. Описание первой задачи (условия, ограничения, формат ответа).
4. Описание второй задачи (условия, ограничения, формат ответа).
5. Определение итогового формата вывода по обеим задачам.

Данный способ работоспособен, однако, в процессе тестирования стало понятно, что модель T-lite-2.1 лучше обрабатывает ситуации, когда запрос содержит одну конкретную задачу. В этом случае в ответах гораздо реже встречаются артефакты, явно не соответствующие входным данным. Такой подход также убирает необходимость встраивания разделителя в ответ, что упрощает обработку текста другими компонентами системы.

Как уже упоминалось выше, T-lite-2.1 хорошо понимает требования, которым должен соответствовать ответ. Пока что подбор требований представляет собой эмпирический процесс. Одна часть требований продиктована условиями задачи, вторая - особенностями системы, третья подбирается вручную для коррекции результата.

Для первой задачи мы остановились на следующих требованиях:

1. Максимальное число категорий равно 5.
2. Верни только итоговые категории, через запятую, без пояснений и лишнего текста.
3. Варианты категорий: [tags]

Токен [tags] здесь представляет собой настраиваемый список категорий, которые используются для организации задач. Как и в случае с рассмотренной ранее задачей категоризации тикета, задача выбора категорий для саммаризации описывается очень просто. Набор требований в данном случае небольшой.

Требования к ответу для второй задачи:

1. Общий объём - не более 2000 символов.
2. Выбери произвольное число предложений от 4 до 7.
3. Каждое предложение - не длиннее 20 слов.
4. Пиши короткими простыми фразами на ясном русском языке.
5. Избегай канцеляризмов, сложных оборотов и внутренних терминов.
6. Не добавляй детали, которых нет в задаче и логах.
7. Текст должен быть дружелюбным по стилю и похож на описание задачи.
8. Обязательно завершай предложение точкой.
9. Не используй md разметку и никак не выделяй ключевые слова.
10. Не используй фразу «пользовательский опыт» и производные.
11. Не называй задачу словом «Проект».
12. Не используй слово «Компания».

Кроме того, в промпте отдельно была описана структура требуемого текста:

• В начале текста описывается общая суть задачи: какая задача стояла, что делали и зачем.
• В середине текста описывается какие работы выполнены, упомяни конкретные улучшения, доработки или интеграции, но без технических деталей и без описания процесса.
• В конце текста описывается результат: какую пользу получили пользователи, заказчик или система после выполнения задачи.

Изначально структура текста содержала прямое указание сколько в каждой части текста предложений, но выяснилось, что T-lite-2.1 этим указаниям не следует. При этом, если задать общее число предложений, то новое требование соблюдается. Также, например, предложения в ответе не всегда завершались точкой, а в тексте часто присутствовали выражения «компания сделала», «компания выполнила» и т.д. Добавление соответствующих требований исправило эти проблемы.

Такие ситуации зависят от множества факторов, не все из которых известны конечному пользователю ИИ модели. К таким факторам относятся: параметры генерации, параметры обучения, содержание и особенности обучающего набора, на котором обучалась модель и т.д. Часть информации можно узнать из описания модели или её документации (при наличии). В остальных случаях остаётся прибегать к эмпирическому методу формирования промпта.

Заключение

Локальные LLM позволяют автоматизировать работу с текстовыми данными без отправки чувствительных данных на сторонние серверы: классификация и управление задачами, заявками, лидами, заказами, комментариями и т.д. При внедрении важен выбор подходящей языковой модели, промптов. В Инитлаб мы активно используем такой подход и предлагаем нашим клиентам автоматизацию, управления контентом и бизнес-процессами с помощью LLM, настройку и поддержку серверов LLM в случае, если использование облачных сервисов для этого нецелесообразно.