Демо RAG-пайплайн можно собрать за один день. Но чтобы он выжил при реальной пользовательской базе — с задержкой менее секунды, затратами на инференс, которые не съедают вашу маржу, и ответами без галлюцинаций — требуются месяцы. Именно в этом разрыве между прототипом и продакшеном тихо умирает большинство AI-проектов.
Роль Full-Stack AI Engineer существует именно из-за этого разрыва. Она не о том, чтобы знать каждую модель или фреймворк. Она о том, чтобы владеть всем путём: от выбора токенизации и эмбеддингов до качества поиска, памяти агента, развертывания в Kubernetes и дашборда затрат, который подскажет, когда один запрос начинает стоить дороже, чем платит клиент.
Эта статья — практическое руководство по этому пути. Мы возьмём одну реалистичную задачу, решим её шаг за шагом с цифрами, затем посмотрим, где вся схема ломается — и какие учебные маршруты действительно к этому приводят.
Что на самом деле представляет собой работа: механизм, а не модные слова
LLM — это предсказатель следующего токена. Всё остальное в продакшн-AI-продукте — это инженерия вокруг его ограничений: контекстное окно, стоимость за токен, задержка и тот факт, что он уверенно выдумывает факты.
RAG-пайплайн (Retrieval-Augmented Generation, генерация с дополненной выборкой) решает последнюю проблему, внедряя релевантные документы в промпт. Механизм прост: разбить документы на чанки, преобразовать каждый чанк в вектор с помощью модели эмбеддингов, сохранить векторы в векторной базе данных, затем во время запроса векторизовать вопрос, найти ближайшие чанки и вставить их в промпт перед генерацией.
У каждого шага есть режим отказа. Слишком маленький чанк — теряется контекст. Слишком большой чанк — эмбеддинг усредняет слишком много тем, и точность поиска падает. Неправильная метрика расстояния — косинусное сходство против скалярного произведения — и результаты незаметно ухудшаются. Выбор векторной базы данных (Chroma, Qdrant, Pinecone) значит меньше, чем думают, на малом масштабе, и гораздо больше на большом: фильтрация, репликация и время перестроения индекса становятся реальными ограничениями.
Один пример: создание ассистента поддержки, который не сливает деньги
Представьте SaaS-компанию с 4000 документов поддержки и 20 000 пользовательских вопросов в месяц. Цель: автоматически отвечать на 60% вопросов, удерживать p95 задержки ниже 2 секунд и оставаться в рамках фиксированного месячного бюджета.
Шаг 1 — Чанкинг и эмбеддинги
Разбейте документы на чанки примерно по 400–600 токенов с перекрытием 10–15%. Перекрытие сохраняет предложения, которые пересекают границы. Затем используйте эмбеддинги с моделью, соответствующей вашему языку и домену — универсальная модель эмбеддингов подходит для английских документов поддержки, но модель, настроенная на домен, может заметно улучшить полноту поиска на техническом жаргоне.
Шаг 2 — Векторная база данных и поиск
Для 4000 документов по ~500 токенов у вас примерно 2000–3000 чанков. Это спокойно помещается в одноузловой Qdrant или управляемый индекс Pinecone. Извлеките топ-20 кандидатов, затем переранжируйте до топ-5 перед генерацией. Переранжирование — самый дешёвый способ повысить качество в большинстве пайплайнов: оно стоит долю от вызова генерации и удаляет нерелевантные чанки, которые иначе запутали бы модель.
Шаг 3 — Генерация и расчёт стоимости
Предположим, каждый запрос отправляет 1500 токенов промпта и возвращает 200 токенов завершения. При цене модели среднего уровня, скажем, $3 за миллион входных токенов и $15 за миллион выходных, один запрос стоит примерно $0,0075. При 20 000 запросов в месяц это около $150 — приемлемо. Но если вы наивно отправляете все 20 лучших чанков (скажем, 8000 токенов) на каждый запрос, та же математика даёт примерно $0,03 за запрос, или $600 в месяц, ещё до повторов и циклов агента.
Шаг 4 — Агенты и память
Если вы добавляете AI-агента с использованием инструментов — проверка заказа, статус возврата, эскалация — каждый вызов инструмента это ещё один цикл модели. Цикл в стиле ReAct с тремя шагами может утроить расход токенов. Память (история разговора) добавляет ещё. Именно здесь оптимизация затрат на инференс перестаёт быть абстракцией и становится статьёй расходов.
Где схема ломается: четыре сценария отказа
1. Качество поиска рушится, когда корпус меняет форму
Вы настроили чанкинг на чистую документацию. Затем команда начинает загружать PDF с таблицами, сканированные договоры и многоколоночные макеты. Разбиение по количеству символов разрывает таблицы на бессмысленные фрагменты. Поиск возвращает чанки, которые выглядят релевантными по косинусному сходству, но не содержат ответа.
Как заметить это рано: отслеживайте долю ответов, где модель говорит «Я не знаю» или не ссылается на источник. Внезапный рост после обновления корпуса — это сигнал.
Если уже слишком поздно: добавьте парсер, учитывающий тип документа (извлечение PDF с учётом макета), переразбейте на чанки и перестройте индекс. Заложите бюджет на периодические перестроения индекса — это не разовые работы.
2. Векторный поиск незаметно деградирует при масштабировании
На 3000 чанках полный перебор работает нормально. На 3 миллионах приближённые индексы ближайших соседей (HNSW) обменивают полноту на скорость. Вы можете потерять 5–10% релевантных результатов без какого-либо сообщения об ошибке.
Как заметить это рано: поддерживайте небольшой размеченный набор вопросов-ответов для оценки и измеряйте recall@k после каждого изменения индекса.
Если уже слишком поздно: увеличьте параметры ef_search, добавьте переранжировщик или шардируйте индекс по арендатору или категории.
3. Провайдер модели меняет цены или снимает модель с поддержки
Развертывание LLM — это не «выбрал модель и забыл». Провайдеры снимают модели с поддержки, меняют токенизаторы и корректируют цены. Пайплайн, настроенный на контекстное окно одной модели, может незаметно обрезать промпты на другой.
Как заметить это рано: фиксируйте версии моделей в конфигурации, еженедельно отслеживайте стоимость за запрос и держите слой абстракции, чтобы смена провайдера была изменением конфигурации, а не переписыванием.
4. Бюджет задержки взрывается из-за циклов агента
Один вызов генерации может занять 1,5 секунды. Агент с тремя вызовами инструментов и поиском в памяти может занять 6–8 секунд. Пользователи уходят.
Как заметить это рано: измеряйте p95, а не среднее. Среднее скрывает хвост.
Если уже слишком поздно: передавайте частичные ответы потоком, распараллеливайте независимые вызовы инструментов, кешируйте частые запросы и ограничивайте итерации агента жёстким лимитом.
Учебные маршруты и их реальные компромиссы
| Маршрут | Время до готовности к продакшену | Стоимость | Основной риск |
|---|---|---|---|
| Самостоятельное изучение по документации и туториалам | 6–12 месяцев, неравномерно | Низкие денежные затраты, высокие временные | Нет обратной связи по решениям; вы учитесь тому, что работает в демо, а не в продакшене |
| Создание реального побочного проекта | 3–6 месяцев | Низкие денежные затраты, средние временные | Вы сталкиваетесь только с теми отказами, которые вызывает ваш проект |
| Структурированный курс с практикой | 2–4 месяца | Средняя | Требует дисциплины; не заменяет выпуск чего-то реального |
Самостоятельное изучение жизнеспособно, если у вас уже есть инженерная дисциплина. Барьер — не информация, а обратная связь. Никто не скажет вам, что размер чанка неправильный, пока пользователи не пожалуются, а к тому времени вы уже дважды перестроите индекс.
Структурированный путь помогает больше всего, когда он заставляет вас пройти через неудобные части: измерение полноты поиска, расчёт стоимости за запрос и развертывание с мониторингом. Курс Full-Stack AI Engineer на asibiont.com проходит именно через эти расчёты — проектирование RAG-пайплайна, компромиссы векторных баз данных, циклы агентов и оптимизацию затрат на инференс — с финальным проектом, который должен работать в продакшене, а не только в блокноте. Уроки текстовые и персонализированы под ваш уровень, так что вы можете быстрее пройти то, что уже знаете.
Если вы взвешиваете, что делать сначала — строить или учиться, — полезное правило: соберите небольшой RAG-прототип на этой неделе, затем изучите те части, которые сломались. Такое сочетание лучше, чем любой из путей по отдельности.
Кому подходит этот путь — и кому нет
Эта работа подходит инженерам, которые уверенно работают с API, базовым Python и чтением логов. Она также подходит техническим продакт-менеджерам, которым нужно понимать, почему AI-функция медленная или дорогая.
Она не подходит людям, ищущим no-code решение. Агенты и RAG-пайплайны отказывают так, что требуется отладка — чтение трассировок, сравнение эмбеддингов, проверка параметров индекса. Для падения полноты поиска нет решения «перетащи и брось».
Она также не подходит тем, кто хочет полностью избежать математики. Вам не нужен глубокий матанализ, но нужно рассуждать о количестве токенов, бюджетах задержки и стоимости за запрос. Это арифметика, а не исследовательская математика — но её не избежать.
Спокойное место для старта
Путь от демо до продакшн-AI-продукта — это в основном негламурные части: решения о чанкинге, оценка поиска, дашборды затрат и развертывание, которое не падает. Если вы хотите структурированный маршрут через эти части — с обратной связью по вашим решениям и финальным проектом, который должен выжить в реальных ограничениях — курс Full-Stack AI Engineer — один из способов туда добраться. Вы можете начать на asibiont.com и приступить к первому уроку, когда будете готовы.
А если вы всё ещё решаете, начните с прототипа. Отказы, с которыми вы столкнётесь за неделю, расскажут вам больше о том, чему нужно учиться, чем любая сравнительная таблица.