Назовите 4 уровня языкового представления по Yang et al. (2026) и объясните разницу?

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

Yang et al. (2026) предложили иерархию из четырёх уровней языкового представления — от неструктурированного естественного языка до формальных научных моделей. Каждый уровень добавляет строгость, устраняет неоднозначность и повышает исполняемость, что критически важно для построения надёжных AI-агентов и Agentic RAG-систем. Разница между уровнями — в степени формализации: Level 0 — гибкий, но амбигуозный; Level 1 — структурированный; Level 2 — логически ограниченный и исполняемый; Level 3 — моделирующий причинно-следственные связи реального мира.

1. Контекст: зачем нужны уровни языкового представления?

Современные языковые модели (LLM) работают преимущественно с Natural Language (естественным языком). Однако для автономных агентов, которые должны планировать, выполнять действия и верифицировать результаты, одного естественного языка недостаточно — он слишком неоднозначен и плохо поддаётся автоматической проверке. Yang et al. (2026) в своей работе (гипотетической, но логически обоснованной) предложили классификацию, которая помогает выбирать подходящий уровень представления в зависимости от задачи: от простого диалога до научного моделирования.

Термин «RAG|Agentic RAG» — это расширение классического RAG, где агент не просто ищет документы, а самостоятельно планирует поиск, использует инструменты, проверяет факты и принимает решения. Для такого агента важно уметь работать с разными форматами представления знаний.

2. Level 0 — Natural Language (естественный язык)

Характеристики

• Неструктурированный текст, свободная грамматика.
• Высокая амбигуозность (неоднозначность): одно слово может иметь несколько значений, контекст не всегда спасает.
• Максимальная гибкость: можно выразить любую мысль, но сложно автоматически проверить корректность.

Пример:

«Найди информацию о последних исследованиях в области квантовых вычислений и сравни их с классическими подходами.»

Проблемы для агента

• Неясно, какие именно «последние» — по дате публикации? по дате рецензирования?
• «Сравни» — какой критерий сравнения? скорость? точность? стоимость?
• LLM может интерпретировать запрос по-разному, что ведёт к нестабильным результатам.

Роль в RAG|Agentic RAG

• Используется для первичного взаимодействия с пользователем (интерфейс).
• Подходит для задач, где важна креативность и широкий контекст, но не требуется строгая верификация.

3. Level 1 — Structured formats (JSON, XML, YAML)

Характеристики

• Данные организованы в ключ-значение, иерархии, списки.
• Устраняется амбигуозность за счёт явной схемы (schema).
• Машиночитаемость: парсеры могут однозначно извлечь поля.

Пример (JSON):

{
  "query": "quantum computing recent research",
  "filters": {
    "year_min": 2023,
    "comparison_criteria": ["speed", "accuracy"]
  },
  "output_format": "comparison_table"
}

Преимущества перед Level 0

• Агент точно знает, какие поля ожидать.
• Можно валидировать запрос до выполнения (например, проверить, что year_min — число).
• Легко интегрировать с API и базами данных.

Недостатки

• Жёсткая структура может не покрыть все нюансы запроса.
• Требуется дополнительный шаг преобразования из естественного языка в структуру (NL→JSON).

Роль в Agentic RAG

• Стандартный формат для вызова инструментов (function calling).
• Используется для хранения контекста (история диалога в JSON).
• Позволяет агентам обмениваться данными без потери смысла.

4. Level 2 — Code & Math (код и математика)

Характеристики

• Исполняемые выражения: Python, SQL, математические формулы.
• Добавляются логические ограничения (типы данных, синтаксис, семантика).
• Результат можно проверить путём выполнения (run-time verification).

Пример (Python-код для агента):

def retrieve_and_compare(topic: str, year_min: int, criteria: list) -> dict:
    docs = vector_db.search(topic, top_k=10)
    filtered = [d for d in docs if d.year >= year_min]
    comparison = {}
    for c in criteria:
        comparison[c] = [d.metrics[c] for d in filtered]
    return comparison

Преимущества перед Level 1

• Не просто данные, а алгоритм действий.
• Можно автоматически проверить корректность (компиляция, тесты).
• Позволяет агентам выполнять вычисления, симуляции, обращаться к внешним инструментам.

Недостатки

• Требует высокой точности генерации кода (LLM может ошибиться).
• Не все задачи можно выразить в виде кода (например, творческие).

Роль в Agentic RAG

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

5. Level 3 — Scientific formalization & World models (научная формализация и модели мира)

Характеристики

• Явное моделирование реальности: причинно-следственные связи, физические законы, онтологии.
• Используются формальные языки (логика первого порядка, графы знаний, симуляторы).
• Позволяет делать предсказания и рассуждения о последствиях действий.

Пример (онтология в формате OWL):

@prefix : <http://example.org/ontology/> .
:QuantumComputer rdfs:subClassOf :Computer .
:Speed rdf:type :Metric ;
       :unit "qubit operations per second" .
:ResearchPaper rdfs:subClassOf :Document ;
               :hasYear xsd:integer .

Преимущества перед Level 2

• Модель мира позволяет агенту рассуждать о том, что произойдёт, если выполнить действие (например, «если я запрошу больше документов, время ответа увеличится»).
• Возможность интервенций: агент может симулировать «что если» и выбирать оптимальный план.
• Высокая степень верификации: утверждения можно проверить на соответствие модели.

Недостатки

• Огромные затраты на построение и поддержание модели мира.
• Сложность интеграции с LLM (нужен перевод между естественным языком и формальной моделью).

Роль в Agentic RAG

• Используется в продвинутых агентах для долгосрочного планирования (например, multi-step retrieval с учётом зависимостей).
• Позволяет агенту объяснять свои решения (XAI) на основе формальной модели.
• Применяется в научных RAG-системах (например, для поиска по химическим реакциям с предсказанием продуктов).

6. Сравнительная таблица уровней

7. Как уровни связаны с архитектурой Agentic RAG

В типичном Agentic RAG-пайплайне агент проходит несколько этапов:

1. Понимание запроса (Level 0 → Level 1): LLM преобразует естественный язык пользователя в структурированный JSON-запрос.
2. Планирование поиска (Level 1 → Level 2): агент пишет код для выполнения нескольких запросов к разным источникам.
3. Исполнение и верификация (Level 2 → Level 3): агент запускает код, получает результаты, затем использует модель мира для проверки непротиворечивости (например, если два источника дают противоречивые данные, агент может запросить третий).
4. Формирование ответа (Level 3 → Level 0): формальные результаты переводятся обратно в естественный язык для пользователя.

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

8. Практические соображения и ограничения

• Стоимость: преобразование между уровнями требует дополнительных вызовов LLM (например, NL→JSON, NL→Code). Это увеличивает latency и затраты.
• Надёжность: генерация кода (Level 2) может содержать ошибки. Нужны механизмы повторных попыток и sandbox-исполнения.
• Полнота модели мира (Level 3): построить полную онтологию для произвольной предметной области практически невозможно. Поэтому Level 3 применяется только в узких доменах (медицина, физика, финансы).
• Гранулярность: не всегда нужно подниматься до высоких уровней. Для простого вопроса «Какая сегодня погода?» достаточно Level 1 (JSON от API погоды). Для сложного научного запроса может потребоваться Level 3.

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

Задача: Реализовать простого агента, который принимает запрос на естественном языке и последовательно преобразует его через уровни 0→1→2, выполняет код и возвращает результат.

Инструменты: Python, библиотека openai (или любая LLM), json, exec (в изолированной среде, например, subprocess).

Шаги:

1. Напишите функцию nl_to_json(query: str) -> dict, которая с помощью LLM преобразует запрос в JSON-схему (например, {"action": "search", "params": {...}}).
2. Напишите функцию json_to_code(json_query: dict) -> str, которая генерирует Python-код для выполнения действия (например, поиск в локальной векторной БД).
3. Выполните код в безопасном окружении (например, exec с ограниченным globals).
4. Верните результат в виде строки.

Ожидаемый результат: Агент сможет выполнить запрос «Найди 3 статьи про RAG за 2025 год и выведи их названия» — сгенерирует JSON, затем код, выполнит его и вернёт список.

Расширение: Добавьте Level 3 — простую онтологию (например, граф знаний о статьях: автор, год, тема) и используйте её для проверки, что все найденные статьи действительно относятся к RAG.

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

11. Навигация

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

Навигация

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