Контекстное окно LLM: что это означает для бизнес-приложений
Разбор того, почему ограничение контекста у языковых моделей - это не технический нюанс, а архитектурное решение, которое определяет, что вообще получится построить.
Когда разговор заходит о внедрении языковой модели в конкретный продукт или процесс, одним из первых технических терминов всплывает "контекстное окно". Инженеры говорят об этом как о само собой разумеющемся. Руководители кивают, не вполне понимая, почему это важно.
Я хочу объяснить, почему это важно - и почему именно это ограничение определяет, что реально построить, а что только выглядит реальным на демо.
Что такое контекстное окно простыми словами
Языковая модель не "помнит" в обычном смысле. Она обрабатывает то, что вы ей передали прямо сейчас. Контекстное окно - это максимальный объём текста, который модель видит за один раз: ваш вопрос, история переписки, документы, которые вы приложили, и системная инструкция.
В начале 2024 года типичное окно составляет несколько тысяч токенов у массовых моделей, и до ста тысяч у отдельных специализированных. Токен - это примерно 0.7 слова на русском языке. Несколько тысяч токенов - это 3-5 страниц текста. Сто тысяч - около 70 страниц.
Звучит много, пока вы не начинаете прикладывать реальные документы.
Где это ограничение проявляется на практике
Самый распространённый сценарий, который я вижу у клиентов: "мы хотим сделать чат-бота, который отвечает на вопросы по нашей документации". Документация - это пятьсот страниц регламентов, каталог продуктов, база FAQ. Всё это не помещается в контекстное окно одновременно.
Из этого вытекают три принципиально разных архитектурных решения:
Первое - вы выбираете и передаёте только нужные фрагменты документа в ответ на конкретный вопрос. Это называется RAG (retrieval-augmented generation). Модель видит не всю документацию, а то, что поиск нашёл по запросу. Работает хорошо, если поиск работает хорошо.
Второе - вы дообучаете модель на ваших данных, чтобы знания "зашить" в веса, а не передавать в контексте. Это дорого, требует специалистов, и знания устаревают вместе с обучением.
Третье - вы принимаете ограничение как данность и проектируете задачу так, чтобы она умещалась в окно. Часто это лучшее решение, просто требует честного взгляда на задачу.
Почему демо выглядит лучше, чем продакшн
На демо инженер аккуратно подбирает вопросы, которые попадают точно в заранее подготовленный контекст. Всё работает плавно. В продакшне пользователь задаёт вопрос, который требует информации из пяти разных мест документации, плюс истории предыдущих разговоров, плюс текущего статуса его заказа. Всё это вместе не умещается в окно.
Я видел несколько проектов, где команда только через три месяца разработки поняла, что целевой сценарий использования физически не помещается в архитектуру, построенную на демо-логике.
Как думать об этом при оценке проекта
Несколько вопросов, которые стоит задать до того, как команда начала строить:
- Какой объём контекста нужен для одного рабочего взаимодействия - сколько текста нужно видеть модели одновременно?
- Откуда этот текст берётся: из базы знаний, из истории разговора, из внешних систем?
- Что происходит, если не весь нужный контекст попадает в окно - какие ошибки это порождает?
- Кто отвечает за то, чтобы поиск правильных фрагментов работал надёжно?
- Как будет меняться объём данных через год - не превратится ли сегодняшний "умещается" в "не умещается"?
Простой тест
Попросите команду описать типичный производственный сценарий: что именно пользователь спросит, какой текст нужен модели для ответа и откуда он возьмётся. Если этого описания нет - архитектурное решение ещё не принято, даже если разработка уже идёт.