Почему естественный язык не подходит для сложного рассуждения?

Краткий тезис

Естественный язык (NL) — мощное средство коммуникации, но для сложного рассуждения он принципиально ограничен из-за логической нестрогости, семантической неоднозначности и отсутствия исполнимости. В контексте Agentic RAG агенты, полагающиеся только на NL-рассуждения, часто генерируют непроверяемые, непоследовательные или невыполнимые планы. Для надёжных многошаговых рассуждений необходимы формальные промежуточные представления — код, логические формулы, графы знаний.

1. Термин: «Сложное рассуждение» и его требования

Сложное рассуждение — это процесс, включающий несколько логических шагов, учёт ограничений, проверку гипотез и принятие решений на основе неполной информации. Примеры: математическое доказательство, планирование маршрута с несколькими условиями, отладка программы.

Ключевые требования к языку для сложного рассуждения:

• Детерминированность: один и тот же набор посылок всегда приводит к одному выводу.
• Композициональность: результат сложного выражения однозначно определяется значениями частей и правилами их комбинирования.
• Верифицируемость: возможность проверить каждый шаг рассуждения на корректность.
• Исполнимость: возможность «запустить» рассуждение как алгоритм.

Естественный язык не удовлетворяет ни одному из этих требований в полной мере.

2. Логическая нестрогость

Естественный язык не имеет явных constraints (ограничений) на форму высказываний. В нём отсутствуют:

• Формальные правила вывода (modus ponens, резолюция).
• Явные кванторы (∀, ∃) — их роль играют неоднозначные слова «все», «некоторые», «любой».
• Чёткое разделение между аксиомами, гипотезами и выводами.

Пример нестрогости

«Если идёт дождь, то улица мокрая. Сейчас идёт дождь. Значит, улица мокрая.» — это корректный modus ponens, но в NL часто встречаются ошибки: «Если идёт дождь, то улица мокрая. Улица мокрая. Значит, идёт дождь.» — это логическая ошибка (утверждение консеквента), но в NL она может звучать правдоподобно.

LLM, обученные на NL, склонны воспроизводить такие ошибки, так как они не имеют встроенного механизма проверки логической валидности.

3. Семантическая амбигуозность

Одно слово или фраза в NL может иметь множество смыслов в зависимости от контекста. Это создаёт проблемы для рассуждений, где точность критична.

Для сложного рассуждения каждая неоднозначность — потенциальный источник ошибки. Агент, работающий с NL, должен либо разрешать амбигуозность через внешние инструменты (например, запрос к базе знаний), либо рисковать неверным выводом.

4. Отсутствие исполнимости

Естественный язык не является исполняемым. Нельзя «запустить» NL-текст как программу. В RAG|Agentic RAG это критично, потому что агент должен выполнять действия: вызывать API, обрабатывать данные, принимать решения.

Сравнение

• Формальный язык (Python): if temperature > 30: activate_cooling() — однозначно, исполняемо, тестируемо.
• Естественный язык: «Если температура превышает 30 градусов, включи охлаждение» — может быть понято по-разному (какой порог? что значит «включи»? какой тип охлаждения?).

Даже если LLM генерирует NL-план, агент должен преобразовать его в конкретные действия. Этот шаг трансляции — источник ошибок.

5. Невозможность верификации

Модель, рассуждающая на NL, не может проверить своё рассуждение на выполнимость. В формальной логике или программировании есть чёткие критерии корректности:

• Синтаксическая валидность (парсинг).
• Семантическая валидность (типизация, область значений).
• Выполнимость (SAT-решатель, интерпретатор).

В NL таких критериев нет. LLM может сгенерировать цепочку рассуждений, которая выглядит правдоподобно, но содержит скрытые противоречия или неверные шаги. Это явление известно как hallucination (галлюцинация) в рассуждениях.

Пример:

«Все птицы умеют летать. Пингвин — птица. Значит, пингвин умеет летать.» — формально неверно из-за исключения, но NL-модель может это выдать, если не имеет доступа к фактам.

6. Проблема композициональности

Сложное рассуждение требует композиции шагов: результат одного шага становится входом для следующего. В NL композиция часто неоднозначна.

Пример:

«Умножь сумму чисел 2 и 3 на 4.» — возможны две интерпретации:

1. (2+3)*4 = 20
2. 2+(3*4) = 14

В формальном языке скобки разрешают неоднозначность: (2+3)*4 vs 2+(3*4). В NL приходится полагаться на контекст или дополнительные уточнения.

Для агента, который строит многошаговый план, композициональность критична: каждый шаг должен однозначно передавать состояние следующему.

7. Сравнение естественного и формальных языков

8. Роль в Agentic RAG

В Agentic RAG агент использует LLM для планирования и принятия решений. Если агент рассуждает исключительно на NL, возникают проблемы:

• Невыполнимые планы: агент может предложить шаги, которые невозможно реализовать (например, «вызвать несуществующий API»).
• Отсутствие обратной связи: NL-рассуждение не даёт сигнала об ошибке на промежуточных шагах.
• Невозможность повторного использования: NL-план нельзя легко переиспользовать или модифицировать программно.

Поэтому современные архитектуры Agentic RAG (например, ReAct, Plan-and-Solve) предлагают генерировать не NL-текст, а структурированные представления: JSON с действиями, код на Python, вызовы функций.

9. Альтернативы: структурированные рассуждения

Чтобы преодолеть ограничения NL, в Agentic RAG применяют:

• Code-as-Thought: LLM генерирует код на Python, который затем выполняется. Код детерминирован, верифицируем и исполняем.
• Function calling: модель выбирает и вызывает предопределённые функции с типизированными параметрами.
• Graph-of-Thought: рассуждение представляется в виде графа, где узлы — промежуточные выводы, а рёбра — логические связи.
• Формальные логические программы: использование Prolog или Datalog для дедуктивных рассуждений.

Пример (Code-as-Thought):

# Запрос: "Найди среднюю зарплату разработчиков в Москве, у которых опыт больше 3 лет"
def get_salary_stats():
    data = query_database("SELECT salary FROM developers WHERE city='Moscow' AND experience > 3")
    if not data:
        return "Нет данных"
    avg = sum(data) / len(data)
    return f"Средняя зарплата: {avg:.2f}"

Такой код можно выполнить, проверить и отладить.

10. Ограничения современных LLM в NL-рассуждениях

Даже продвинутые модели (GPT-4, Claude) демонстрируют ограниченную способность к сложному рассуждению на NL:

• Chain-of-Thought улучшает результаты, но не гарантирует корректность — модель может «выдумать» правдоподобные, но неверные шаги.
• Self-consistency (множественные трассы) повышает надёжность, но не решает проблему амбигуозности.
• Внешние инструменты (калькулятор, поиск) помогают, но требуют, чтобы модель корректно сформулировала запрос к инструменту — а это снова NL.

Исследования (например, «GSM8K» для математических задач) показывают, что точность падает с ростом числа шагов, особенно когда требуется учёт контекстных ограничений.

11. Пример: почему NL-рассуждение подводит в Agentic RAG

Рассмотрим задачу: «Найди документы, связанные с темой 'нейронные сети', которые были обновлены после 2023 года, и отсортируй по дате».

NL-рассуждение (плохо):

«Сначала нужно найти все документы про нейронные сети. Потом отфильтровать по дате. Потом отсортировать.» — не указано, как именно искать, какой формат даты, что делать, если документов нет.

Структурированное рассуждение (хорошо):

{
  "action": "search_documents",
  "params": {"query": "нейронные сети", "filters": {"updated_after": "2023-01-01"}},
  "next_action": "sort_results",
  "params": {"by": "date", "order": "desc"}
}

Здесь каждый шаг однозначен, параметры типизированы, результат можно проверить.

12. Заключение

Естественный язык — превосходный интерфейс для общения человека и машины, но он принципиально не подходит для внутреннего представления сложных рассуждений в Agentic RAG. Логическая нестрогость, семантическая амбигуозность, отсутствие исполнимости и верифицируемости делают NL-рассуждения ненадёжными для многошаговых задач. Решение — использовать формальные промежуточные представления (код, JSON, графы) и оставлять NL только для финальной коммуникации с пользователем.

Пет-проект для закрепления

Задача Создать агента, который для сложного запроса (например, «спланируй поездку из Москвы в Санкт-Петербург с учётом погоды, бюджета и времени») генерирует не NL-ответ, а формальный план в виде Python-кода, выполняет его и возвращает результат.

Инструменты Python, LangChain, функция exec(), библиотека requests для API погоды, sqlite3 для базы данных маршрутов.

Шаги:

1. Определить набор инструментов (API погоды, поиск билетов, калькулятор бюджета).
2. Написать промпт, который заставляет LLM генерировать код, вызывающий эти инструменты.
3. Реализовать безопасное выполнение кода (песочница, ограничение времени).
4. Добавить обработку ошибок: если код не выполняется, агент должен перегенерировать план.
5. Сравнить качество ответов с агентом, который рассуждает только на NL (без кода).

Ожидаемый результат Агент с code-as-thought будет давать более точные и выполнимые планы, особенно для запросов с несколькими условиями.

Связь с другими вопросами

Навигация

• Предыдущий: 183
• Следующий: 185
• Индекс: 00. Индекс разборов