DevDay, длинный контекст и сдвиг к продакшн-системам на LLM
Что означает конференция OpenAI DevDay для компаний, которые думают о переходе от LLM-пилотов к рабочим системам.
Вчера OpenAI провела первый DevDay - конференцию для разработчиков. Анонсы были конкретными: GPT-4 Turbo с окном контекста в 128 тысяч токенов, новые возможности для вызова функций, режим Assistants API, который упрощает создание систем с памятью и инструментами. Плюс снижение цен.
Это не просто обновление продукта. Это сигнал о направлении, в котором движется инструментарий LLM. И этот сигнал важен для любой компании, которая сейчас думает о том, что делать с языковыми моделями в бизнесе.
Что изменилось с длинным контекстом
До сих пор одним из главных ограничений LLM в реальных задачах был размер контекстного окна. Модель "забывает" всё, что выходит за его пределы. Это означало, что для работы с длинными документами нужно было резать их на части, строить сложные схемы извлечения и управления контекстом.
128 тысяч токенов - это примерно 90-100 страниц плотного текста в одном запросе. Целый договор, целый технический регламент, несколько часов транскрипции встречи - всё это теперь помещается в контекст без нарезки.
Это не значит, что RAG и векторный поиск умерли - для очень больших корпусов они по-прежнему нужны. Но для задач среднего масштаба сложность архитектуры существенно снижается.
Что означает Assistants API
До этого анонса создание LLM-системы с памятью между сессиями, набором инструментов и возможностью работать с файлами требовало значительного инженерного труда. Нужно было самостоятельно управлять историей диалогов, реализовывать вызов инструментов, хранить и извлекать файлы.
Assistants API переносит часть этой логики на сторону OpenAI. Меньше инфраструктурного кода - больше времени на бизнес-логику. Это снижает порог входа для команд, которые хотят строить продуктивные LLM-системы, но не хотят или не могут инвестировать в тяжёлую инфраструктуру.
Почему это сдвиг, а не просто улучшение
На мой взгляд, сегодняшние анонсы маркируют момент, когда LLM-инструментарий перестаёт быть в первую очередь исследовательским и становится прежде всего инженерным и продуктовым.
Раньше большинство разговоров шло о том, что модели умеют. Теперь разговор переходит к тому, как строить системы, которые работают в продакшне: надёжно, масштабируемо, с управляемой стоимостью.
Это означает, что компании, которые до сих пор наблюдали со стороны, ожидая пока технология "созреет" - сейчас получают более понятную точку входа. Инструменты для сборки продуктивных систем стали конкретнее.
Что это означает на практике
Для тех, кто уже строит что-то на LLM: стоит заново оценить архитектуру в свете новых возможностей. Часть сложности, которую вы вручную решали в RAG-пайплайне, может уйти. Часть стоимости снизится.
Для тех, кто ещё не начал: порог входа снизился. Но это не значит, что вопросы о данных, безопасности и операционных расходах куда-то делись. Они просто стали задаваться в другой точке пути.
Несколько вопросов для оценки своей позиции
- Есть ли у нас конкретные задачи, где длинный контекст меняет архитектурный ответ?
- Какие из наших LLM-пилотов готовы к разговору о продакшн-инфраструктуре?
- Понимаем ли мы, где в нашей цепочке находится узкое место - модель, данные или интеграция?
- Есть ли у нас ответственный за то, чтобы отслеживать изменения в LLM-инструментарии и оценивать их применимость?
Скорость изменений в этой области такова, что "посмотрим через год" - уже не работающая стратегия. Год назад GPT-4 не существовало. Сегодня он получил контекст в 128 тысяч токенов и API для сборки агентов.