Книгу прочитал. Теперь что делать?

Вы закрыли последнюю страницу "AI Engineering" Чипа Хуена. Теория в голове. Архитектурные паттерны, принципы проектирования, даже математика где-то там плавает. Но руки пустые. GitHub пустой. Работодатели спрашивают про опыт, а вы показывать нечего. Знакомо?

Этот разрыв между теорией и практикой убивает больше карьер, чем плохие модели. Знать, как работает RAG, — одно. Построить RAG-систему, которая не позорит вас на собеседовании, — совсем другое.

Самый частый вопрос в моем телеграм-канале: "Прочитал Хуена, понимаю теорию, но не знаю, с чего начать практику". Если вы сейчас в этой точке — эта статья ваш спасательный круг.

Шаг ноль: выбросьте иллюзии

Прежде чем что-то строить, примите три неприятные истины:

Никто не будет платить вам за знание теории. Платят за работающие системы.
Простое клонирование репозитория с GitHub не считается проектом. Это домашнее задание.
Если ваш проект не решает реальную проблему — он никому не интересен. Даже вам через неделю.

Забудьте про "попробовать технологии". Начинайте с "решить проблему". Разница принципиальная.

1Неделя первая: диагноз и целеполагание

Не бегите сразу писать код. Сначала ответьте на три вопроса:

Вопрос	Правильный ответ	Неправильный ответ
Что я умею на практике?	"Могу настроить векторную БД и собрать простой RAG пайплайн"	"Знаю теорию эмбеддингов"
Куда хочу попасть?	"В стартап, который строит агентные системы для автоматизации бизнес-процессов"	"В AI-компанию"
Что мне не хватает?	"Опыта работы с LangGraph и оценки качества агентов"	"Больше теории"

Теперь конкретика. Откройте 5 вакансий на позиции, куда хотите попасть. Выпишите все технологии из требований. Увидите повторяющиеся паттерны:

LangChain/LangGraph — в 80% вакансий
Оценка качества (RAGAS, TruLens) — в 60%
Агентные системы — в 70%
Docker + базовый MLOps — в 90%

Ваш план на следующие 8 недель рождается из этого анализа. Не из книг. Не из курсов. Из реальных требований работодателей.

💡

Если не знаете, куда хотите попасть — посмотрите статью про дорожную карту для AI-разработчика. Там разобраны возможные направления после освоения базового RAG и финтюна.

2Недели 2-3: RAG, который не стыдно показать

Все начинают с RAG. И все делают это неправильно. Типичная ошибка — скачать датасет, закинуть в векторную БД, подключить OpenAI и радоваться. Такой проект даже в портфолио не положишь.

Вместо этого:

Возьмите реальные данные. Не датасет из Kaggle. Ваши собственные заметки, документацию с работы (анонимизированную), публичные API с динамическим контентом.
Сделайте препроцессинг не для галочки. Удалите дубликаты, нормализуйте текст, разбейте на чанки с перекрытием. Если не знаете, как это делать правильно — ваша система будет работать в два раза хуже.
Добавьте реранкинг. Простой семантический поиск — это 2019 год. В 2025 нужен хотя бы cross-encoder для реранкинга результатов.
Напишите тесты. Не unit-тесты на функции. Тесты на качество ответов. Используйте RAGAS или TruLens. Замерьте метрики до и после каждого улучшения.

Самый важный момент: ваш RAG должен решать конкретную проблему. Например: "Система отвечает на вопросы по документации моего старого проекта, потому что я сам уже не помню, как там что работает". Или: "Агрегатор технических статей с возможностью задавать вопросы по всему контенту".

Не используйте OpenAI для всего. Возьмите локальную модель через Ollama или llama.cpp для эмбеддингов. Для генерации можно оставить GPT-4, но хотя бы попробуйте локальные варианты. Это покажет, что вы понимаете разницу между инференсом эмбеддингов и генеративных моделей.

Когда ваш RAG работает, добавьте мониторинг. Логируйте запросы, ответы, latency, стоимость (если используете платные API). Сделайте простую дашборду в Streamlit или Gradio. Это уже не игрушка, а прототип production-системы.

3Недели 4-5: LangGraph — где теория становится сложной

Если RAG — это линейный пайплайн, то LangGraph — это граф состояний. И здесь большинство спотыкаются. Потому что начинают со сложного, вместо того чтобы понять основы.

Не пытайтесь сразу строить многоагентные системы. Начните с простого:

Агент с двумя инструментами: поиск в интернете и калькулятор
Система с conditional routing: если вопрос про математику — идет в калькулятор, если про факты — в поиск
Добавьте human-in-the-loop: агент останавливается и спрашивает у пользователя уточнения, когда не уверен

Самая частая ошибка — переусложнение. Видел проекты, где люди пытались сделать 7 агентов с разными специализациями, но не могли заставить работать даже базовый цикл. Начните с одного агента. Доведите его до рабочего состояния. Потом добавляйте второго.

Ключевой навык здесь — отладка. Графы состояний сложнее дебажить, чем линейный код. Научитесь использовать LangSmith или хотя бы логировать каждое состояние. Без этого вы будете часами гадать, почему агент зациклился.

💡

Если хотите увидеть, как выглядит агент 3-го уровня автономии в работе, посмотрите практический гайд по построению автономных агентов. Там разобран реальный кейс с n8n и OpenRouter.

4Недели 6-7: CrewAI и управление агентами

LangGraph дает гибкость. CrewAI дает структуру. И это важно понимать: они решают разные задачи.

CrewAI — это фреймворк для многоагентных систем, где у каждого агента есть роль, цель, backstory. Звучит как over-engineering, но на практике это решает проблему несфокусированных агентов.

Практическое задание: сделайте систему из трех агентов:

Research Agent — ищет информацию в интернете
Analysis Agent — анализирует найденное, выделяет ключевые точки
Writer Agent — формирует итоговый отчет

Казалось бы, просто. Но вот где подводные камни:

Агенты начинают повторять друг друга
Research Agent передает Analysis Agent слишком много мусора
Writer Agent игнорирует анализ и генерирует текст из головы

Решение? Пропишите четкие инструкции для каждого агента. Ограничьте контекст. Добавьте валидацию выходных данных. И самое главное — тестируйте на реальных запросах, а не на придуманных.

После того как система работает, попробуйте применить принципы управления из реального офиса. Да, это звучит странно, но работает. Агенты — как сотрудники. Им нужны четкие KPI, регулярная обратная связь (через валидацию) и понятные процессы.

5Неделя 8: упаковка и продажа

У вас есть три проекта. RAG, LangGraph агент, CrewAI система. Теперь нужно это упаковать так, чтобы работодатель захотел вас нанять.

Что НЕ работает:

Ссылка на GitHub репозиторий с README.md "Мой проект"
Скриншоты интерфейса без объяснения архитектуры
Список использованных технологий без контекста

Что работает:

Живой демо. Разверните систему на бесплатном инстансе (Hugging Face Spaces, Railway). Пусть можно поиграться.
Детальный разбор архитектуры. Не просто "использовал LangGraph", а диаграмма графа состояний с объяснением, почему выбрал именно такую структуру.
Метрики качества. RAGAS оценки для RAG, success rate для агентов, latency, стоимость запроса.
Проблемы и решения. Честно напишите, с какими сложностями столкнулись и как их решили. Это ценнее, чем список успехов.

Сделайте отдельный сайт-портфолио. Не резюме на hh.ru. Свой сайт, где вы рассказываете о каждом проекте как кейсе. Добавьте видео с демонстрацией работы. Напишите статью про технические детали.

Не ждите идеального проекта. Идеальных проектов не существует. Показывайте то, что есть. Но показывайте с умом. Лучше средний проект с отличной презентацией, чем отличный проект, о котором никто не знает.

А что с собеседованиями?

Вы прошли 8 недель. У вас есть портфолио. Теперь ищите работу. И здесь снова большинство ошибаются.

Типичная стратегия: отправить 100 резюме, получить 5 ответов, провалить 4 собеседования из-за стресса. Неэффективно.

Вместо этого:

Выберите 10 компаний, где реально хотите работать. Не 100 случайных.
Для каждой компании адаптируйте сопроводительное письмо. Ссылайтесь на их продукты, предлагайте конкретные идеи улучшений с помощью AI.
На собеседовании говорите не о технологиях, а о проблемах, которые вы решали. "Я использовал LangGraph для построения агента, который решает проблему X, потому что традиционный подход Y не работал из-за Z".

Самый важный навык на собеседовании AI-инженера — умение объяснять trade-offs. Почему выбрали эту модель, а не ту? Почему такая архитектура графа? Почему такие метрики качества? Если можете аргументированно ответить на эти вопросы — вы уже впереди 80% кандидатов.

💡

Если боитесь, что ваш босс заменит вас на AI — прочитайте статью про замену разработчиков AI. Но лучшее средство от страха — стать тем, кто строит эти системы, а не тем, кого ими заменяют.

Чего не хватило в книге Хуена

Книга отличная. Но в ней есть пробелы, которые заметны только на практике:

Мало про отладку. В теории все работает. На практике агенты зацикливаются, RAG возвращает ерунду, эмбеддинги ломаются на специфичных данных.
Ничего про cost optimization. Использовать GPT-4 для всего — легко. Сделать систему, которая работает так же хорошо, но в 10 раз дешевле — искусство.
Слабо освещена тема оценки качества. Accuracy, recall — это просто. А как измерить, хороший ли ответ дал агент? Нет универсальной метрики.

Эти пробелы вы заполните только практикой. Через ошибки. Через бессонные ночи отладки. Через разочарование, когда система, которая работала вчера, сегодня сломалась из-за обновления библиотеки.

И это нормально. AI Engineering — не про знание теории. Это про умение заставить работать сложные системы в неидеальных условиях. Про принятие решений при недостаточной информации. Про баланс между качеством, скоростью и стоимостью.

Книга Хуена дала вам карту. Но идти по территории придется вам. Сейчас. Пока другие размышляют о perfect project. Пока ждут идеальных условий. Пока боятся начать.

Ваш первый проект будет кривым. Второй — немного лучше. Третий — уже можно показывать. К десятому вы будете смеяться над своими ранними решениями. Это и есть рост.

Начните сегодня. Не с идеального плана. С первого коммита. С первого запуска. С первой ошибки, которую вы исправите сами.

Теория закончилась. Пора строить.

От теории к практике: пошаговый план для AI-инженера после книги Чипа Хуена