(по мотивам вопроса в community курса)
Фишка в том, чтобы не пытаться тестировать ответы системы человеку напрямую - это бесполезное и неблагодарное дело.
Скажем, есть вопрос "Which requirements to implement and test business continuity plans does the contract specify?", а ответ - "The contract specifies these requirements for implementing and testing business continuity plans..."
Можно, конечно, набрать пары вопрос-ответ, а потом использовать "LLM as a Judge" для сравнения каноничного ответа с тем, который выдает система. Но этот путь выложен граблями.
Вместо этого можно, например, попытаться упростить себе жизнь и разделить систему на две части: (1) сложную, но тестируемую и (2) простую, но тестируемую плохо. Первая часть будет решать сложные задачи, но выдавать ответы в том виде, который можно проверить автоматически. А вторая часть уже будет разворачивать машино-проверяемые ответы в те, которые поймет человек.
Пример ответа, который можно проверить автоматически:
{ "relevant_sections": [ "2.2.1", "3.15", "6.1" ] }
Бенчмарк для данного агента будет состоять в виде таблицы "вопрос" - "relevant_sections". Мы будем отправлять их в систему, получать
relevant_sections и сравнивать их с каноничными используя, например, Jacard Index. Считаем среднее и получаем качество работы системы в данной версии.Это простой пример, в жизни бывают ситуации и посложнее. Но он демонстирует основной принцип - при создании архитектуры изначально выбирать границы логических блоков так, чтобы самые сложные части всегда было просто тестировать. А если можно тестировать, то можно не только контроллировать качество, но и планомерно его улучшать.
Пост: Как может выглядеть код для тестирования?
Ваш, @llm_under_hood 🤗
PS: Для тех, кто любит distributed systems, есть одна из самых вдохновляющих презентаций на тему тестирования сложных систем - от создателей FoundationDB: Testing Distributed Systems w/ Deterministic Simulation.