Языковые модели в QA
Я давно разрабатываю пет-проекты в рамках исследований генеративных моделей и решения личных задач. На любом из таких проектов всегда была важной фаза обкатки продукта, плагина, скилла и тому подобное. Мне всегда было важно понять: а как вообще отрабатывает система на задуманных сценариях и какие слабые места у него есть? Особенно важно найти слабые места для публичных проектов, где есть риск потерять деньги и создать ненужный геморрой.
Я долго копал, пробовал в лоб давать агентам проводить приемку, и это на самом-то деле давало свои плоды. Я пошел дальше, и понял, что здесь нужна методика. Суть этой методики должна заключаться в том, что любой продукт, подключаемый через адаптер, можно будет проверить в формате симуляций под разными ролями и понять, как он вообще себя покажет. Ключевое слово - симуляции.
А одно из самых классных и сильных возможностей, которые дают нам генеративные модели - комбинаторика решений, которые и позволяют легко создать сценарии для запроса: а что если?
Проектирование началось с заложения базовых принципов. Кстати, по моему мнению, сейчас владение именно принципами гораздо важнее, нежели сухими фактами. Я много раз об этом говорил, и сейчас всё отчетливее вижу картину
Если кратко, как работает концепт. Проект имеет иерархию агентов, которые распределены по ролям для каждой задачи. 1. Агент-аналитик изучает репозиторий и составляет карту системы: что она умеет, где риски, куда можно бить. 2. По этой карте генерируются карточки-сценарии пяти типов: простые, запутанные, критичные, неочевидные и хакерские. В каждую карточку сразу записывается список ожидаемых результатов. 3. Сценарии утверждает человек, 4. Дальше они в изолированной среде прогоняются агентами-исполнителями. Факты до нейросети проверяет детерминированный слой, затем вердикты выносит агент-судья на другой модели. 5. После этого формируется отчет по прогону
Название проекта в Github qa-agent-evals
P.S.: По мере разработки я все чаще замечаю, что в разработке я становлюсь бутылочным горлышком по реализации, потому что очень много времени и энергии тратится на осмысление архитектуры и найденных решений.