Как тестировать систему с LLM под капотом? Как бенчмаркать разные LLM? Давайте попробуем разобраться.

В посте про тестирование агентов мы с вами проговорили про тестируемость LLM систем в принципе.

А как именно можно выстроить тестирование отдельных блоков? Как можно проверить качество их работы? Как мы можем подобрать наилучшую модель?

Давайте на примере кода из будушего LLM бенчмарка v2 разберем подход к тестированию систем. Ведь бенчмарки - это просто набор тестов, которые оценивают способности LLM-ок работать с часто встречающимися типами блоков.

Вот кусок кода 👇. Он тестирует блок, который реализует паттерн “Data Extraction”. Тут мы отправляем в Vision Language Model картинку с графиком и задаем вопросы по названиям линий (картинку я добавлю в комментарии).

@requires_vision
def bench_analyse_chart_line(m: Model) -> TestResult:
    attachment = Attachment.image(FOLDER / "chart_colored.png")

    class ChartAnalysis(BaseModel):
        line_name: Optional[str]

    truth_table = [
        ("blue", ["20V", "20 V"]),
        ("purple", ["12V", "12 V"]),
        ("red", ["5V", "5 V"]),
        ("green", ["80", None]),
        ("yellow", ["3.3V", "3.3 V"]),
        ("pink", [None])
    ]

    scores = []

    for color, names in truth_table:
        response = m.generate(
            context="Analyze the chart and answer the question.",
            attachments=[attachment],
            question=f"What is the name of the line colored {color}?",
            response_format=ChartAnalysis,
        )
        score = 1.0 if response.line_name in names else 0.0
        scores.append(score)

    avg_score = sum(scores) / len(scores)
    return TestResult.score(avg_score)

Этот тест и его формулировки взяты из кейса по извлечению параметров электронных компонентов из документации (это вспомогательный блок в проекте).

Исходные данные - это картинка и тестовый dataset, который в коде назван truth_table. Во время запуска этого бенчмарка, мы проходимся по всем строчками в этой таблице, формируем запрос в LLM, получаем ответ и сравниваем его с каноничными вариантами. Если есть совпадение, то присваиваем 1.0, если нет - 0.0. А в итоге считаем среднее.

В LLM бенчмарке v2 таких блоков будет под сотню, на основе разных кейсов и паттернов. Поэтому код каждого блока простой, а таблицы - маленькие и прямо в коде (получаются table-driven tests). Мы аггрегируем оценки модели на разных блоках и получаем ее оценку в бенчмарке в целом.

А в рабочих системах все совсем наоборот - число блоков обычно можно пересчитать по пальцам, а вот таблицы с тестовыми данными будут большие. И мы с этими тестами будем работать иначе:

(1) мы будем менять формат промпта, response schema или даже саму модель, а потом прогонять всю таблицу и смотреть на итоговую оценку качества после этих изменений. Цель - подкрутить так, чтобы качество росло на всех тестах.

(2) если пользователи проекта найдут кейс, который система отрабатывает плохо, мы проанализируем и найдем “сбоящий блок”. Потом, аккуратно внесем данные в тестовые таблицы этого блока и перейдем на шаг (1).

Можно повторять эти шаги для планомерного повышения качества системы.

Если у вас есть проекты, которые непонятно, как тестировать с таким подходом - пишите ситуацию и проблему в комментарии! Можно устроить community brainstorming для подбора путей к решению.

Ваш, @llm_under_hood 🤗