PAL

Коротко

PAL лучше всего работает, когда:

• задача легко описывается словами, но плохо считается "в уме";
• нужно пройти по условиям, циклам или нескольким формулам;
• важна воспроизводимость результата;
• вы готовы выполнять безопасный код в песочнице.

Используй PAL. Прочитай задачу и напиши короткую Python-программу, которая её решает.

На складе 180 товаров. 35% продали в понедельник, затем завезли ещё 24 единицы, потом 18% от текущего остатка зарезервировали под корпоративный заказ. Сколько осталось доступно для обычной продажи?

inventory = 180
sold_monday = inventory * 0.35
remaining = inventory - sold_monday
remaining += 24
reserved = remaining * 0.18
available = remaining - reserved
print(available)

PAL стоит включать там, где задача уже похожа на маленький алгоритм.

Чем PAL отличается от Program of Thoughts

PAL и Program of Thoughts близки, но акцент у них разный.

• PAL сильнее тяготеет к схеме "натуральный язык -> программа -> исполнение".
• Program of Thoughts допускает более смешанный формат, где reasoning и код могут чередоваться.

На практике PAL обычно выбирают, когда вы хотите получить именно исполнимую программу как главный артефакт, а не просто код как часть рассуждения.

Когда PAL даёт наибольшую пользу

PAL особенно силён в четырёх типах задач:

1. арифметика и word problems;
2. правила с ветвлениями if/else;
3. преобразование таблиц и списков;
4. небольшие симуляции и бизнес-логика.

Если в задаче есть повторяющиеся операции, условные переходы или накопление промежуточного состояния, PAL обычно надёжнее текстового reasoning.

Практический паттерн промпта

PAL плохо работает, если вы просто говорите "реши через Python". Лучше сразу задать рамку:

Где техника переоценена

PAL не универсален.

• Если задача опирается на свежие факты, нужен retrieval.
• Если задача про стиль, тон или объяснение, код только усложнит путь.
• Если решение не переводится в чёткие операции, модель будет генерировать псевдокод без пользы.

Отдельная ошибка команд: пытаться через PAL решить проблему плохого понимания условий. Код помогает считать, но не спасает, если задача изначально неверно интерпретирована.

Что меняется в 2026

Сегодня PAL важен не как "хак из эпохи раннего prompting", а как хороший шаблон маршрутизации. Во многих продуктах уже есть sandbox, code interpreter, SQL-engine или python-runner. PAL просто даёт модели дисциплину: сначала переведи задачу в программу, потом исполни.

Отсюда и современная роль техники:

• не заменять все ответы кодом;
• а использовать PAL как отдельный route для algorithmic tasks.

Хорошая стратегия выглядит так:

• text-only reasoning для простых объяснений;
• scratchpad для коротких промежуточных шагов;
• PAL для исполнимой бизнес-логики и вычислений;
• RAG + verification для knowledge-heavy задач.

Где PAL особенно окупается

Техника хорошо показывает себя в:

• финмоделях;
• расчёте unit-экономики;
• проверке тарифов и скидок;
• аналитических мини-скриптах;
• text-to-SQL и data transformation;
• задачах по расписаниям, слотам и ограничениям.

Именно там PAL выигрывает у обычного CoT не только по качеству, но и по аудируемости. Команда может посмотреть на сгенерированную программу и быстро понять, где модель ошиблась.

Главный риск

Риск PAL не в арифметике, а в ложном ощущении надёжности. Если модель неправильно поняла бизнес-правило и аккуратно закодировала неправильную логику, runtime честно исполнит ошибку.

Поэтому PAL лучше комбинировать с:

• unit tests на типовые кейсы;
• валидацией входных параметров;
• несколькими golden examples;
• отдельной проверкой граничных случаев.

Техническая реализация

const palPrompt = `
Прочитай задачу и напиши короткую Python-программу, которая её решает.

Требования:
- только безопасные базовые конструкции;
- финальный ответ выведи через print();
- не объясняй решение длинным текстом.

Задача:
${task}
`

Практический production-паттерн: хранить для PAL не только финальный ответ, но и сам код, stdout и входные параметры. Это сильно упрощает дебаг, когда пользователь спрашивает, почему система посчитала именно так.