Пайплайн из 50 нод n8n внешне выглядел рабочим. На деле — молча падал на части запросов, и узнал я об этом не из логов, а после письма клиента: «результат пустой».
Речь про генератор комментариев для медиа. n8n берёт новость, пишет комментарий от лица клиента, целится в 1500 символов. Всё кажется прозрачным, пока не пытаешься понять, куда уходит половина запросов.
Первое, что всплыло — тихие ошибки. Если в n8n нода падает без Error Trigger, пайплайн замирает в статусе "processing" и молчит. Нет коллбэка, нет алерта — клиент ждёт, а пайплайн просто висит. Решил это просто: поставил Error Trigger, добавил retry на слабых местах и ввёл клиентский таймаут в 5 минут. Теперь хотя бы понятно, где сыплется.
Но интересное началось дальше. Оказалось, LLM не умеет считать символы. Просил Claude Sonnet: "сделай ровно 1500 символов" — получал 1129, терялись целые абзацы. GPT-5-nano выдавал 3432 символа, проигнорировав ограничение. Оба — без ошибок, API возвращает 200, pipeline считает задачу завершённой. Проблема в токенизации: LLM работает с subword tokens (BPE, WordPiece), а не с символами. Для модели "символ" — абстракция, не единица счёта. RLHF-обучение добавляет verbosity bias: длинный ответ модели предпочитают, коротким инструкциям сопротивляются даже при явных ограничениях.
Решение оказалось не в промпте, а в структуре. Я стал оборачивать каждый абзац на входе в теги: [P1]...[/P1], [P2]...[/P2] и так далее, и просил модель сохранять их в выводе. Теперь теги якорят текст — модель не может выбросить блок, не нарушив структуру. После этого Claude и GPT перестали терять абзацы. Счёт символов по-прежнему неидеален — модель не считает, — но структура не разваливается, и это главное.
Суть такая: если LLM не может выполнить инструкцию напрямую (как с подсчётом символов), надо менять саму задачу и давать структуру, которую модель способна удержать. Промпт-инжиниринг не обходит архитектурные ограничения, но правильная разметка входа решает настоящую проблему.
#ИИ #n8n #Debugging #LLM #AIAgents #Автоматизация
Речь про генератор комментариев для медиа. n8n берёт новость, пишет комментарий от лица клиента, целится в 1500 символов. Всё кажется прозрачным, пока не пытаешься понять, куда уходит половина запросов.
Первое, что всплыло — тихие ошибки. Если в n8n нода падает без Error Trigger, пайплайн замирает в статусе "processing" и молчит. Нет коллбэка, нет алерта — клиент ждёт, а пайплайн просто висит. Решил это просто: поставил Error Trigger, добавил retry на слабых местах и ввёл клиентский таймаут в 5 минут. Теперь хотя бы понятно, где сыплется.
Но интересное началось дальше. Оказалось, LLM не умеет считать символы. Просил Claude Sonnet: "сделай ровно 1500 символов" — получал 1129, терялись целые абзацы. GPT-5-nano выдавал 3432 символа, проигнорировав ограничение. Оба — без ошибок, API возвращает 200, pipeline считает задачу завершённой. Проблема в токенизации: LLM работает с subword tokens (BPE, WordPiece), а не с символами. Для модели "символ" — абстракция, не единица счёта. RLHF-обучение добавляет verbosity bias: длинный ответ модели предпочитают, коротким инструкциям сопротивляются даже при явных ограничениях.
Решение оказалось не в промпте, а в структуре. Я стал оборачивать каждый абзац на входе в теги: [P1]...[/P1], [P2]...[/P2] и так далее, и просил модель сохранять их в выводе. Теперь теги якорят текст — модель не может выбросить блок, не нарушив структуру. После этого Claude и GPT перестали терять абзацы. Счёт символов по-прежнему неидеален — модель не считает, — но структура не разваливается, и это главное.
Суть такая: если LLM не может выполнить инструкцию напрямую (как с подсчётом символов), надо менять саму задачу и давать структуру, которую модель способна удержать. Промпт-инжиниринг не обходит архитектурные ограничения, но правильная разметка входа решает настоящую проблему.
#ИИ #n8n #Debugging #LLM #AIAgents #Автоматизация