Post #541

ReAct-промпт стал монолитом Это был узел в агенте, который искал круизы и вел пользователя по процессу бронирования. Тот самый, который упоминался в посте выше. В этом агентском цикле модель должна была делать tool calls по инструкциям, а затем отвечать пользователю. Пока бронирований не было, всё работало нормально: агент искал круизы, уточнял параметры и показывал варианты. Алгоритм был достаточно простым. Потом добавилась booking-логика. Причем уже заметно сложнее: с явными состояниями, переходами и запретами. И в одном промпте оказалось сразу три ответственности: — определить бизнес-сценарий — выбрать и вызвать нужные инструменты — отформатировать ответ пользователю Сценариев становилось больше. Появлялись исключения, запреты, новые шаги логики. При этом дообучать модель мы не могли. Пошли ошибки: — неправильно определялись сценарии — пропускались шаги — игнорировались важные запреты — да, те самые, которые написаны капсом и с восклицательными знаками Проблема была в том, что один промпт пытался быть сразу planner’ом, tool executor’ом и formatter’ом. Для LLM это превращается в complex instruction following: много ограничений разного типа внутри одного вызова. Формально — один промпт. По факту — несколько задач в одном forward pass. Решение было не в том, чтобы еще раз “лучше написать промпт”. Мы разделили узел на два этапа: — planning: определить сценарий и план действий — tool execution: выполнить нужные вызовы После этого стало проще понимать, где ломается логика: на выборе сценария или на исполнении. Следующий шаг — отдельно вынести presentation logic. Главный вывод: когда промпт начинает содержать бизнес-логику, он становится кодом. А код нужно декомпозировать. Благо, на моем любимчике LangGraph это легко провернуть