Портфолио-проект: AI-фича от идеи до production

Что ищет hiring manager

Сделать demo на LLM легко, сделать продукт трудно. Авторы «What We've Learned From A Year of Building with LLMs» пишут, что продукты часто застревают после demo, потому что команды недооценивают инженерную работу и оценку качества. Поэтому в портфолио смотрят не на красоту чата, а на признаки инженерного суждения:

• Evals с числами. Есть набор вопросов, метрики по слоям и таблица результатов, которую можно воспроизвести одной командой.
• Error analysis (разбор ошибок). Видно, как ты читал traces, какие провалы нашёл и что изменил.
• Решения и компромиссы. Почему hybrid search (поиск по словам и по смыслу вместе), почему этот размер chunk (фрагмента), почему workflow (путь, заданный в коде), а не свободный agent.
• Production-привычки. Docker, конфигурация через переменные окружения, logging и traces, eval в CI, секреты не в репозитории.
• Честные ограничения. Раздел «что не работает» вызывает больше доверия, чем обещание, что работает всё.

Красные флаги: обёртка над API без единой метрики; только notebook; нет README; ключ API в истории git; огромный замысел, сделанный на треть. Маленький проект, доведённый до конца, сильнее большого незаконченного.

Бриф проекта

Задача. Ассистент, который отвечает на вопросы по документации открытого проекта (например, большого open-source framework с публичной документацией и подходящей лицензией) и умеет подготовить черновик issue (сообщения о проблеме), если ответа в документации нет.

Корпус. Бери только публичные документы с понятной лицензией: открытая документация, открытые государственные данные. Никаких документов работодателя или клиентов и никаких персональных данных: репозиторий публичный, и одна такая ошибка перечёркивает весь проект. Хороший корпус — 300–2 000 страниц с таблицами, версиями и перекрёстными ссылками: на нём видны настоящие проблемы chunking и retrieval.

Пользователь. Разработчик, который застрял и хочет ответ со ссылкой на нужный раздел, а не пересказ.

Функции. Ответ с citations (ссылками на конкретные фрагменты); честный отказ, если ответа нет; tool draft_issue, который формирует черновик и показывает его пользователю на подтверждение, но ничего не публикует сам.

Non-goals (что сознательно не делаем): авторизация пользователей, свой fine-tuning, мобильное приложение. Список non-goals показывает, что ты управляешь объёмом.

Архитектура. Ingestion документации с metadata (раздел, версия, URL) → hybrid search → reranker (модель, которая переупорядочивает найденное) → top-5 → LLM с инструкцией отвечать только по фрагментам → проверка формата и наличия citations → ответ. Отдельная ветка: router решает, отвечать или предложить черновик issue.

Evals — сердце проекта

Набор из 60 вопросов, размеченных вручную: - 40 вопросов, на которые документация отвечает, с указанием нужных фрагментов; - 10 вопросов, ответа на которые нет: правильное поведение — отказ и предложение issue; - 10 adversarial (враждебных): prompt injection в тексте вопроса и в специально подложенном документе.

Метрики: recall@5 для retrieval (нашёлся ли нужный фрагмент в первых пяти); groundedness (подтверждён ли ответ фрагментами) через LLM-as-judge, которого ты проверил на 30 ответах, размеченных вручную, и записал согласие; доля правильных отказов; для tool — конечное состояние (черновик создан, ничего не опубликовано) и pass^3 (задача решена во всех трёх прогонах); latency p50 и p95; стоимость одного ответа.

Пример строки результата в README (числа условные): «Hybrid search plus reranker raised recall@5 from 0.72 to 0.86; groundedness stayed at 0.91; cost per answer rose by 20%». Одна такая строка с методикой стоит больше десяти скриншотов.

Evals дешевле, чем кажется. Один прогон: 60 вопросов × 3 повтора = 180 вызовов по 3 500 tokens — около 630 000 tokens. По условной цене $1 за 1 млн input tokens это меньше $1 за прогон, плюс вызовы judge. Значит, прогонять набор после каждого изменения можно без оглядки на бюджет, и в README это стоит сказать.

Eval запускается в CI на каждый pull request, и результат виден в отчёте. Это та же фраза, что и на собеседовании: «the eval job blocks the merge».

README и демо

README читают 2–3 минуты, поэтому порядок важен: 1. Одна фраза: что это и для кого. 2. Ссылка на демо-видео на 2 минуты. 3. Схема архитектуры. 4. Как запустить: docker compose up и файл .env.example без настоящих ключей. 5. Таблица eval-результатов и команда, которая их воспроизводит. 6. Решения и компромиссы: 3–5 пунктов «выбрал X, потому что Y, отказался от Z». 7. Ограничения и что дальше.

Демо-видео показывает три сцены: удачный ответ со ссылкой; честный отказ с черновиком issue; провал, который поймал eval, и как ты его исправил. Третья сцена — самая сильная: она показывает процесс, а не удачу. Живая ссылка на приложение — плюс, но с лимитом расходов у провайдера модели.

План на четыре недели

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

Последнее — как рассказывать о проекте. На system design раунде он становится твоим примером: требования, архитектура, eval, компромиссы. На поведенческом — STAR-историей о провале, найденном через eval. Подготовь обе версии заранее и ещё одну, короткую, на 60 секунд для вопроса «tell me about a recent project»: задача, одна цифра из eval-таблицы, один найденный провал, одно решение, которое ты принял бы иначе.

Шесть навыков, шесть маленьких проектов

В коротких видео популярна подача «one skill = one project»: по проекту на каждый навык. Как список тренировок она полезна; как портфолио — нет: шесть недоделанных demo слабее одного законченного проекта. Бери их упражнениями на выходные и доводи каждое до одной цифры в README.

Две поправки к исходной подаче. Обещание «semantic cache режет счёт вдвое» верно только при доле попаданий около 50 % и молчит о ложных попаданиях. А в text-to-SQL запрет опасных запросов парсером — первый слой: гарантию дают права базы и read-only replica.