"Как тестировать систему с 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 🤗"