ИИ-анализ отзывов клиентов на своём сервере

MAATRIX

Отзывы и обращения клиентов копятся быстрее, чем кто-то успевает их читать: маркетплейсы, форма на сайте, почта поддержки, иногда телеграм-чат. Разбирать это руками — либо нанимать человека на разметку, либо смириться, что часть сигналов от клиентов вы просто не видите. Отправлять тексты с именами, телефонами и деталями заказов в облачный API тоже не всегда вариант — не для всех данных это приемлемо с точки зрения политики компании или NDA с клиентом. Ниже — рабочая связка: n8n собирает отзывы из разных источников, локальная модель на вашем сервере классифицирует тональность и тему, результат стекает в таблицу или дашборд. Все данные остаются в периметре, который контролируете вы.

Зачем анализировать отзывы локально, а не через облачный API

Тональность и тема отзыва — это задача классификации текста, а не задача, требующая топовой модели уровня GPT-4 или Claude. Для неё достаточно модели на 7-8B параметров, которая умещается на GPU среднего уровня или неплохо тянется на CPU. Три практические причины делать это локально:

• Данные не покидают сервер. Отзыв клиента часто содержит номер заказа, имя, иногда телефон — отправлять это в чужое API означает передавать персональные данные третьей стороне, что для многих компаний прямо запрещено договором или 152-ФЗ.
• Стоимость предсказуема. При потоке в тысячи отзывов в месяц счёт за облачный API становится заметной статьёй расходов, а локальная модель после разгона стоит только аренду сервера — независимо от объёма.
• Нет лимитов на скорость запросов. Пакетная обработка тысячи накопленных отзывов за ночь не упирается в rate limit провайдера.

Обратная сторона: точность локальных open-моделей в классификации тональности заметно уступает топовым закрытым моделям, особенно на неоднозначных и смешанных отзывах («доставили быстро, но товар — брак»). Дальше в статье честно разберём, где эта разница критична и как с ней жить.

Архитектура пайплайна: n8n + локальная модель + хранилище

Схема состоит из четырёх звеньев:

1. Источники — форма на сайте, webhook от площадки, ручной импорт CSV, почтовый ящик поддержки.
2. n8n — оркестратор: принимает отзыв, нормализует текст, вызывает модель, разбирает ответ, пишет результат.
3. Локальная модель через Ollama — классификация тональности (позитив / негатив / нейтрально) и темы (доставка, качество товара, цена, сервис поддержки и т.д.).
4. Хранилище отчёта — Postgres-таблица или Google Sheets, поверх которой строится дашборд или еженедельная сводка.

На сервере с 16-32 ГБ RAM и GPU от 8 ГБ VRAM (или без GPU, но тогда обработка идёт медленнее) всё это можно поднять в одном docker-compose:

version: "3.8"
services:
  n8n:
    image: n8nio/n8n:latest
    restart: unless-stopped
    ports:
      - "5678:5678"
    environment:
      - N8N_HOST=n8n.example.com
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://n8n.example.com/
      - GENERIC_TIMEZONE=Europe/Moscow
    volumes:
      - n8n_data:/home/node/.n8n

  ollama:
    image: ollama/ollama:latest
    restart: unless-stopped
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama
    # для GPU добавьте секцию deploy с nvidia runtime

  postgres:
    image: postgres:16
    restart: unless-stopped
    environment:
      - POSTGRES_DB=reviews
      - POSTGRES_USER=reviews
      - POSTGRES_PASSWORD=change_me
    volumes:
      - pg_data:/var/lib/postgresql/data

volumes:
  n8n_data:
  ollama_data:
  pg_data:

После docker compose up -d подтяните модель: docker exec -it <ollama_container> ollama pull qwen2.5:7b-instruct — для русскоязычных отзывов модели семейства Qwen2.5 и Mistral-Nemo на практике справляются с классификацией заметно лучше, чем англоцентричные модели похожего размера. Для коротких отзывов можно попробовать модель поменьше (3-4B) — она быстрее, но точность стоит проверить на своей выборке.

Подробный процесс установки n8n на VPS — в статье n8n на Ubuntu 24.04: пошаговая установка, базовые сценарии связки n8n с ИИ-агентами — в материале n8n с ИИ-агентами на своём сервере.

Сбор отзывов: webhook, формы, импорт из разных площадок

У n8n есть три типовых способа получить отзыв на вход:

Webhook-нода — самый простой вариант для формы на собственном сайте. Создаёте ноду Webhook с методом POST, форма сайта отправляет туда JSON { "text": "...", "source": "site_form", "order_id": "12345" }. n8n сразу отвечает 200 OK и передаёт данные дальше по цепочке.

HTTP Request к API площадки — если отзывы приходят с маркетплейса или сервиса отзывов с API (или экспортом), нода-триггер по расписанию (Cron, раз в час) запрашивает новые отзывы за период. Важно хранить курсор — id последнего обработанного отзыва, — чтобы не разбирать одно и то же дважды; проще всего держать его в отдельной таблице Postgres.

Импорт из почты поддержки — нода Email Trigger (IMAP) слушает ящик, куда падают обращения, и превращает каждое письмо в элемент потока.

Если площадок несколько, разумно свести их в единый формат сразу после приёма — нода Set/Edit Fields приводит все источники к одинаковой структуре (text, source, customer_id, created_at), и дальше по пайплайну идёт уже нормализованный поток.

Классификация тональности и темы: промпт и модель

Ключевая часть — нода HTTP Request к Ollama (POST http://ollama:11434/api/generate) с чётко структурированным промптом, который просит модель вернуть JSON, а не свободный текст:

Ты — классификатор отзывов клиентов. Определи тональность и тему отзыва.
Ответь ТОЛЬКО валидным JSON без пояснений, в формате:
{"sentiment": "positive|negative|neutral", "topic": "delivery|quality|price|support|other", "confidence": 0.0-1.0}

Отзыв: "{{ $json.text }}"

В теле запроса задайте "format": "json" — это заставляет Ollama гарантировать валидный JSON на выходе, что заметно упрощает парсинг дальше по цепочке и избавляет от ситуаций, когда модель вместо JSON начинает объяснять своё решение. Пример тела запроса:

{
  "model": "qwen2.5:7b-instruct",
  "prompt": "...(промпт выше с подставленным текстом)...",
  "format": "json",
  "stream": false,
  "options": { "temperature": 0.1 }
}

Низкая температура (0.1-0.2) здесь важна: для классификации не нужна креативность модели, нужна стабильность — один и тот же отзыв должен получать одинаковую метку при повторном прогоне. После HTTP Request идёт нода Code (JavaScript), которая парсит response.body в объект и выбрасывает исключение, если JSON не распарсился — такие случаи стоит откладывать в очередь "на ручную проверку", а не молча пропускать.

Поле confidence из ответа модели — это самооценка модели, а не техническая метрика точности, но на практике она полезна как фильтр: отзывы с низкой уверенностью — хороший кандидат на выборочную проверку человеком, о чём ниже.

Агрегация в отчёт: таблица, дашборд, алерты

Дальше — ветвление по результату классификации (нода Switch по полю sentiment):

• Все отзывы пишутся в Postgres построчно — сырые данные плюс метки, источник истины для дальнейшего анализа.
• Негативные отзывы дополнительно уходят алертом в Telegram или Slack — задержка в 5-10 минут не критична, но поддержка должна увидеть проблему в тот же день, а не через неделю на отчёте.
• Сводка собирается по cron (раз в сутки) отдельным workflow: SQL-запрос GROUP BY sentiment, topic, date_trunc('day', created_at) формирует агрегат, который нода Google Sheets дописывает строкой в таблицу-дашборд.

Пример SQL-схемы для хранения:

CREATE TABLE reviews (
  id SERIAL PRIMARY KEY,
  source TEXT NOT NULL,
  customer_id TEXT,
  text TEXT NOT NULL,
  sentiment TEXT,
  topic TEXT,
  confidence NUMERIC(3,2),
  created_at TIMESTAMPTZ DEFAULT now()
);

CREATE INDEX idx_reviews_sentiment ON reviews(sentiment, created_at);

Google Sheets вместо Postgres как основное хранилище — тоже рабочий вариант при потоке до нескольких сотен отзывов в день. Для большего объёма Postgres удобнее — проще строить выборки и не упираться в лимиты API Google Sheets.

Точность и ограничения: где нужна проверка человеком

Здесь стоит быть честным, а не продавать пайплайн как готовое к 100% доверию решение. Открытые модели 7-8B на задаче классификации тональности русскоязычного текста ошибаются заметно чаще закрытых топовых моделей — точную цифру называть не будем, она сильно зависит от домена, длины текста и того, насколько отзывы ироничны или содержат смешанную оценку. Единственный способ узнать реальную точность на ваших данных — прогнать через пайплайн 100-200 уже размеченных вручную отзывов и посчитать, в скольких случаях модель согласна с человеком.

Практические выводы, которые стоит заложить в процесс:

• Смешанные отзывы — слабое место. «Товар хороший, но доставка опоздала на неделю» модель может отнести и к позитиву, и к негативу в зависимости от того, что перевесило в промпте — введите отдельную метку mixed, если такие отзывы у вас частые, вместо того чтобы заставлять модель насильно выбирать одну сторону.
• Используйте confidence как фильтр для выборки. Отзывы с низкой уверенностью модели (например, ниже 0.6) — направляйте в очередь на ручную проверку, а не в автоматическую сводку без разметки.
• Не принимайте решения, влияющие на клиента напрямую, только на основе автоклассификации. Если по итогам анализа планируется что-то вроде автоматического извинения, компенсации или блокировки, финальное решение должен подтверждать человек.
• Периодически пересчитывайте точность. Раз в месяц-два берите свежую выборку из 50-100 отзывов, размечайте вручную и сверяйте с тем, что выдала модель — это единственный способ заметить, что модель "поплыла" на новом типе отзывов (например, после запуска нового продукта появилась незнакомая лексика).

Для сравнения — если у вас уже есть похожий пайплайн для документов, логика во многом пересекается со статьёй ИИ-анализ документов на своём сервере, а если задача шире — не только анализ, но и автоответы клиентам — посмотрите ИИ-поддержку клиентов на своём сервере.

Развёртывание: сервер, ресурсы и первые шаги

Для потока в пределах пары тысяч отзывов в день модели 7-8B на CPU-сервере с 8-16 ядрами и 32 ГБ RAM хватает — обработка одного отзыва займёт несколько секунд, что приемлемо для пакетного сценария. Если нужна обработка ближе к реальному времени или объём выше — берите сервер с GPU от 8-12 ГБ VRAM. Конкретные цифры по расходу RAM под разные модели Ollama — в таблице в статье Сколько RAM нужно для Ollama.

Порядок запуска: разверните сервер (RU/US/UK — по тому, откуда трафик формы и где сидит поддержка) → поднимите docker-compose из примера выше и подтяните модель → настройте n8n (триггер источника → HTTP Request к Ollama → парсинг JSON → запись в Postgres/Sheets → алерт на негатив) → прогоните 100-200 исторических отзывов с ручной разметкой и сверьте точность → включите workflow в продакшн и настройте регулярную сводку.

Если вебхук не принимает запросы или workflow подвисает на середине цепочки — разборы причин есть в статьях n8n не принимает webhook и n8n на сервере: частые ошибки и решения.

Частые вопросы