# От RAG до автономных агентов: лекция Stanford CME295 о будущем LLM

Источник: https://www.youtube.com/watch?v=h-7S6HNq0Vg
Канал: Stanford Online
Опубликовано: 18.11.2025

---

Седьмая лекция курса Stanford CME295 посвящена переходу от изолированных языковых моделей к системам, активно взаимодействующим с внешним миром. Преподаватели Стэнфорда рассматривают три ключевых технологии: Retrieval Augmented Generation (RAG), вызов инструментов (Tool Calling) и создание автономных агентов. Основная цель — преодолеть ограничения «замороженных» знаний нейросетей и научить их выполнять сложные задачи в динамической среде.

## 🧠 Проблема «замороженных» знаний и концепция RAG
[[JUMP:06:34]]

Основная проблема современных LLM заключается в том, что их знания ограничены датой отсечки обучающих данных (knowledge cutoff). Например, для модели GPT-5 (в контексте лекции) эта дата — 30 сентября 2024 года [08:11]. Если спросить такую модель о событиях, произошедших позже, она либо признает свое неведение, либо галлюцинирует.

Афин (преподаватель курса) выделяет несколько причин, по которым простое дообучение (fine-tuning) для обновления знаний неэффективно:

*   **Риск регрессии:** Изменение весов модели для добавления новых фактов может негативно сказаться на её общих способностях [08:51].
*   **Сложность поддержки:** Если у компании сотни узкоспециализированных моделей, обновлять каждую из них накладно [09:20].
*   **Ограничение контекста:** Несмотря на рост контекстного окна (у GPT-5 оно составляет 400 000 токенов), бесконечно впихивать данные в промпт невозможно [11:04].

По мнению лектора, даже при «безлимитном» контексте возникает проблема «иголки в стоге сена» (needle in a haystack). Тесты показывают, что LLM теряют точность, если нужный факт находится в середине длинного промпта [12:14]. Кроме того, длинные промпты стоят дорого: при цене около $1 за миллион токенов затраты быстро растут [14:36].

Решением становится RAG (Retrieval Augmented Generation) — метод, при котором в промпт добавляется только самая релевантная информация, извлеченная из внешней базы данных в реальном времени [15:17].

## 🛠 Архитектура поиска: эмбеддинги и чанки
[[JUMP:19:30]]

Процесс RAG состоит из трех этапов: поиск (Retrieve), дополнение (Augment) и генерация (Generate) [19:01]. Ключевым этапом является эффективный поиск в базе знаний.

Для подготовки базы знаний документы разбиваются на «чанки» (chunks) — небольшие фрагменты текста. Афин называет типичные параметры для этой операции:

1.  **Размер эмбеддинга:** Обычно составляет около 1500 измерений [21:18].
2.  **Размер чанка:** Оптимально около 500 токенов, чтобы сохранить смысл, не перегружая память [21:57].
3.  **Перекрытие (Overlap):** Между чанками оставляют около 100 токенов, чтобы контекст не разрывался на границах [23:15].

Сам поиск проходит в две стадии [24:35]:

*   **Candidate Retrieval:** Быстрый отбор примерно 100 потенциально полезных чанков с помощью векторного поиска и косинусного сходства [28:14]. Здесь используются Bi-encoders (например, на базе BERT) [30:58].
*   **Ranking (или Reranking):** Более тщательная сортировка отобранных кандидатов. Здесь применяются Cross-encoders, которые анализируют запрос и документ одновременно, что точнее, но требует больше вычислительных мощностей [46:53].

## 📈 Метрики и продвинутые техники поиска
[[JUMP:48:03]]

Для оценки качества работы поисковой системы в RAG лектор рекомендует использовать метрики, стандартные для поисковых систем и рекомендаций [48:18]:

*   **NDCG (Normalized Discounted Cumulative Gain):** Оценивает качество ранжирования, поощряя систему за подъем релевантных документов в топ списка [49:51].
*   **MRR (Mean Reciprocal Rank):** Учитывает только позицию самого первого релевантного документа [54:11].
*   **Recall@K и Precision@K:** Оценивают, какая доля релевантных документов попала в топ-K выдачи [55:07].

Афин также упоминает популярный бенчмарк MTEB (Massive Text Embedding Benchmark) для тестирования моделей эмбеддингов [57:10].

Среди продвинутых методов лектор выделяет HyDE (Hypothetical Document Embeddings). Вместо поиска по самому вопросу, LLM сначала генерирует «фиктивный» ответ, и уже по его эмбеддингу ищется реальный документ [39:10]. Также важной техникой является контекстуализация чанков: к каждому фрагменту текста при поиске добавляется краткое саммари всего документа, чтобы модель понимала, о чем идет речь в отрыве от контекста [41:15].

Для экономии средств при частых вызовах лекторы советуют использовать **Prompt Caching**. Это позволяет не пересчитывать активации для повторяющихся префиксов промпта, что может снизить стоимость вычислений до 90% [44:10].

## 📞 Tool Calling: когда LLM начинает действовать
[[JUMP:59:20]]

Переходя ко второй части лекции, Шервин (второй лектор) объясняет концепцию вызова инструментов (Tool Calling или Function Calling). Если RAG работает с неструктурированным текстом, то Tool Calling позволяет модели взаимодействовать со структурированными данными и API [59:54].

Процесс взаимодействия строится по схеме:

1.  **Preamble:** В промпт модели передается описание доступных функций (их имена, параметры и документация) без реализации [1:08:16].
2.  **Execution:** Если модель решает, что для ответа нужен инструмент, она выдает JSON с аргументами. Система выполняет этот код и возвращает результат модели [1:10:09].
3.  **Response:** Модель интерпретирует данные от API и выдает ответ пользователю на естественном языке [1:10:35].

Шервин утверждает, что обучение модели вызову инструментов можно проводить двумя путями: через классический SFT (Supervised Fine-Tuning) на парах «запрос-вызов» или через детальные инструкции в промпте [1:15:50]. По мнению лектора, для современных мощных моделей предпочтительнее второй путь. Он советует не писать инструкции вручную, а попросить сильную модель (например, Claude или GPT) проанализировать ошибки текущей версии и итеративно улучшить объяснение правил работы с инструментом [1:19:11].

## 🤖 Агенты и фреймворк ReAct
[[JUMP:1:32:05]]

Агент — это система, которая автономно преследует цель, используя циклы рассуждений и действий [1:32:11]. В отличие от простого вызова инструментов, агенты работают итеративно.

Шервин подробно описывает классическую схему **ReAct (Reason + Act)** [1:33:53]:

*   **Observe (Наблюдение):** Анализ текущего состояния и запроса пользователя.
*   **Plan (Планирование):** Формулирование следующего шага.
*   **Act (Действие):** Вызов конкретного инструмента.

На примере холодного дома лектор показывает цикл работы агента: заметив жалобу «мишке холодно», агент сначала запрашивает температуру через API термостата (Observe), видит значение в 65°F (Plan) и принимает решение поднять её на 5 градусов (Act), после чего проверяет результат и закрывает цикл [1:35:11].

Для масштабирования таких систем индустрия движется к стандартизации. Лектор выделяет два важных протокола:

1.  **MCP (Model Context Protocol):** Разработан Anthropic для унификации того, как инструменты и ресурсы предоставляются моделям [1:29:18].
2.  **Agent-to-Agent Protocol:** Инициатива Google для организации общения между разными специализированными агентами [1:39:46].

## 🛡 Безопасность и риски автономности
[[JUMP:1:42:19]]

С ростом возможностей агентов растут и риски. Шервин предупреждает о возможности кражи данных (exfiltration): если агент имеет доступ к паролям и инструменту отправки почты, злоумышленник может обманом заставить его переслать конфиденциальную информацию на внешний адрес [1:42:48].

В качестве примера реальной угрозы упоминается недавний отчет Anthropic о масштабной кибератаке, совершенной с помощью их модели Claude и её агентских способностей [1:45:18]. (Anthropic опубликовала подробный разбор действий хакеров и мер защиты).

Для защиты рекомендуются:

*   **Harmlessness training:** Обучение моделей безопасности на этапе RLHF [1:43:57].
*   **Inference safeguards:** Использование классификаторов безопасности, которые проверяют историю диалога перед выполнением действия [1:44:22].
*   **Бенчмарки:** Использование Agent Safety Bench для оценки уязвимостей [1:44:51].

В завершение лекции Шервин дает практический совет: начинать разработку агентов с самых простых случаев и самых мощных моделей [1:47:50]. По его мнению, в будущем роль программиста сместится от написания кода к его оценке: «Генерация кода стала дешевой, но суждение о том, правилен ли он — это самая сложная часть» [1:49:07].