1. Обзор
Первая проблема, о которой я задумался при разработке AI-системы Lakey на основе RAG (генерации с увеличением извлечения), была: «Насколько можно доверять ответам LLM?»
На начальном этапе разработки мы просто настроили поиск документов и создание ответов с помощью LLM.
Однако, когда мы провели фактическое тестирование, начали возникать некоторые проблемы.
Наиболее характерной проблемой было явление галлюцинации. LLM иногда естественным образом генерирует информацию, которая не существует в реальных документах, или преувеличивает некоторые детали.
Особенно в реальной рабочей среде неправильные ответы не ограничиваются простыми проблемами с пользовательским опытом.
Процесс принятия решений может быть затронут, и существует вероятность неправильного выполнения работы.
Например, если ответы формируются на основе внутренних политических документов, могут возникнуть проблемы с указанием несуществующих политик или объяснением информации о прошлых политиках как актуальной.
По этой причине в проекте было решено не просто выполнять «генерацию ответов», но и добавить слой Verifier для отдельной проверки сгенерированных ответов.
То есть, была разработана структура, которая повторно проверяет результаты, сгенерированные LLM, и может фильтровать низконадежные или неверные ответы.
В проекте использовались AI-агент и инструмент автоматизации рабочего процесса n8n для реализации данной структуры.
В этой статье я постараюсь сосредоточиться на том, почему был выбран n8n, а не просто на том, как это было реализовано, а также на преимуществах и недостатках, которые мы ощутили в реальной рабочей среде.
2. Общая структура архитектуры
Система Verifier в основном состоит из следующего потока.
- Lakey AI система
- Система передачи событий на основе Kafka
- n8n Workflow
- Подпроцесс для проверки
- Ошибка рабочего процесса
- Структура возвращаемого результата
Если в системе Lakey необходимо проверить ответ, будет выпущено событие запроса на проверку через Kafka.
Это событие содержит следующую информацию.
- Вопрос пользователя
- Найденный контекстный документ
- Сгенерированный ответ LLM
- Идентификатор запроса
- Проверка метаданных
В n8n конфигурация рабочего процесса Kafka Consumer позволяет ему принимать данное событие и вызывать подсистему, выполняющую фактическую логику проверки.
Логика проверки была выделена в независимый Sub Workflow.
Причина выбора этой структуры заключается в том, что критерии проверки, вероятно, будут постоянно изменяться.
Например, может существовать такая логика проверки.
- Проверка, основана ли ответ на контексте
- Проверка наличия определенных ключевых слов
- Обнаружение запрещенных фраз
- Проверка на нарушение политики
- Расчет уровня доверия
- Проверка формата JSON
Таким образом, было возможно повысить удобство обслуживания, разделив эти потоки проверки на отдельные узлы и подпроцессы.
Также была настроена отдельная ошибка рабочего процесса.
Поскольку могли возникать различные исключительные ситуации, такие как сбой вызова LLM, ошибка соединения с Kafka, тайм-аут, ошибка разбора JSON и др.
n8n позволяет настраивать обработку ошибок на уровне рабочих процессов, поэтому в случае возникновения сбоев мы перенаправляем в отдельный Workflow ошибок для записи логов и отправки уведомлений.
В конечном итоге, после завершения проверки, результаты снова публикуются в виде событий Kafka, и система Lakey настроена на их потребление.
Итак, вся структура была спроектирована на основе архитектуры, ориентированной на события.
3. Почему был выбран n8n
В начале проекта также рассматривался способ реализации AI Workflow на базе Python.
Например, была идея создать API-сервер на основе FastAPI и обрабатывать проверки во внутреннем потоке с помощью LangChain или собственного написанного логики на Python.
Но на самом деле промпт и критерии проверки очень часто менялись.
Особенно в процессе эксплуатации возникали подобные запросы на повторной основе.
- Исправление промпта
- Добавление этапа проверки
- Обработка исключений для определенных условий
- Проверка журнала
- Изменение формата ответа
- Изменение порядка рабочего процесса
Если бы это все управлялось на основе кода, мне бы каждый раз приходилось повторять следующий процесс.
- Исправление кода
- сборка
- развертывание
- Перезагрузка сервера
- Тестирование
С другой стороны, n8n имеет структуру на основе рабочего процесса, поэтому можно было изменять узлы на пользовательском интерфейсе и сразу видеть изменения.
Эта особенность показалась мне очень большим преимуществом.
Особенно системы на базе AI Agent часто сталкиваются с быстро меняющимися требованиями. Поэтому быстрая итеративная разработка и эксперименты имеют большое значение.
n8n оказался инструментом, который отлично соответствует этим требованиям. Кроме того, n8n очень легко подключается к различным внешним системам.
Поскольку существует множество узлов, таких как Kafka, HTTP API, Slack, Redis, Database и Webhook, необходимость в написании отдельного кода коннектора практически отсутствовала.
На самом деле, в проекте мы смогли очень быстро настроить получение и публикацию событий Kafka.
Одним из преимуществ было то, что вы можете визуально представить рабочий процесс.
Поскольку сложные AI-процессы можно представить в виде узлов, операторы и другие разработчики могут легко понять весь поток.
Особенно важен AI Workflow, поскольку понимание самого процесса важнее, чем простой код, поэтому визуализация оказала значительное влияние.
В результате проект выбрал n8n из-за «большой скорости разработки» и «удобства эксплуатации».
4. Реальные преимущества, которые я почувствовал в ходе эксплуатации
Основное преимущество, которое я ощутил в процессе эксплуатации, заключалось в функциях отладки и отслеживания журналов.
В существующей кодовой базе Workflow часто было трудно определить, какие данные были созданы на определенном этапе.
В то же время в n8n можно было проверить как входные, так и выходные данные для каждого узла.
То есть, удалось отслеживать весь процесс выполнения рабочего процесса поэтапно.
Это было очень полезно, например, в следующих ситуациях.
- Проверка результатов конкретного запроса (Prompt)
- Верификация данных ответа LLM
- Анализ причин сбоя парсинга JSON
- Проверка сообщения Kafka
- Проверьте результаты условий ветвления
- Анализ таймаута конкретного узла
Особенно в системах ИИ функция проверки промежуточных данных была очень важна, поскольку результаты не всегда одинаковы. Даже в реальных операционных средах, при возникновении проблем, в большинстве случаев возможно быстро понять причину, опираясь только на журналы выполнения n8n.
Кроме того, структура минимизации кода также была преимуществом.
Если бы это был старый способ, то весь код потребовался бы для написания таких вещей, как Kafka Consumer, HTTP Client, Retry Logic и Error Handling.
Но в n8n большинство из этих задач можно было реализовать только с помощью настройки узлов. Благодаря этому скорость разработки значительно возросла, и мы смогли сосредоточиться на бизнес-логике.
Кроме того, повторное использование Workflow также было хорошим.
Например, если отдельную логику валидации выделить в виде Sub Workflow, ее можно использовать в разных Workflow.
Это было очень полезно в среде AI Workflow на основе запроса.
С точки зрения эксплуатации это также имело свои преимущества. Благодаря возможности немедленного применения после изменения рабочего процесса, скорость реакции на экстренные ситуации была весьма высокой.
Особенно удобно, что в случае, если необходимо только изменить подсказку (Prompt), это можно сделать сразу без отдельного развертывания.
5. Недостатки, которые я заметил в процессе разработки
Конечно, n8n не был идеальным инструментом во всех ситуациях. В процессе работы над реальными проектами я также столкнулся с рядом недостатков.
Первым недостатком, который я почувствовал, была сложность управления версиями.
n8n также может сохранять историю изменений, но сравнить изменения интуитивно, как это делается с помощью Git Diff в Java-коде, было сложно.
Особенно по мере усложнения структуры рабочего процесса приходилось проверять, какие настройки узлов были изменены, вручную.
Второй проблемой были проблемы с читаемостью, возникающие при сложных рабочих процессах.
Сначала узловая структура казалась очень интуитивной, но по мере увеличения размера рабочего процесса экран начал усложняться. Особенно когда становилось много условных ветвлений и повторяющейся логики, линии соединения запутывались.
Третье - это отсутствие автоматизации тестирования.
В обычной среде на основе кода можно использовать такие тестовые фреймворки, как JUnit, для настройки автоматизированного тестирования. Однако n8n изначально является инструментом, ориентированным на рабочие процессы, поэтому автоматизация тестирования на уровне кода была затруднена.
В результате нам в основном пришлось полагаться на ручное тестирование. Это могло стать обременительным по мере увеличения масштаба операций.
Еще одной проблемой была сложность масштабного рефакторинга.
Например, если изменить название определенной переменной или узла, функция рефакторинга IDE не выполняла автоматические изменения во всем проекте.
То есть, нужно было вручную находить и изменять связанные узлы. По мере увеличения масштаба рабочего процесса такие задачи казались довольно неудобными.
В конце концов, n8n очень силен в «быстром разработке», но также можно столкнуться с тем, что в очень сложных крупных системах может возникнуть уровень операционной сложности выше определенного порога.
6. Заключение
В этом проекте мы смогли подтвердить, что n8n имеет достаточный потенциал, чтобы стать не просто инструментом для автоматизации, но и платформой для AI Workflow.
В частности, требования к AI-системам меняются очень быстро.
Одна только замена подсказки может изменить качество результата, и критерии проверки часто также подлежат постоянным изменениям.
В таких условиях быстрая коррекция и мгновенное отображение имеют чрезвычайно важное значение.
n8n предоставил структуру, которая отлично соответствует этим требованиям.
Особенно в следующих ситуациях я заметил значительные преимущества.
- Повторяющееся изменение подсказок (Prompt)
- Быстрое создание экспериментальной среды
- Разнообразная интеграция систем
- Конфигурация рабочих процессов на основе событий
- Визуализация потока ИИ-агента
- Отслеживание операционных журналов
Конечно, если сложность станет чрезмерно высокой, поддерживать кодовую базу может быть сложнее. Однако, если это проект с важностью быстрого повторного разработки и автоматизации операций, я думаю, что n8n может стать очень сильным выбором.
Из этого опыта я еще раз осознал, что в AI-системах важны не только простая производительность модели, но и операционная структура и система проверки также очень важны.
В частности, слой Verifier, по моему мнению, будет играть все более важную роль в будущих AI-системах.
У меня был такой положительный опыт, что в будущем, если появятся подобные проекты AI Workflow, есть высокая вероятность повторного использования n8n.
sby