Capstone: проектируем и строим production AI-приложение с нуля

Цели урока

• Спроектировать архитектуру AI-приложения от требований до выбора стека
• Реализовать полный pipeline: API → RAG → LLM → Tool Calling → Response
• Применить production hardening: caching, rate limiting, monitoring, error handling
• Настроить контейнеризацию (Docker), CI/CD и управление секретами
• Организовать цикл демо → feedback → оценка → итерация

Инженер выходит с собеседования в YC-стартап. Конкурентов было 40. Его взяли - из-за одного репозитория: Knowledge Assistant с Qdrant, streaming-ответами, агентом и semantic cache. Не из-за диплома и не из-за leetcode. Из-за того, что весь стек AI Engineering - RAG, embeddings, tool calling, vector DB, мониторинг стоимости - был собран в один рабочий продукт. Именно это и строится в этом уроке.

• Stripe Docs AI: RAG поверх 500+ страниц документации, tool calling для генерации примеров кода - архитектурно идентичен capstone-проекту
• Cursor IDE: агентный pipeline с RAG по кодовой базе, embeddings через text-embedding-3-small, streaming через SSE - те же паттерны, другой масштаб
• Perplexity AI: поиск + RAG + citations - под капотом vector store, re-ranking и LLM-as-judge для оценки релевантности; стартовали с 50 долларов в день на API
• 70% YC-стартапов W24/S24 используют RAG + multi-agent архитектуру из этого курса - разница только в объёме данных и количестве инструментов

AI Engineering становится дисциплиной

До ChatGPT (ноябрь 2022) разработка с AI почти всегда означала обучение моделей - работу ML-исследователей. Волна мощных hosted-моделей вслед за ним выделила отдельное ремесло: собирать готовые модели в надёжные продукты через prompting, RAG, tool calling, оценку и контроль расходов. К 2023-2024 годам название «AI Engineer» разошлось по вакансиям, а паттерны вроде vector search, агентных циклов и guardrails сложились в общий инструментарий. Единого события-основания не было, лишь постепенное взросление. Capstone - это момент, когда разрозненный инструментарий собирается в одну работающую систему.

Предварительные знания

• AI System Design: production AI application architecture from zero to scale
• Multi-Agent Systems: Orchestration, Communication, Agent Specialization
• Advanced RAG: hybrid search, re-ranking, query expansion, self-RAG

Планирование: requirements, архитектурные решения, выбор стека

Каждый production AI-проект начинается не с кода и не с выбора LLM-провайдера, а с **чёткого определения задачи**. Требования latency диктуют streaming. Требования cost - model routing и semantic cache. Требования scale - BullMQ и горизонтальное масштабирование. Без этих ответов даже идеально написанный RAG pipeline будет оптимизировать не то.

Capstone-проект - **AI Knowledge Assistant**: документация загружается, чанкуется и индексируется в Qdrant через `text-embedding-3-small`. На запрос пользователя запускается RAG retrieval, результаты передаются агенту с tool calling (web search, calculator, API), ответ стримится через SSE. Это не игрушечный пример - это архитектура Stripe Docs AI и Cursor в миниатюре.

Выбор стека определяется requirements, а не хайпом и не тем, что «все используют». Каждый компонент должен быть обоснован конкретной потребностью:

**Частая ошибка на этапе планирования** - начинать с выбора технологий вместо определения требований. Qdrant «круче» pgvector, но если в проекте 1000 документов и нет нужды в filtering - pgvector внутри существующего PostgreSQL будет проще и дешевле.

Реализация: API, LLM, RAG pipeline, tool calling

Ядро AI-приложения - **Orchestrator**: точка сборки всех компонентов курса. Запрос попадает сюда, агент решает, нужен ли RAG из Qdrant или tool call (web search, calculator, внешний API), формирует контекст с историей диалога и embedding-результатами, вызывает LLM - и возвращает структурированный ответ с источниками. Именно здесь multi-agent паттерны из урока 19 встречаются с Advanced RAG из урока 13.

**RAG pipeline** - место, где большинство проектов теряет качество. Chunking с неправильным размером дробит смысловые единицы, retrieval без score threshold возвращает нерелевантные куски, embedding без batch-запросов делает ingestion в 10 раз медленнее. Ниже - battle-tested реализация с recursive chunking, Qdrant filtering по userId и batched `text-embedding-3-small`:

**Совет по chunking:** начинать с chunk_size=512 и overlap=64. Если ответы неточные - уменьшить chunk_size до 256. Если контекст теряется - увеличить overlap до 128. Всегда измерять качество на реальных вопросах, а не подбирать параметры вслепую.

Production-hardening: кеширование, rate limiting, мониторинг

Рабочий прототип - это 20% пути. Остальные 80% - **production hardening**: reliability, cost control, observability. Один непредсказуемый всплеск трафика без semantic cache и rate limiting может потратить дневной бюджет за час - реальный кейс из YC-стартапа с 8000 долларов за ночь на GPT-4. Три компонента закрывают 90% этого риска: semantic cache поверх Qdrant, per-user rate limit через Redis, и cost tracking с Prometheus.

• **Semantic cache** - для повторяющихся запросов (экономия 30-60% на LLM вызовах)
• **Rate limiting** - per-user лимиты, разные тарифы (free/premium)
• **Circuit breaker** - автоматическое переключение на fallback при сбое провайдера
• **Request timeout** - 30с для обычных запросов, 60с для reasoning models
• **Input validation** - ограничение длины промпта, фильтрация prompt injection
• **Cost tracking** - логирование каждого вызова с подсчётом стоимости
• **Alerting** - уведомление при превышении дневного бюджета

**Semantic cache с threshold 0.95** может выдать неправильный ответ при тонких различиях в вопросах. «Как удалить файл?» и «Как удалить директорию?» - cosine similarity ~0.96, но ответы разные. Всегда тестировать cache на edge cases.

Deployment: Docker, CI/CD, secrets, environments

AI-приложение при деплое сложнее обычного: API-ключи трёх провайдеров, self-hosted Qdrant с persistent storage, embedding models с версионированием, опционально GPU для local inference. Одна ошибка - `COPY . .` без `.dockerignore` - и `OPENAI_API_KEY` уходит в Docker Hub в открытом виде. Правильная контейнеризация и secrets management закрывают этот класс проблем раз и навсегда.

• **OPENAI_API_KEY** - ротация каждые 90 дней, разные ключи для dev/staging/prod
• **ANTHROPIC_API_KEY** - fallback провайдер, хранить в том же secret manager
• **DATABASE_URL** - никогда не хардкодить, даже в docker-compose
• **Инструменты:** GitHub Secrets для CI/CD, Docker secrets или .env для runtime
• **Мониторинг утечек:** использовать git-secrets или gitleaks в pre-commit hook

**API-ключи в Docker image** - частая утечка. Никогда не копировать .env в Docker image через `COPY . .` без .dockerignore. Секреты передаются через environment variables при запуске контейнера, не при сборке.

Demo, feedback, итерации: жизненный цикл AI-продукта

Деплой - не финал, а точка отсчёта. AI-приложение деградирует само по себе: OpenAI обновляет модели и поведение промптов меняется, пользователи находят edge cases которые не тестировались, semantic cache накапливает устаревшие ответы. Без eval pipeline (LLM-as-judge на dataset из реальных вопросов) деградацию замечают только когда уже получили плохой NPS.

**Подготовка демо** - отдельный навык. AI-приложения непредсказуемы при temperature > 0: один и тот же вопрос может дать разные ответы. Цель демо - показать capability системы (RAG + tool calling + streaming + корректный отказ при hallucination risk), не идеальный ответ на один вопрос. Демо должно быть подготовлено, но не fake:

• Подготовить 5-7 вопросов, которые демонстрируют все capability (RAG, tools, history)
• Протестировать каждый вопрос 3-5 раз - убедиться в стабильности ответов
• Подготовить fallback-сценарий: что показать, если LLM API упадёт во время демо
• Показать метрики: latency, cost per query, cache hit rate
• Продемонстрировать edge case: вопрос вне контекста → корректный отказ вместо галлюцинации

**Итерационный цикл:** Demo → Feedback → Анализ метрик → Улучшение промптов / chunking / model routing → Eval pipeline → Повторный Demo. Каждая итерация занимает 1-2 недели. После 3-4 итераций качество стабилизируется.

**Главный принцип capstone-проекта:** делать меньше, но лучше. Лучше отличный RAG pipeline с 3 источниками, чем посредственная система с 10 фичами. Глубина важнее ширины - это то, что отличает senior AI-инженера от junior.

Итоги

• Начинать с requirements (latency, cost, scale) - они диктуют архитектуру; выбор Qdrant vs pgvector вытекает отсюда, а не из хайпа
• Собрать Orchestrator: RAG retrieval из Qdrant + conversation history + tool calling в единый pipeline перед первым вызовом LLM
• Добавить semantic cache поверх Qdrant - снижает расходы на LLM на 30-60% без потери качества
• Прописать rate limiting per-user, circuit breaker и cost tracking с первого дня - иначе первый всплеск трафика сожжёт бюджет
• Настроить Docker multi-stage + CI/CD + secrets через env - ни одного API-ключа в image-слоях
• Запустить eval pipeline (LLM-as-judge) при каждом изменении промпта или модели - это и есть CI/CD для AI

Что дальше

Capstone-проект объединил все навыки AI Engineering курса. Дальнейшие уроки посвящены cutting-edge направлениям, которые определят будущее AI-инженерии.

• Reasoning модели — o1/o3 - следующий скачок качества, меняющий архитектуру AI-приложений
• World Models — От текста к пониманию физического мира - следующий горизонт AI
• Путь к AGI — Scaling laws, emergent abilities и что это значит для разработчиков

Связанные уроки

• aie-42-ai-system-design — Capstone применяет полный AI system design
• aie-13-advanced-rag — Проект строит продвинутый RAG-пайплайн
• aie-19-multi-agent — Агенты и оркестрация двигают capstone
• aie-35-observability — Прод-харднинг требует мониторинга и трассировки
• sd-22-observability — Мониторинг деплоя повторяет системную observability
• net-37-load-balancing — Масштабирование деплоя применяет балансировку нагрузки
• sd-10-microservices