Практические советы: как я перестал догадываться и начал измерять эффективность своей системы RAG

В этом руководстве пошагово описывается путь от сырья до функционирующей системы для проекта «Как я перестал догадываться и начал измерять эффективность своей пайплайны RAG» (LLM Zoomcamp 2026, модуль 4). Основное внимание уделяется практическим шагам, четким проверкам и коду, который можно просто добавить в репозиторий без необходимости угадывать его назначение. На этапе обзора необходимо определить входные данные, ответственного за выполнение шага и критерии завершения перед внесением изменений в код. Операторы должны иметь возможность перезапустить шаг с известной точки контроля, не пытаясь угадать скрытое состояние системы. Рекомендуется использовать небольшие, тестируемые единицы вместо обширных скриптов. При сбое шага причина должна быть связана с конкретной функцией, а не с запутанной структурой всей пайплайны.

Почему оценка является наименее ценным аспектом RAG

При работе над этапом «Почему оценка необходима» сначала запишите контракт: требуемые входные данные, сигнал успешного завершения и действия при частичной неудаче. Такой список помогает избегать недобросовестных изменений в коде позже. Рассматривайте этот этап как контракт между входными данными и проверенными выходными результатами. Дайте названия элементам, определите критерии успешности и не допускайте молчаливого частичного выполнения задачи. Храните в кэше стабильные инструкции системы и схемы инструментов. Пересылка одинаковых данных является распространённой причиной избыточных ресурсов.

Создание набора данных истинных значений

При работе над этапом создания исходных данных сначала запишите условия работы: необходимые входные данные, сигнал о успешном выполнении и действия при частичной неудаче. Такой список поможет сохранять честность при последующих изменениях кода. Рядом с функциональными результатами записывайте время выполнения и стоимость токенов или запросов. Отслеживание затрат с самого начала предотвращает неожиданные счета при переходе от демо-среды к общедоступным средам. Храните в кэше стабильные инструкции системы и схемы инструментов. Повторная отправка одинаковых данных — частая причина лишних расходов.

Два важных показателя

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

Результаты, которые меня удивили

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

Функция evaluate(), которая меняет всё

Функция оценки на данном этапе работает наилучшим образом, если рассматривать её как измеримую поверхность. Зафиксируйте один идеальный пример работы, один случай сбоя и записку о возврате к предыдущему состоянию перед расширением объёма задачи. Записывайте время выполнения и стоимость токенов или запросов рядом с функциональными результатами. Отображение стоимости на раннем этапе предотвращает неожиданные счёты при переходе от демо-среды к общедоступным средам. Установите лимит токенов на один ход и на одну сессию. Инструменты агентов активно расширяют контекст; жёсткие ограничения не позволяют демо-версиям превращаться в неожиданные счёты.

def evaluate(search_func, ground_truth):
    hit_rates, mrrs = [], []
    for record in ground_truth:
        results = search_func(record["question"])
        relevance = compute_relevance(record, results)
        hit_rates.append(hit_rate(relevance))
        mrrs.append(mrr(relevance))
    return {"hit_rate": sum(hit_rates)/len(hit_rates),
            "mrr": sum(mrrs)/len(mrrs)}

Полное решение

Этап «Полное решение» работает наилучшим образом, когда его рассматривают как измеримую поверхность. Соберите один идеальный пример работы, один случай сбоя и записку о возврате к предыдущему состоянию перед расширением объема работ. Храните конфигурацию вне кода приложения. Файлы среды, хранилища секретов и флаги функций должны находиться в одном месте, чтобы операторы могли их проверять, не читая весь код. Установите лимиты на количество токенов за раунд и сессию. Инструменты типа агентов активно расширяют контекст; жесткие ограничения предотвращают появление неожиданных счетов. Этап «Полное решение» работает наилучшим образом, когда его рассматривают как измеримую поверхность. Соберите один идеальный пример работы, один случай сбоя и записку о возврате к предыдущему состоянию перед расширением объема работ. Предпочитайте небольшие, тестируемые единицы кода вместо обширных скриптов. Когда какой-то шаг сбивается, причина сбоя должна указывать на конкретную ответственность, а не на запутанную цепочку операций.

Чек-лист для работы

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

Задокументируйте одновременно успешный сценарий работы и сценарий восстановления. Повторные попытки, проверки человеком и обработка неработоспособных сообщений являются частью продукта, а не последующими доработками.

Установите лимиты на количество операций за один раз и за сессию. Инструменты агентов активно расширяют объем контекста; жесткие ограничения предотвращают превращение демонстраций в неожиданные счета.

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

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