Як AutoSynthData перетворює помилки моделей на навчальні дані для підприємств

Від помилок до навчальної програми

AutoSynthData запускає цільову модель і сильнішого вчителя через діагностичні завдання у цільовому середовищі. Оцінка показує, з якими здібностями цільова модель має труднощі. Виявляються інструменти та структури робочих процесів. Також стає видно, як вчитель досягає успіху там, де цільова модель провалює. Спостереження стискаються до очищених карток специфікацій здібностей. Кожна картка описує здібність та необхідні властивості кінцевого стану. Зазначаються виміри, що можуть змінюватися без втрати суті навички. Генератор отримує лише ці картки. Оригінальні запити та сутності йому не передаються. Траєкторії та деталі верифікатора теж залишаються за кадром. На основі карток створюються нові завдання з іншими запитами та початковими станами. Шляхи вирішення теж змінюються. Навчальна програма змінюється разом із покращенням моделі.

Формування набору даних

Конвеєр працює в два етапи. Цільовий етап формує базовий набір перевірених зразків. Працівники генерують незалежні завдання паралельно з карток здібностей. Кожен кандидат проходить валідацію та виконання в середовищі. Далі йде оцінка решатора та обмежений цикл виправлення перед прийняттям. Етап множення потім розширює набір даних, створюючи нові варіанти прийнятих цільових зразків. Кожен варіант несе власний запит користувача та стан середовища. Конфігурація сутностей і референс-траєкторія унікальні. Верифікатор теж має власний. Зразок, отриманий множенням, не може стати базою для іншого подібного зразка. Це закріплює розширення за перевіреним ядром і обмежує дрифт між поколіннями.

Дворівневий контроль якості

Окремі кандидати мають пройти цикл контролю якості. Оцінка решатора віддає перевагу завданням, які цільова модель вирішує не частіше одного разу з трьох спроб. Сильніший решатор справляється принаймні двічі з трьох. Позитивна верифікація виконує референс-траєкторію і перевіряє отриманий стан за верифікатором кандидата. Негативна верифікація мутує частини очікуваного результату і підтверджує, що такі мутовані стани більше не проходять. Неуспішні кандидати передаються критику. Критик діагносує неузгоджені стани або неможливі робочі процеси. Він також позначає помилкове конструювання завдання. Погані референс-траєкторії теж потрапляють у зону уваги. Слабка логіка верифікатора та невідповідності здібностей виявляються так само. Виправлення керуються діагнозом і повторюються до фіксованого ліміту. Виправлене завдання знову має пройти відповідні перевірки. Пакетний огляд потім аналізує прийняті та відхилені зразки у кожному пакеті. Визначається, які родини завдань перепредставлені, а які виміри здібностей відсутні. Контролер стежить за покриттям у прийнятому наборі. Він зменшує генерацію в перепредставлених областях і спрямовує більше робіт до прогалин. Коли область повторно видає слабких кандидатів, критики напрямляють зміни стратегії генерації. Мета-огляд діє аналогічно. Ці зворотні зв'язки покращують окремі завдання. Вони також покращують набір даних, який ці завдання формують.