двадцать вопросов против гадания: как я проверяю свой rag

Сценка: вымышленная история. Метод при этом совершенно настоящий, и ниже — как повторить его на своих документах.

Пару недель назад я поймала себя на том, что всю неделю кручу свой поиск по документам: chunk size поменьше, overlap побольше, top_k с трёх до пяти. После каждого изменения задавала один любимый вопрос — про сроки возврата в инструкции по оборудованию — и радовалась: стало лучше. К пятнице «лучше» случилось четыре раза подряд. Это подозрительно похоже на гадание, просто с конфигом.

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

Состав списка, если нужен шаблон:

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

Дальше всё скучно, и в этом смысл. Прогоняю список, каждый ответ оцениваю по шкале 0/1/2: неверно, частично, верно. Записываю в табличку рядом с датой и параметрами. Меняю один параметр, прогоняю снова, сравниваю не впечатления, а числа.

Первый же честный прогон показал то, что я неделю не хотела видеть. Мой «улучшенный» вариант действительно лучше отвечал на перефразированные вопросы — плюс два балла. А на отрицательных стал уверенно выдумывать: вместо «не нашла» приводил правдоподобный срок из соседнего параграфа. Минус три. Табличка вежливо объяснила, что я не улучшала систему, а перераспределяла ошибки в более неприятное место. Найденное число, которого нет в документах, — худший тип ошибки, потому что выглядит он лучше всех.

Несколько практических моментов, если будете делать свой список:

1. Храните его в файле рядом с конфигом, а не в голове. Голова бессознательно подстраивает вопросы под текущее поведение системы — очень эффективно, к сожалению.
2. Пишите ожидаемый ответ сразу, пока вы его точно знаете. Через две недели «ну, там что-то про четырнадцать дней» перестанет быть тестом.
3. Обязательно держите отрицательные вопросы. Это единственная категория, которая ловит уверенную выдумку до того, как её увидит человек, которому вы покажете систему.
4. Перепрогоняйте при любом изменении: модель, эмбеддинги, chunk size, промпт. Специально для лени список ограничен двадцатью — это максимум час на прогон.
5. Когда документы меняются, обновляйте и список. Устаревший тест хуже, чем его отсутствие: он даёт ложное чувство контроля.

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

Честно говоря, двадцать вопросов — это минимум, а не эталон. Но разница между «нет теста» и «двадцать вопросов» гораздо больше, чем между двадцатью и двумястами. Как с бэкапами: сначала важно, чтобы он вообще был, вопросы красоты — потом.

masha_spb писал:
шесть прямых вопросов: ответ лежит в одном месте одного документа

Вот с прямыми вопросами у меня история. Генерю я картинки, и у меня накопилась простыня заметок по промптам — какие слова у меня на 12гб дают нормальные руки, какие превращают лицо в пластилин. Решила прикрутить к этому поиск, чтобы не листать глазами.

Выписала свои двадцать вопросов по твоему шаблону. Прямые прошли с первого раза, я уже приготовилась радоваться. А потом перефразированный: в заметке написано «пальцы ломает на высоком cfg», я спросила «почему руки кривые» — и он мне притащил абзац про освещение. Просто потому что там тоже было слово «кривые».

Три таких промаха из четырёх. Прямые вопросы, получается, самые обманчивые: они проверяют не поиск, а умение совпасть слово в слово. Теперь в моём списке их не шесть, а два, зато перефразированных восемь. Числовые тоже коварные — «сколько шагов» он находил, а «на сколько шагов больше, чем в прошлом пресете» уже нет, хотя оба числа в файле лежали рядом.

Вот у меня поэтому вся двадцатка лежит в n8n-сценарии: поменял конфиг — прогнал всю пачку разом, а не один любимый вопрос. Один вопрос — это гадание, только с автозапуском.

Слово «кривые» в абзаце про освещение — это прямо портрет ключевого поиска: он честно нашёл то, что ты написала, просто не то, что ты имела в виду.

У меня в сценке была зеркальная история с перефразами. Пока вопросы совпадали с текстом дословно, я решила, что поиск умный. Потом переформулировала «срок хранения» как «сколько можно держать» — и получила ответ про складские условия, потому что там было «хранить при температуре». После этого я перестала считать прямые вопросы проверкой поиска: они проверяют совпадение букв.

Про «на сколько больше, чем в прошлом пресете» — это уже не поиск, а арифметика поверх найденного. Тут модель должна сначала вытащить оба числа, потом ещё и вычесть. Если вычитание не её сильная сторона, отдельно не поможет ни chunk size, ни top_k — только расчёт вне модели или явная просьба посчитать по найденным числам. Я бы такие вопросы вообще держала в списке отдельной строкой: они ловят не поисковые промахи, а то, что после поиска.

Маша, у твоего метода есть второй акт, и я в него наступил обеими ногами ))

masha_spb писал:
настройка перестала быть религией

У меня она перестала быть религией и стала статистикой. А у статистики есть свой грех: на неё можно переобучиться.

Объясняю на пальцах, потому что сам долго не видел. Ты не трогаешь модель и не трогаешь тест — трогаешь только конфиг. Но каждое решение «стало лучше / стало хуже» принимается взглядом на те же двадцать вопросов. Через пять-шесть итераций конфиг подогнан под них — не потому что ты жульничал, а потому что другой информации у тебя просто не было. Тест просочился в настройку через твои же глаза. После этого 20/20 измеряет уже не качество поиска, а степень подгонки под эти двадцать. Это ровно «обучение на тестовой выборке», только без единой строчки обучения.

Кусок жизни (в этой же сценке, разумеется). У меня есть файл заметок по своим прогонам: какие кванты, какие флаги, что в какую память влезло и при каком контексте. Прикрутил к нему поиск, выписал двадцать вопросов по твоему шаблону — такой же час с чашкой чая. Неделю крутил chunk size и overlap, пока не получил чистые двадцать из двадцати. Торжество! На следующий день задаю живой вопрос не из списка: какой квант у меня не влез при восьми тысячах контекста и что пришлось урезать. Поиск притащил кусок про другой прогон, где цифры просто похожие. Идеальный результат продержался до первого честного вопроса — примерно сутки.

Что поменял, три вещи, все дешёвые.

Первая: список режется на dev и holdout. Пятнадцать вопросов рабочие — на них кручу конфиг, смотрю, радуюсь. Пять лежат в отдельном файле, который я не открываю, пока не решил, что «всё, готово». Прогон по пятёрке — честный экзамен. Если там 3 из 5, значит, я накрутил под пятнашку, и вся радость была про другое.

Вторая: после любого крупного изменения — другая эмбеддинг-модель, другой принцип нарезки — половину dev-вопросов переписываю заново. Да, ещё час жизни. Зато старые вопросы, которые конфиг уже «видел» десять раз, перестают тянуть одеяло.

Третья, моя любимая: двадцать — маленькая выборка. Разница между 17/20 и 19/20 — это два вопроса, и она запросто может быть шумом, особенно если генерация идёт с температурой выше нуля. Поэтому я прогоняю пачку несколько раз и смотрю не «прошло / не прошло», а сколько раз из пяти проходит каждый вопрос. Изменение конфига считаю настоящим, только если оно стабильно двигает больше двух вопросов, а не одного соседа на одном прогоне. Допущение тут такое: если температура нулевая и весь пайплайн детерминированный, пять прогонов не нужны — но тогда метрика всё равно не знает, как система поведёт себя на чуть другом вопросе.

И отдельно смешно, как это стыкуется с тем, что leo_msk гоняет пачку через n8n: автопрогон снимает лень, но удешевляет и ловушку — подогнаться под тест теперь можно в десять раз быстрее )) Автоматизация ускоряет и хорошее, и плохое, она беспристрастная.

Короче, мой файл теперь называется dev.txt, а рядом лежит holdout.txt с первой строкой-комментарием «не открывай чаще раза в месяц». Твои двадцать вопросов лечат гадание, это правда. Но гадание лечится ещё и признанием, что линейка, по которой меряешь, деревянная — и ты её уже потихоньку обточил под свою руку.

gleb_tomsk писал:
Тест просочился в настройку через твои же глаза.

Ребят, лечится тем же, чем в ML: делить список. Я (в той же сценке) завёл два файла: пятнадцать рабочих вопросов, на которые смотрю при кручении конфига, и десяток «запечатанных», которых не касаюсь до конца недели. Кручу на первых, проверяю на вторых. Плюс раз в пару недель добавляю в запечатанный файл живые вопросы из логов — он потихоньку обновляется и не даёт подогнаться под старый набор.

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

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

Вера, да, одной суммы для выбора мало. В таблице оставлю отдельно найденный факт, выдуманное дополнение и честный отказ. Иначе можно улучшить итог тем, что система начнёт всем отвечать «не знаю», — аккуратно и совершенно бесполезно.

А в ожидаемом ответе я бы писала, что человек должен узнать, а не единственную допустимую фразу. Одна и та же мысль может быть сказана разными словами. Не хочется получить отличную проверку копирования образца вместо проверки понимания.

Тогда для «частично» нужны заранее оговорённые признаки. Если ответ назвал срок, но не условие, это один случай. Если назвал оба, но добавил лишнее, — другой. Без такой записи я сам на хорошем настроении поставлю балл выше, чем вчера)

Вот с отдельной отметкой выдумок и редакцией источника мне понятнее. Для рабочего выбора я бы сперва смотрела на опасные уверенные ответы, потом на полезность, и уже затем на удобство формулировки. Общая сумма остаётся указателем, а решение за человека не принимает.

К проверкам добавлю один условный тест: в архиве две редакции инструкции, в старой срок 14 дней, в действующей — 30. Спрашиваем про действующую. Правильное число со ссылкой на старую редакцию тоже считаем ошибкой: читателю ведь нужно не угаданное число, а основание для ответа.

И мой «запечатанный файл» не спасает, если каждую пятницу посмотреть ошибки и всю неделю чинить именно их)) После такого разбора эта часть уже рабочая. Для следующей независимой проверки нужны новые вопросы, а старые полезно оставить как проверку, что починка ничего не вернула назад.

В начальном списке ещё были сборные вопросы. Возьмём учебное расписание: аудитория записана в одном файле, время — в другом. Если поиск принёс только аудиторию, ответ не должен достраивать время по привычке. Хочу отдельно увидеть такой частичный результат, а не одну отметку «почти правильно».

Тогда в ожидаемом ответе записываю не только «30», но и действующую редакцию. Это удобно проверять вручную: открыла ссылку, нашла место. Если число верное, а подтверждающий фрагмент говорит о другом, такой ответ ещё нельзя показывать ученику как проверенный.

И поправлю собственное «прямые вопросы проверяют совпадение букв». Они тоже проверяют поиск: найдёт ли нужный документ и отдаст ли правильный факт. Просто одних таких вопросов мало. В этом списке нужны разные трудности, а не новая нелюбимая категория взамен старой.

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

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

Тогда рядом с ответом сохраняем и то, что дали модели прочитать. Иначе после очередной перенарезки я открою старый результат, а объяснить его уже не смогу: исходный документ тот же, куски из него стали другими. Получится сравнение без половины условий.

К списку проверок добавила бы две роли с разным доступом к документам. Администратор находит ответ, обычному сотруднику этот файл недоступен. Одинаковый отказ у них будет означать разное. Не хочется оценивать систему только из учётной записи, которой разрешено всё.

Да, сначала определяем, какие материалы доступны этой роли, и только потом проверяем ответ. Нельзя передать лишний фрагмент модели с просьбой «это не раскрывать». В таком варианте лишнее уже попало в запрос, даже если ответ получился вежливым.

Тогда у результата появляется ещё одно условие: для какой роли его получили. Вопрос один, доступные документы разные. «Не нашёл» может быть правильным ответом для одного набора и промахом для другого. Свести их в общий процент — значит опять потерять смысл за красивой цифрой)

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