После знакомства с предыдущим разделом у многих возникает вполне естественный вопрос.
Если проблема заключается в том, что модель не знает новых документов, почему бы просто не добавить эти документы в её память? На первый взгляд решение кажется очевидным.
Появилась новая инструкция? => Переобучили модель.
Изменился закон? => Добавили новый текст в обучение.
Вышла новая версия библиотеки Python? => Еще раз обучили модель.
К сожалению, на практике такой подход практически невозможен. Чтобы понять почему, необходимо разобраться, как вообще создаются современные большие языковые модели.
Обучение LLM — это не загрузка файлов
Одна из самых распространенных ошибок начинающих разработчиков заключается в том, что они представляют обучение модели примерно так.
Документы
│
▼
Загружаются внутрь модели
│
▼
Модель их запоминает
Такой образ интуитивно понятен. Мы ведь именно так работаем сами. Если человек прочитал книгу, значит информация «записалась» в память. Но нейронные сети устроены совершенно иначе. Во время обучения документы никогда не сохраняются внутри модели в привычном виде.
Нет никакой внутренней папки
knowledge/
python.pdf
linux.pdf
company.docx
Нет базы данных.
Нет SQL.
Нет JSON.
Нет XML.
Нет файлов вообще.
После окончания обучения от исходных документов ничего не остается. Остаются только параметры нейронной сети.
Что действительно происходит во время обучения
Попробуем сильно упростить процесс.
Представим предложение
Кошка сидит на ковре.
Во время обучения модель видит последовательность слов. Она пытается предсказать следующее слово.
Например.
Кошка сидит на ______
Она предполагает
стуле
Но правильный ответ
ковре
Возникает ошибка. Алгоритм обучения немного изменяет миллиарды внутренних параметров модели. После этого вероятность слова «ковре» становится немного выше. На следующем примере происходит то же самое.
И так повторяется…
Миллиарды раз.
Сотни миллиардов раз.
Триллионы раз.
Каждый раз параметры модели изменяются совсем немного. В результате внутри сети постепенно формируется сложнейшая статистическая модель языка. Именно поэтому современные LLM содержат десятки и даже сотни миллиардов параметров.
Эти параметры не являются фактами. Они являются весами огромной математической функции.
Почему параметры — это не база знаний
Представьте библиотеку. В ней хранится миллион книг. Теперь представьте, что вместо хранения книг библиотеку заставили вычислить среднее содержание всех этих книг. После этого оригиналы уничтожили. Что останется? Некоторое усредненное представление информации. Вернуться к оригинальной книге уже невозможно. Примерно так же работают большие языковые модели.
После обучения нельзя открыть параметр номер
W[38294712]
и увидеть
«Документ №25 говорил о PostgreSQL.»
Этого там нет. Каждый параметр участвует одновременно в кодировании огромного количества закономерностей. Информация распределена по всей сети. Именно поэтому говорят, что знания в нейронной сети распределенные (distributed representations). Нельзя указать пальцем на конкретный нейрон и сказать:
«Вот здесь хранится инструкция по установке Docker.»
Такого места просто не существует.
Почему переобучение невероятно дорого
Теперь становится понятно, почему нельзя просто «добавить один документ». Представим, что компания выпустила новую инструкцию объемом двадцать страниц. Чтобы встроить её непосредственно в параметры модели, необходимо снова запустить обучение. Но обучение современной LLM — одна из самых ресурсоемких задач в вычислительной технике.
Рассмотрим, что для этого требуется.
1. Огромные вычислительные мощности
Современные модели обучаются не на одном компьютере. Используются сотни или даже тысячи графических процессоров (GPU), работающих одновременно. Во время обучения они непрерывно выполняют триллионы операций с плавающей запятой. Стоимость такой инфраструктуры измеряется миллионами долларов.
2. Большое время обучения
Даже при использовании специализированных вычислительных кластеров обучение может продолжаться неделями или месяцами. Это не процесс, который можно запускать каждый вечер после обновления документации.
3. Необходимость повторного прохождения по огромному корпусу данных
Кажется логичным обучить модель только на новом документе. Но здесь возникает другая проблема. Если обучать модель исключительно на новой информации, она начинает забывать старую.
Это явление называется катастрофическим забыванием (catastrophic forgetting).
Представьте преподавателя, который весь месяц объясняет ученику только квантовую физику, полностью игнорируя математику, химию и биологию. Через некоторое время ученик действительно станет лучше понимать квантовую физику, но часть ранее изученного материала начнет забываться. С нейронными сетями происходит нечто похожее. Поэтому при серьезном дообучении приходится тщательно балансировать между сохранением старых знаний и добавлением новых.
4. Финансовая стоимость
Даже если компания располагает собственной вычислительной инфраструктурой, каждое новое обучение означает:
- оплату электроэнергии;
- использование дорогих GPU;
- резервирование серверов;
- хранение промежуточных данных;
- работу специалистов.
Для большинства организаций ежедневное переобучение модели экономически нецелесообразно.
Дообучение тоже не является универсальным решением
На этом этапе важно различать два понятия, которые часто путают:
- обучение модели с нуля;
- дообучение (fine-tuning).
Дообучение действительно позволяет изменить поведение модели без полного переобучения. Однако оно решает совсем другую задачу.
Fine-tuning помогает модели:
- лучше соблюдать определенный стиль общения;
- корректнее выполнять специализированные инструкции;
- использовать профессиональную терминологию;
- адаптироваться к новой предметной области.
Но fine-tuning не предназначен для постоянного обновления базы знаний. Если каждое изменение корпоративной документации сопровождать новым fine-tuning, процесс быстро станет столь же дорогим и сложным, как и регулярное переобучение. Более того, возникнет вопрос управления версиями: какая модель соответствует какой версии документов? Как откатить изменения? Как обеспечить согласованность между несколькими источниками данных?
Мы пытаемся решить не ту задачу
На этом этапе полезно остановиться и посмотреть на проблему под другим углом. Представим инженера, которому ежедневно приходится отвечать на вопросы по внутренней документации компании.
Каждое утро выходит несколько новых документов.
Как сделать так, чтобы инженер знал о них?
Есть два варианта.
Первый вариант
Заставить инженера каждое утро перечитывать всю документацию компании заново. Очевидно, что это абсурдно.
Второй вариант
Дать инженеру быстрый поиск по документам. Когда поступает вопрос, инженер открывает нужные материалы, читает только релевантные фрагменты и уже после этого формулирует ответ. Именно второй подход выглядит естественным. Любопытно, что именно он и лежит в основе RAG. Мы перестаем пытаться «встроить» все знания в модель.
Вместо этого мы отделяем две совершенно разные задачи:
- Хранение и поиск информации.
- Понимание информации и генерация ответа.
Это разделение кажется очевидным, но оно стало одним из важнейших архитектурных решений в истории современных систем искусственного интеллекта.
В следующем разделе мы увидим, как из этой идеи рождается архитектура Retrieval-Augmented Generation и почему она оказалась настолько успешной.