# Докажи, что твоя нейросеть не врёт

Фраза «вроде стало получше» больше не считается ответом — ни на собеседовании, ни перед клиентом. Считается доля правильных ответов на одном и том же наборе запросов. Ниже — как собрать такой набор за вечер и что с ним делать дальше.

## Шаг 1. Собери набор проверок

- 01 «Выпиши 30-50 реальных запросов, которые уже приходили в твою систему» — Придуманные вопросы дают красивую картинку и нулевую пользу. Бери из логов, переписок, чата поддержки.
- 02 «Добавь четыре типа тяжёлых случаев» — Ответ собирается из нескольких документов. Вопрос сформулирован размыто. Ответа в базе нет вообще. Вопрос с опечатками и просторечием.
- 03 «К каждому запросу напиши эталонный ответ» — Тот, который ты сам считаешь правильным. Без эталона мерить нечем.
- 04 «Отметь источник там, где он есть» — Какой документ или фрагмент обязан попасть в ответ. Это отдельная проверка, и она ловит половину проблем.
- 05 «Зафиксируй версию промта и модели на первом прогоне» — Это точка отсчёта. Без неё «стало лучше» не с чем сравнивать.

## Шаг 2. Прогоняй и считай, а не смотри глазами

- 01 «После каждой правки прогоняй весь набор, а не тот запрос, который чинил» — Иначе чинишь одно и ломаешь два. Это и называется регрессией.
- 02 «Записывай долю, а не впечатление» — «Сорок два из пятидесяти» — это результат. «Кажется, лучше» — это не результат.
- 03 «Автоматизируй проверку везде, где получается» — Точное совпадение для категорий, наличие обязательного факта, оценка второй моделью по шкале. Руками набор проверяется один раз, дальше это не работает.
- 04 «Держи объём выше идеальности» — Сто грубо размеченных примеров дают больше сигнала, чем десять вылизанных.
- 05 «Меряй заодно цену и задержку одного ответа» — Качество без стоимости — половина картины. На проде вторая половина решает.

## Шаг 3. Разбери поиск и генерацию по отдельности

Система ищет документы, потом пишет по ним ответ. Это два разных места поломки, и лечатся они по-разному.

строки «Показатель → Значение»: Ответ уверенный, но фактов из твоей базы в нём нет → Смотреть: попал ли нужный документ в выдачу поиска. Чинить в поиске: разбиение на фрагменты, формулировка запроса, ранжирование; Нужный документ нашёлся, а ответ всё равно мимо → Смотреть: что модель сделала с найденным текстом. Чинить в генерации: промт, требование опираться только на источник; Ответ верный, но каждый раз разный → Смотреть: разброс между прогонами на одном запросе. Чинить: температура, жёсткий формат ответа; На старых запросах хорошо, на новых мимо → Смотреть: покрытие набора. Чинить в наборе проверок: долить свежие реальные запросы; Система уверенно отвечает там, где данных нет → Смотреть: поведение при пустой выдаче. Чинить: явный отказ отвечать и передача человеку

## Что превращает ответ в отказ

- «~~«Вроде стало лучше»~~» → «На том же наборе доля совпадений с эталоном выросла, вот цифры до и после»
- «~~«Подкручу промт»~~» → «Сначала замерю, где ломается: поиск или генерация. Промт трогаю вторым шагом»
- «~~«Возьму модель посильнее»~~» → «Сравню обе на одном наборе: качество, цена ответа, задержка»
- «~~«Мы тестировали руками, всё нормально»~~» → «Набор прогоняется автоматически на каждом изменении»
- «~~«Модель иногда галлюцинирует, это нормально»~~» → «Есть доля ответов без опоры на источник, и я знаю, куда она движется»

## Вопросы, к которым стоит быть готовым

- Наш бот отвечает ненадёжно. Как найдёшь причину и что починишь первым? — Ждут порядок действий: замер, разделение поиска и генерации, гипотеза, проверка.
- Как поймёшь, что новая версия промта лучше старой, а не просто другая? — Ждут набор проверок и цифру, а не ощущение.
- Сколько стоит один ответ твоей системы и что в нём дороже всего? — Ждут понимание расхода на запрос и того, как он растёт с нагрузкой.
- Что делает система, когда ответа в базе нет? — Ждут честный отказ и передачу человеку, а не выдумывание.
- Как ловишь ухудшение после обновления модели? — Ждут автоматический прогон и сравнение с предыдущим замером.

врезка `// Главное правило`: текст «Пока ты не умеешь превратить «мне кажется, оно врёт» в число, любая починка — это угадывание. Число не делает систему умнее, оно показывает, куда идти. Начни с малого: тридцать запросов, эталонные ответы, один прогон. Дальше набор растёт сам — каждый пойманный косяк в него добавляется.»

## Куда идти дальше

карточка 1 — моно-метка «», заголовок «platform.claude.com/docs/en/test-and-evaluate/develop-tests», описание «Как строить наборы тестов, какие бывают способы автоматической оценки, примеры кода.», кнопка «»; карточка 2 — моно-метка «», заголовок «braintrust.dev/articles/what-is-rag-evaluation», описание «Раздельная оценка поиска и генерации, размер стартового набора, метрики опоры на источник.», кнопка «»; карточка 3 — моно-метка «», заголовок «promptfoo.dev/docs/intro», описание «Открытый инструмент, чтобы прогонять наборы проверок из командной строки и сравнивать версии.», кнопка «»; карточка 4 — моно-метка «», заголовок «kore1.com/ai-engineer-interview-questions-2026», описание «Раскладка раундов собеседования по времени и список причин, по которым чаще всего отказывают.», кнопка «»; карточка 5 — моно-метка «», заголовок «careerservices.upenn.edu — 45+ вопросов с разбором», описание «Вопросы по раундам с образцами ответов, от прикладных основ до проектирования системы.», кнопка «»; карточка 6 — моно-метка «», заголовок «linkedin.com — Jobs on the Rise 2026», описание «Рейтинг самых быстрорастущих профессий и место, которое занимает инженер по искусственному интеллекту.», кнопка «»

---

Источник: https://localhost:3000/m/ai-ne-vret
