Як користуватися кількома моделями ШІ разом (чотири схеми, які працюють)

Чому однієї моделі недостатньо

Звичний аргумент на користь кількох моделей ШІ звучить так: кожна в чомусь краща, тож обирайте найкращу під завдання. Це правда, але це найменш цікава причина.

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

Друга причина практична: лідерство серед моделей постійно змінюється. Той, хто найкращий у програмуванні цього кварталу, може не бути найкращим наступного. Робочий процес, побудований навколо одного постачальника, доводиться перебудовувати щоразу, коли зміщується рейтинг. Робочий процес, побудований на ідеї, що ви міняєте моделі, такої проблеми не має.

Далі йдуть чотири схеми, у порядку від тієї, що дає найбільше користі щодо витрачених зусиль. Вам не потрібні всі чотири. Більшість людей отримує майже все від перших двох.

Схема 1: чернетка, потім критика від іншої моделі

Найцінніша схема, і та, якою майже ніхто не користується. Пишете однією моделлю, перевіряєте іншою.

Вона працює, бо створювати й оцінювати, це різні роботи. Модель, яка породжує текст, оптимізує зв'язне продовження. Модель, яка оцінює текст, написаний не нею, не має жодного інтересу в цьому аргументі, тож вона просто скаже, що третій абзац не випливає з попереднього, замість того щоб згладити це.

Формулювання тут важить надзвичайно багато. Запитання «що ти про це думаєш» принесе вам компліменти. Просіть натомість ось так:

Наведений нижче текст написали не ви, і ви не маєте в ньому жодного інтересу. Перегляньте його як скептичний редактор. Перелічіть, у такому порядку: 1) будь-яке фактичне твердження, яке хибне, непідкріплене або надто категоричне, 2) будь-яке місце, де аргумент насправді не випливає, 3) один найслабший абзац і точно чому. Нічого не переписуйте. Не розповідайте мені, що тут доброго.

Справжню роботу роблять три інструкції в кінці. «Нічого не переписуйте» не дає їй видати версію власним голосом, про яку ви не просили. «Не розповідайте, що тут доброго» прибирає рефлекторну похвалу, якою напханий майже будь-який відгук від ШІ. «Це написали не ви», це напрочуд дієве формулювання, бо воно зупиняє модель від захисту рішень, які вона вважає своїми.

Потім поверніть критику першій моделі разом із тими пунктами, з якими ви згодні. Ви редактор, який вирішує, які зауваження прийняти, і це саме той поділ праці, який тут потрібен.

Де ці дві додаткові хвилини варті витрат: усе, що йде клієнту, усе публічне, усе, де помилитися дорого. Де не варті: повідомлення в робочому чаті, чорновий план, список покупок.

Схема 2: перевірка розбіжностей

Це найближче до надійного детектора галюцинацій, що не вимагає перевіряти вручну геть усе.

Поставте двом різним моделям одне й те саме фактичне запитання, незалежно одна від одної, з тим самим формулюванням. Потім порівняйте. Там, де вони збігаються, у вас, імовірно, усе гаразд. Там, де вони розходяться, ви знайшли точно те місце, яке треба перевірити.

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

Якщо тверджень кілька, доручіть саме порівняння моделі:

Нижче наведено дві відповіді на те саме запитання, позначені A і B. Не зважайте на стиль і довжину. Перелічіть кожен змістовний пункт, у якому вони розходяться, зокрема різницю в числах, датах, іменах і в тому, наскільки категорично щось стверджується. Для кожної розбіжності скажіть, що ймовірніше правильне і яке одне джерело це б вирішило.

У підсумку ви маєте короткий список того, що треба перевірити, замість довгого документа на фактчекінг, і цей список зазвичай правильно вказує, де саме проблеми.

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

Застосовуйте до: статистики, юридичних і медичних тверджень, історичних фактів, деталей API, усього, що вам потім цитуватимуть. Пропускайте на: думках, творчій роботі і всьому, де бути приблизно правим цілком достатньо.

Схема 3: маршрутизація за завданням

Очевидна схема, яку варто робити як слід. Надсилайте кожен вид роботи тій моделі, яка в ньому найкраща, замість того щоб надсилати все туди, що у вас відкрито.

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

Одна звичка, яку варто виробити: перестаньте діяти за замовчуванням. Більшість людей використовує для всього ту модель, яку дала їхня підписка, зокрема й для завдань, у яких вона слабка, а потім робить висновок, що ШІ погано з цим справляється. Десять секунд роздумів про те, яка модель пасує, змінюють результат більше, ніж година підбору формулювань.

Розгорнуту версію цього рішення дивіться в як обрати модель ШІ, а що таке контекстне вікно пояснює, чому в таблиці є рядок про довгі документи.

Схема 4: естафета з письмовою передачею

У роботі, яка складається з кількох етапів, збій стається на стиках. Ви пояснюєте проєкт одній моделі, доходите до чогось корисного, потім переходите до іншої і або вставляєте стіну історії, або знову все пояснюєте, тільки гірше.

Виправляється це прямим проханням про передачу перед перемиканням:

Напишіть бриф передачі для іншого асистента, який не бачив цієї розмови. Включіть: що ми намагаємося зробити, які рішення вже ухвалено і чому, обмеження і чого уникати, що вже пробували й відкинули, і що саме мені потрібно далі. Будьте достатньо конкретні, щоб він міг продовжити, не ставлячи мені жодних запитань.

Це корисно, навіть коли ви не міняєте модель. Це найчистіший спосіб вибратися з довгої розмови, яка стала повільною і розмитою, бо ви зберігаєте суть і скидаєте накопичений шум. Вставте бриф у новий чат, і якість зазвичай одразу підскакує.

Реалістична естафета виглядає так. Віддайте звіт на 200 сторінок моделі з великим контекстом і попросіть структурований підсумок із десятьма важливими уривками, поданими цитатами. Занесіть їх у сильну модель для письма й зробіть записку для клієнта. Проженіть прохід критики зі схеми один через третю модель. Загалом близько п'ятнадцяти хвилин, і на кожному етапі працював придатний саме для нього інструмент.

Коли не варто морочитися

Мультимодельні процеси мають свою ціну, і вдавати інше, це прямий шлях до складної процедури заради листа на два рядки.

Беріть одну модель, коли: завдання невелике, ціна помилки низька, ви радше досліджуєте, ніж виробляєте, ви швидко ітеруєте і зайве тертя збило б вас із ритму, або робота справді творча і друга думка лише замулює ваш голос.

Беріть дві чи більше, коли: результат іде іншій людині, важлива фактична точність, у завданні є окремі етапи, які потребують різних сильних сторін, ви застрягли й вам потрібен справді інший кут зору, або ви от-от ухвалите рішення на основі сказаного моделлю.

Розумне правило: якщо ви попросили б колегу глянути на це, попросіть другу модель. Якщо не попросили б, не робіть цього.

Як зробити це практичним

Усе це просте в теорії і дратівливе на практиці, якщо кожна модель живе за окремою підпискою. Тертя реальне: окремі вкладки, окремі історії, копіювання контексту між ними, втрачене форматування і той невеликий опір, через який ви пропускаєте прохід критики саме того дня, коли він найпотрібніший.

Саме через це тертя описані вище схеми й використовують надто рідко. Вони не складні, вони просто достатньо марудні, щоб їх пропустити, коли ви зайняті.

Ось для чого існує мультимодельний робочий простір. У Whizi моделі сидять в одній розмові, тож прохід критики, це перемкнути модель і запитати, а не відкрити інший продукт і вставити туди свою чернетку. Одна історія, один пошук по всьому, що ви колись запитували, один рахунок. Подивіться перемикання моделей посеред розмови і порівняння моделей поруч, щоб побачити, як ці два кроки працюють насправді.

Якщо вам більше до вподоби зібрати це самотужки з окремих підписок, ці схеми все одно працюють, і користуватися ними варто. Змінюється лише те, наскільки часто вам вистачить сил. Якщо ви вже платите за два чи три плани, щоб це стало можливим, спершу запустіть калькулятор економії, бо зазвичай це дорожчий шлях до того самого результату.

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