В чем проблема «natural language bottleneck» для LLM?

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

Natural language bottleneck (узкое горлышко естественного языка) — это фундаментальное ограничение пропускной способности текстового канала при передаче информации из высокоточных источников (численные модели, сенсоры, базы данных) в LLM. Разрыв между объёмом данных, генерируемых, например, численной моделью погоды (~10¹⁴ бит), и текстовым прогнозом (~10² бит) достигает 12 порядков. Это означает, что LLM, работающие исключительно с текстом, теряют критическую детализацию, что делает их непригодными для задач, требующих высокой точности (прогнозирование, инженерные расчёты, медицинская диагностика). Понимание этого bottleneck необходимо для проектирования Agentic RAG-систем, которые должны компенсировать потерю информации через внешние инструменты и мультимодальные каналы.

1. Определение natural language bottleneck

Natural language bottleneck (NLB) — термин, описывающий ситуацию, когда естественный язык (текст) выступает единственным интерфейсом между LLM и внешним миром, но его пропускная способность (количество информации, передаваемой в единицу времени) на много порядков ниже, чем у исходных данных.

• Пропускная способность текста — ограничена скоростью чтения/письма человека (~40–60 бит/с) и плотностью упаковки смысла (символы, слова).
• Пропускная способность численных данных — может достигать гигабит в секунду (например, поток данных]] с метеоспутника).

LLM «видят» мир только через текст, поэтому при переводе численных массивов, изображений, временных рядов в текст происходит сжатие с потерями. Это и есть bottleneck.

2. Пример с численной моделью погоды

Рассмотрим задачу прогноза погоды.

• Численная модель погоды (NWP — Prediction|Numerical Weather Prediction) оперирует сеткой с разрешением 1 км × 1 км × 100 уровней по высоте, шагом по времени 1 час, 10 переменными (температура, давление, влажность, ветер и т.д.).
  • Объём данных за сутки: ~10⁶ ячеек × 10 переменных × 24 шага × 32 бита (float) ≈ 10¹⁴ бит.
• Текстовый прогноз для человека: «Завтра в Москве +15°C, переменная облачность, ветер 5 м/с».
  • Объём: ~200 символов × 8 бит ≈ 10² бит.

Информационный разрыв (information gap) = 10¹⁴ / 10² = 10¹² (12 порядков).

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

3. Информационный разрыв (information gap)

Information gap — количественная мера NLB, показывающая, во сколько раз объём исходных данных превышает объём текстового представления.

Чем больше разрыв, тем сильнее LLM зависит от аппроксимации и обобщения, что ведёт к потере точности.

4. Почему это проблема для LLM?

LLM (Large Language Models) — это модели, обученные предсказывать следующий токен на текстовых корпусах. Они не имеют прямого доступа к численным или мультимедийным данным, если те не преобразованы в текст.

Последствия NLB для LLM

• Потеря точности — LLM не может ответить на вопрос «Какая температура будет в 14:30 на улице Тверская?» с точностью до десятых градуса, так как в текстовом прогнозе такой детали нет.
• Галлюцинации — при попытке «додумать» недостающие детали LLM может сгенерировать правдоподобный, но неверный ответ.
• Неспособность к численным рассуждениям — задачи, требующие арифметики или статистики, решаются плохо (например, «Сравни среднюю температуру за неделю с климатической нормой»).
• Ограничение для RAG|Agentic RAG — агенты, которые должны выполнять точные действия (расчёт дозировки лекарства, настройка оборудования), не могут полагаться только на текстовый канал.

5. Связь с RAG и Agentic RAG

RAG (Retrieval-Augmented Generation) частично смягчает NLB, подгружая в контекст релевантные документы. Но если документы — тоже текст, bottleneck сохраняется.

Agentic RAG — архитектура, в которой LLM-агент может вызывать внешние инструменты (калькуляторы, базы данных, API численных моделей). Это позволяет обходить NLB: агент не переводит все данные в текст, а использует инструмент для точного вычисления и возвращает только результат.

Пример:

• Без инструмента: LLM пишет «температура около 15°C» (потеря точности).
• С инструментом: агент вызывает get_temperature(lat, lon, time) → получает 15.234°C → возвращает «15.2°C» (сохранение точности).

Таким образом, Agentic RAG — один из главных способов преодоления NLB.

6. Другие примеры проявления bottleneck

• Медицина: МРТ-снимок (10⁸ бит) → текстовое заключение радиолога (10³ бит). LLM, работающая только с заключением, теряет информацию о форме, размере, текстуре опухоли.
• Инженерия: CAD-модель детали (10⁹ бит) → текстовое описание «деталь цилиндрическая, диаметр 50 мм» (10² бит). LLM не сможет проверить допуски или рассчитать нагрузку.
• Финансы: Поток котировок (10⁷ бит/день) → новостной обзор (10⁴ бит). LLM не уловит микроструктуру рынка.

7. Как измеряется bottleneck?

Метрика — коэффициент сжатия (compression ratio):

[ C = \frac{H_{[text](/wiki/text){original}}}{H_{[text](/wiki/text){text}}} ]

где (H) — энтропия (информационное содержание) в битах.

Для практических оценок используют пропускную способность канала (channel capacity) в битах в секунду. Если LLM получает текстовый контекст со скоростью ~10³ бит/с (через API), а исходные данные генерируются со скоростью 10⁶ бит/с, bottleneck очевиден.

Инструменты для измерения:

• Информационная энтропия Шеннона для оценки объёма данных.
• BPE-токенизация — показывает, сколько токенов нужно для представления числа (например, число 3.1415926535 может занимать 10+ токенов, что неэффективно).

8. Возможные решения

Наиболее перспективный для Agentic RAG — гибридный подход, так как он не требует изменения архитектуры LLM.

9. Ограничения current LLM в работе с численными данными

Даже современные LLM (GPT-4, Claude 3) демонстрируют слабые места:

• Ошибки в арифметике — особенно с большими числами и плавающей точкой.
• Неспособность к интерполяции — LLM не может восстановить промежуточные значения, если они не были в тексте.
• Чувствительность к форматированию — число «1,000» и «1000» могут восприниматься по-разному.
• Отсутствие понимания единиц измерения — «15°C» и «15 K» — разные величины, но LLM может их спутать.

Эти ограничения — прямое следствие NLB.

10. Заключение: важность для проектирования AI-агентов

Natural language bottleneck — не просто академическая концепция, а практическое ограничение, которое необходимо учитывать при разработке Agentic RAG-систем.

• Если задача требует высокой точности (прогноз погоды, медицинская диагностика, управление роботом), нельзя полагаться только на текстовый канал.
• Архитектура должна включать инструменты (калькуляторы, базы данных, симуляторы), которые принимают на вход точные данные и возвращают точные результаты.
• Оценка качества агента должна включать метрики информационной полноты (насколько ответ сохраняет детализацию исходных данных).

Понимание NLB помогает инженеру осознанно выбирать, когда использовать RAG, а когда — Agentic RAG с инструментами.

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

Задача: Построить агента, который принимает численный временной ряд (температура за 7 дней) и генерирует текстовый прогноз на следующий день. Сравнить точность с исходной численной моделью (ARIMA).

Инструменты: Python, pandas, numpy, statsmodels (ARIMA), OpenAI API (GPT-4), библиотека для оценки (scikit-learn).

Шаги:

1. Сгенерировать синтетический временной ряд температуры с трендом и шумом (100 точек).
2. Обучить ARIMA на первых 90 точках, получить численный прогноз на 10 точек (точные значения).
3. Передать последние 7 точек в LLM с промптом: «Предскажи температуру на следующий день на основе этих данных: [7 чисел]».
4. Собрать ответ LLM (текст, например, «около 22°C»).
5. Извлечь численное значение из ответа (регуляркой).
6. Сравнить MAE (средняя абсолютная ошибка) между ARIMA и LLM.

Ожидаемый результат: MAE для LLM будет в 5–10 раз выше, чем для ARIMA, что наглядно демонстрирует NLB. Дополнительно можно показать, что если дать LLM доступ к statsmodels через инструмент (Agentic RAG), ошибка снижается до уровня ARIMA.

Расширение: Добавить мультимодальный канал — передать график ряда (изображение) в GPT-4V и сравнить точность.

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

Навигация

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