Портфолио AI QA: как собрать проект, который покажет, что вы умеете проверять LLM

Коротко

• Работодателю нужен не сертификат, а доказательство, что вы умеете измерять и улучшать качество LLM-системы. Портфолио — это репозиторий, где такой процесс виден.
• Достаточно одного сквозного проекта: учебный RAG-ассистент, golden-датасет, оценка метриками, red team-скан, нагрузочный прогон, quality gate в CI.
• Ценность создают цифры «до и после» и разбор причин. Просто график или список метрик без вывода ничего не доказывает.
• Объект тестирования берите открытый или свой. Корпоративные данные и чужие продукты без разрешения не подходят.
• Каждый артефакт должен запускаться по README. Если проект нельзя воспроизвести, он не работает как доказательство.

Что хочет увидеть читатель репозитория

Человек, который смотрит ваш GitHub, тратит на него несколько минут. Ему нужно ответить на три вопроса: умеет ли автор строить проверки, понимает ли, что результат значит, и можно ли ему доверить реальную систему. Поэтому репозиторий читается сверху вниз: README, структура, отчёт, затем код.

Я не буду делать вид, что знаю, что именно «сработает» на конкретном рынке: правила найма у всех разные. Но универсальная вещь есть: проект, где виден цикл «измерил, нашёл причину, исправил, измерил снова», выглядит убедительнее набора разрозненных скриптов.

Объект тестирования

Нужна система, которую вы можете запускать и менять. Варианты:

• маленький RAG-ассистент на своих документах (например, на открытой документации какого-нибудь проекта);
• учебный агент с тремя инструментами и моками;
• любой чат-бот с доступным API, если у вас есть право его проверять.

Правила выбора: нет персональных данных, есть возможность подменить промпт или модель (чтобы получить «после»), лицензия документов разрешает использование. Как собрать датасет под такую систему, описано в разборе golden-датасет для RAG.

Четыре артефакта

Артефакт	Что внутри	Что показывает
1. Оценка RAG	golden-датасет, метрики поиска и генерации, диагностика	умение мерить и искать причину
2. Безопасность	набор атак, ASR до и после защиты	понимание рисков и проверка защит
3. Нагрузка	TTFT, throughput, p95, стоимость 1000 диалогов	умение считать производительность и деньги
4. Quality gate	pytest + метрики в CI, PR краснеет и зеленеет	автоматизация и дисциплина

Это совпадает с проектами в программе моего курса AI QA Engineer, но структуру можно собрать самостоятельно. Начинайте с первого: остальные опираются на тот же датасет и стенд.

Структура репозитория

ai-qa-portfolio/
├── README.md              # что за проект, как запустить, главные выводы
├── app/                   # объект тестирования (RAG или агент)
├── data/
│   ├── docs/              # исходные документы
│   └── golden.csv         # вопросы, эталоны, тип, сложность
├── tests/
│   ├── test_quality.py    # метрики оценки (pytest)
│   ├── test_security.py   # атаки и проверка ASR
│   └── test_gate.py       # пороги для CI
├── load/                  # сценарии Locust или k6
├── reports/
│   ├── 01-rag-eval.md     # отчёт с таблицей до/после
│   ├── 02-red-team.md
│   └── 03-load.md
├── .github/workflows/qa.yml
├── .env.example           # без реальных ключей
└── requirements.txt       # версии зафиксированы

Файл .env.example покажет, какие переменные нужны, а сам .env лежит в .gitignore. Проверьте историю репозитория: ключ API не должен там оказаться ни в одном коммите.

README: на что тратить главные 30 строк

1. Одна фраза о проекте и о том, что вы проверяете.
2. Как запустить: три-пять команд, от клонирования до первого зелёного pytest.
3. Схема системы и места, где она ломается.
4. Три главных вывода с цифрами и ссылкой на отчёт.
5. Ограничения: на чём проверяли, что не проверяли.

Пункт 5 недооценивают. Честное перечисление слабых мест показывает зрелость больше, чем красивые метрики.

Шаблон отчёта

# Оценка RAG: версия v1 -> v2

## Контекст
Система, версия модели, судья, размер датасета (N вопросов), дата прогона.

## Результаты
| Метрика | v1 | v2 | Порог |
|---|---|---|---|
| Faithfulness | ... | ... | ... |

## Найденные проблемы (по убыванию критичности)
1. Описание -> причина -> исправление -> эффект на метриках.

## Что не проверено
...

Цифры подставляйте реальные из ваших прогонов. Если вы пишете, что метрика выросла, рядом должны быть версия судьи, число вопросов и пояснение, на каких срезах стало лучше, а на каких хуже. Метрики из раздела про четыре метрики RAG подойдут как отправная точка.

Типичные ошибки

• Нет «до». Показан только финальный результат, и непонятно, что вы изменили.
• Датасет из десяти вопросов. Для демонстрации методики допустимо, для выводов мало. Целитесь в 50–100.
• Судья не проверен. Если вы используете LLM-as-a-judge, покажите калибровку: см. калибровка LLM-судьи.
• Нерабочий README. Проверьте его на чистой машине или в контейнере.
• Секреты в истории. Один случайный коммит с ключом портит впечатление и опасен.
• Только скриншоты. Приложите данные и скрипты, по которым можно воспроизвести цифры.

Как работать над проектом

Разбейте на недели: стенд и датасет; метрики и диагностика; безопасность; нагрузка; CI и отчёты. После каждого этапа делайте коммит и короткую запись в reports/. Тогда история репозитория сама покажет процесс. Если застряли, опишите проблему и гипотезы в отчёте: разбор ошибки тоже ценный материал.

Как рассказать о проекте в резюме и на собеседовании

В резюме проект описывается не технологиями, а результатом и ролью. Формула: что проверяли, чем измеряли, что нашли, что изменилось после исправления. Например: «Собрал golden-датасет на 60 вопросов по 8 типам для учебного RAG; нашёл 5 проблем (из них две в чанкинге); после правок Recall@5 вырос с X до Y». Цифры X и Y должны быть вашими реальными и совпадать с отчётом в репозитории: на собеседовании о них спросят.

Заранее подготовьте ответы на вопросы, которые логично возникают по каждому артефакту:

• Почему именно эти метрики и пороги? Что было бы, если поднять порог?
• Как вы убедились, что судье можно верить? Какое было согласие с ручной разметкой?
• Что в проекте не проверено и где метрики могут обманывать?
• Сколько стоит один прогон и как вы его сокращали?
• Что бы вы сделали иначе, будь у вас ещё неделя?

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

Чек-лист перед публикацией

1. README запускается с нуля на чистой машине или в контейнере, шаги не требуют скрытых знаний.
2. В репозитории нет ключей, .env, клиентских данных и чужих документов без разрешения.
3. Версии библиотек, модели и судьи зафиксированы и записаны в отчёте.
4. Каждая цифра в README ведёт к отчёту, а отчёт — к данным и скриптам.
5. Указано, что не проверено и какие допущения сделаны.
6. Есть лицензия на ваш код и пометка о лицензиях использованных документов.

Что дальше

• Выберите объект тестирования и зафиксируйте его версию.
• Соберите первые 30 вопросов по инструкции из разбора про golden-датасет.
• Сверьтесь с картой навыков, чтобы не упустить блок.