FABLE - Бенчмарк анализа потоков данных для процедурного текста для оценки больших языковых моделей.

Исследователи создали бенчмарк FABLE, чтобы проверить, насколько хорошо большие языковые модели (LLM) справляются с отслеживанием изменений состояний объектов в пошаговых инструкциях (рецептах, маршрутах, планах). Они адаптировали для этого классические методы анализа из программирования, где нужно следить, как меняются переменные в коде. Результаты показали, что большинство моделей, включая специализированные на коде и универсальные, справляются с этой задачей на уровне случайного угадывания, что выявляет их фундаментальную слабость.

LLM не обладают надежной способностью отслеживать "потоки данных" — то есть, как сущности (ингредиенты, местоположения, условия) изменяются, появляются и используются на протяжении длинной последовательности действий.

Суть исследования в том, чтобы доказать: LLM — не человек и не компьютерная программа. У них нет встроенной "оперативной памяти" для точного отслеживания состояния переменных. Когда вы даете LLM рецепт, она не "представляет" себе миску, в которую вы сначала положили муку, а потом добавили яйца. Она видит лишь последовательность слов, и связь между "мукой" из шага 1 и "смесью" из шага 5 для нее вероятностная, а не детерминированная.

Это называется проблемой "рассуждения о потоках данных" (data-flow reasoning). Модель может легко потерять контекст или перепутать состояния. Например, если в плане путешествия на 1-3 день бюджет высокий, а на 4-5 — низкий, модель может с легкостью предложить дорогой ресторан на 5 день, "забыв", что состояние переменной "бюджет" изменилось.

Практическая методика, вытекающая из исследования:

Поскольку LLM не может надежно удерживать состояние в "уме", пользователь должен стать для нее "внешней памятью". При формулировании сложных, многошаговых задач, где меняются важные параметры, необходимо явно напоминать модели об их текущем состоянии в момент выполнения конкретной подзадачи. Нельзя полагаться на то, что модель "помнит" условия, заданные 5-10 шагов назад.

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

*Прямая применимость:Пользователь не может использовать сам бенчмарк FABLE, но может немедленно начать применять главный вывод из исследования. Это выражается в изменении подхода к написанию промптов: вместо неявного ожидания, что модель всё помнит, пользователь начинает явно прописывать ключевые состояния и ограничения для каждой конкретной подзадачи внутри большого промпта.

• Концептуальная ценность: Огромна. Исследование дает пользователю мощную концептуальную рамку: "LLM плохо справляется с отслеживанием потоков данных". Это объясняет множество ошибок и неконсистентных ответов в сложных задачах и позволяет перейти от метода "проб и ошибок" к осознанному проектированию промптов, которые минимизируют эту слабость модели.

Метод адаптации прост и универсален. Для любой задачи, будь то планирование, анализ текста или генерация контента, нужно мысленно выделить "переменные" (ключевые сущности, их свойства, ограничения) и перед каждым новым шагом генерации явно "освежать" их значения для модели. Например, вместо "Продолжай" писать: "Отлично, теперь, учитывая, что у нас есть [состояние А] и [ограничение Б], сделай следующее...".

Представим, что вы SMM-менеджер и планируете многоэтапную рекламную кампанию.

# РОЛЬ

Ты — опытный маркетолог, специализирующийся на digital-кампаниях в социальных сетях.

# КОНТЕКСТ

Я разрабатываю трехэтапную кампанию по запуску нового мобильного приложения для медитации "Тишина". У каждого этапа своя цель и своя аудитория.

# ЭТАПЫ КАМПАНИИ

1. **Этап 1 (Осведомленность):**

- **Цель:** Рассказать о приложении как можно шире.
- **Аудитория:** Широкая, мужчины и женщины 20-45 лет, интересующиеся саморазвитием и борьбой со стрессом.
- **Ключевое сообщение:** "Найди свою тишину в большом городе".
2. **Этап 2 (Вовлечение):**

- **Цель:** Побудить тех, кто видел рекламу, попробовать бесплатную версию.
- **Аудитория:** Сужается до тех, кто взаимодействовал с рекламой на Этапе 1. Это уже "теплая" аудитория.
- **Ключевое сообщение:** "7 дней медитаций бесплатно. Почувствуй разницу".
3. **Этап 3 (Конверсия):**

- **Цель:** Мотивировать пользователей бесплатной версии купить подписку.
- **Аудитория:** Узкая, только те, кто установил приложение и пользуется бесплатной версией. Это "горячая" аудитория.
- **Ключевое сообщение:** "Продолжи свой путь к гармонии. Получи доступ ко всем практикам".

# ЗАДАЧА

Напиши короткий, убедительный рекламный текст для поста в Instagram, нацеленного на **аудиторию Этапа 3**.

**ВАЖНО! Напоминаю ключевые условия для этой задачи:**
- **Состояние аудитории:** Эти люди уже знают о приложении "Тишина" и установили его. Они уже попробовали бесплатные медитации. Не нужно им снова представлять продукт.
- **Цель текста:** Не просто рассказать, а убедить купить платную подписку.
- **Эмоциональный тон:** Поддерживающий, вдохновляющий, подчеркивающий ценность полного курса практик.

Этот промпт эффективен, потому что он напрямую решает проблему "data-flow", выявленную в исследовании.

1. Явное указание состояния (State Declaration): Вместо того чтобы надеяться, что LLM сама проанализирует три этапа и поймет, к кому обращаться, мы явно прописываем это в блоке ВАЖНО! Напоминаю ключевые условия.... Фраза Состояние аудитории: Эти люди уже знают о приложении... — это прямое предоставление модели финального, релевантного состояния "переменной" (аудитории) перед выполнением задачи.
2. Минимизация логических скачков: Мы не заставляем модель "рассуждать" и делать вывод о том, что раз это Этап 3, то аудитория уже "горячая". Мы даем ей этот вывод как факт. Это снижает когнитивную нагрузку на LLM и предотвращает ошибку, когда она могла бы сгенерировать текст для широкой аудитории с Этапа 1.
3. Структурирование контекста: Разделение на КОНТЕКСТ, ЭТАПЫ и ЗАДАЧА помогает модели лучше организовать информацию, но именно блок ВАЖНО! является ключевым элементом, который страхует от ошибки "потока данных".

Планирование персональной диеты и тренировок на неделю.

# РОЛЬ

Ты — сертифицированный диетолог и фитнес-тренер.

# КОНТЕКСТ

Я хочу составить план питания и тренировок на 5 дней. У меня есть специфические условия, которые меняются в течение недели.

# ПЛАН НА НЕДЕЛЮ

- **Дни 1-2 (Понедельник, Вторник):**- **Питание:** Низкоуглеводное, фокус на белок и овощи. Калорийность ~1800 ккал.
- **Тренировки:** Силовые, в тренажерном зале.
- **День 3 (Среда):**- **Питание:** Сбалансированное, добавляем сложные углеводы (гречка, рис). Калорийность ~2200 ккал ("рефид").
- **Тренировки:** Отдых или легкое кардио (прогулка).
- **Дни 4-5 (Четверг, Пятница):**- **Питание:** Снова низкоуглеводное, как в дни 1-2. Калорийность ~1800 ккал.
- **Тренировки:** Высокоинтенсивные интервальные тренировки (HIIT).

# ЗАДАЧА

Предложи три варианта ужина на **четверг (День 4)**.

**Ключевые ограничения для этой задачи:**
- **Тип питания на этот день:** Строго низкоуглеводное. Без круп, хлеба, сахара, сладких фруктов.
- **Калорийность:** Ужин должен вписываться в общую дневную калорийность ~1800 ккал, то есть быть умеренным.
- **Контекст тренировки:** В этот день у меня была или будет высокоинтенсивная тренировка, поэтому ужин должен быть богат белком для восстановления мышц.

Этот промпт работает по тому же принципу компенсации слабого "data-flow reasoning" у LLM.

1. Фиксация текущего состояния: План на неделю содержит три разных состояния для переменной "Тип питания". Вместо того чтобы заставлять модель искать в тексте, какой режим питания соответствует четвергу, мы явно указываем это в Ключевых ограничениях: Тип питания на этот день: Строго низкоуглеводное.
2. Предотвращение путаницы: Без этого явного напоминания модель с высокой вероятностью могла бы "посмотреть" на соседний день (среду) и предложить ужин с рисом или гречкой, совершив ошибку "потока данных". Мы исключаем эту возможность, предоставляя ей только релевантную информацию.
3. Консолидация контекста: В блоке ограничений мы не только напоминаем про диету, но и связываем ее с другим параметром — тренировкой (В этот день у меня была ... тренировка). Это помогает модели сгенерировать более целостный и релевантный ответ (ужин, богатый белком), так как все необходимые для принятия решения "переменные" (диета=низкоуглеводная, тренировка=интенсивная) предоставлены ей в одном месте и в актуальном состоянии.

• A. Релевантность техникам промтинга: Низкая. Исследование не предлагает конкретных формулировок или паттернов для промптов. Оно использует промпты для тестирования моделей, а не для обучения пользователей.
• B. Улучшение качества диалоговых ответов: Косвенное. Понимание выявленных в работе ограничений LLM помогает пользователю формулировать запросы так, чтобы избежать ошибок модели, тем самым повышая качество ответов.
• C. Прямая практическая применимость: Низкая. Пользователь не может напрямую использовать бенчмарк FABLE. Практическая польза извлекается через осмысление выводов и адаптацию своего стиля написания промптов.
• D. Концептуальная ценность: Очень высокая. Исследование вводит и доказывает критически важную концепцию — «рассуждение о потоках данных» (data-flow reasoning). Оно наглядно демонстрирует, что LLM плохо отслеживают изменения состояния объектов (ингредиентов, переменных, условий) на протяжении последовательности шагов. Это фундаментальное знание о "слепых зонах" LLM.
• E. Новая полезная практика (кластеризация):
  • Кластер 2 (Поведенческие закономерности LLM): Да. Основная ценность работы — демонстрация системной слабости LLM в отслеживании состояния сущностей в процедурном тексте.
  • Кластер 6 (Контекст и память): Да. Работа напрямую исследует, как модели используют (или не используют) информацию из предыдущих шагов контекста для ответа на вопрос о текущем шаге.
  • Кластер 7 (Надежность и стабильность): Да. Понимание этой слабости позволяет пользователю создавать промпты, которые снижают вероятность "галлюцинаций", связанных с забыванием или путаницей в состояниях объектов.
• Чек-лист практичности (+15 баллов):
  • Раскрывает неочевидные особенности поведения LLM? ДА. Это ключевая ценность статьи. Она формализует и доказывает то, что многие пользователи чувствовали интуитивно: LLM "забывают" детали из начала длинного текста. Это дает +15 баллов к базовой оценке.

Исследование получает высокую оценку 85/100, так как оно предоставляет фундаментальное концептуальное знание о ключевом ограничении LLM, которое напрямую влияет на успешность сложных промптов. Хотя работа не дает готовых "рецептов", она объясняет, почему многие промпты, требующие отслеживания изменений, проваливаются. Это знание позволяет опытному пользователю перейти на новый уровень понимания и сознательно конструировать более надежные запросы.

Аргументы за оценку: 1. Объяснение "почему не работает": Статья дает научное обоснование частой проблемы, когда LLM "забывает" или путает условия, заданные в начале промпта, при генерации конца ответа. Это позволяет пользователю перестать винить "глупость" модели и начать работать с ее системным ограничением. 2. Формирование "ментальной модели": Понимание концепции "data-flow" помогает сформировать правильную ментальную модель LLM — не как разумного агента с памятью, а как мощного, но "забывчивого" обработчика последовательностей, для которого пользователь должен выступать в роли "внешней памяти". 3. Универсальность вывода: Проблема отслеживания состояния универсальна и проявляется в любых задачах: от планирования путешествий и написания кода до создания маркетинговых кампаний и анализа документов.