Для яких офісних задач достатньо невеликої і недорогої моделі

Коротка відповідь: твердження «невеликої моделі достатньо для 80% рутинних офісних задач» не має універсальної перевіреної основи. Частка задач, які впевнено виконує компактна модель, залежить від портфеля задач конкретної компанії, мови документів, вимог до якості і ціни помилки. Але є класи задач, з яких варто починати перевірку: класифікація звернень за відомим списком категорій, вилучення полів із документів зі стабільною структурою, коротке резюме тексту з чітким форматом.

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

Чому 80% не можна взяти з повітря

Питання зазвичай звучить так: «Чи вистачить компактної недорогої моделі для 80% рутинних задач?» Тут дві проблеми.

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

Друга — 80%. Відсоток має сенс лише відносно конкретного переліку задач із їхньою фактичною частотою. В одному офісі 70% потоку — однотипні заявки, які легко класифікувати. В іншому половина роботи — нестандартні договори й переговори. Середнє між ними нічого не скаже ні першому, ні другому.

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

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

Де компактна модель — кандидат

Компактні моделі добре підходять для задач з кількома спільними рисами:

• Обмежений набір відповідей. Класифікація звернення за 10–20 категоріями, визначення мови, тональності, пріоритету.
• Відома схема полів. Вилучення номера рахунку, дати, суми, контрагента з документів однакового типу.
• Короткий контекст. Лист, повідомлення в чаті, одна сторінка документа, а не стоп’ятдесятисторінковий договір.
• Зрозумілі винятки. Що робити, якщо поле відсутнє чи категорія не підходить, — описано наперед.
• Перевірюваний результат. Відповідь можна автоматично перевірити правилами: сума — число, дата — у допустимому діапазоні, категорія — зі списку.

Ось як можна попередньо розкласти типові офісні задачі. Це навчальна класифікація для старту, а не результат тесту: остаточне рішення по кожному рядку дає лише перевірка на ваших даних.

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

Такі задачі часто становлять великий обсяг, а ціна одного виклику для них низька. Наприклад, у знімку стандартного тарифу для короткого контексту, перевіреному 11.10.2026, gpt-6-luna коштує $0,10 за мільйон вхідних і $0,50 за мільйон вихідних токенів. Існують і відкриті компактні моделі для власного розгортання, наприклад Qwen3-8B за ліцензією Apache 2.0; заявлена підтримка понад сотні мов не гарантує якості на конкретному наборі задач. Але ні ціна, ні розмір, ні заявлена підтримка мов не доводять, що модель упорається саме з вашими українськими документами — це перевіряється тестом.

Де потрібна додаткова перевірка

Є задачі, де компактна модель може дати переконливу, але неправильну відповідь, і де помилка дорога:

• Неоднозначні договори. Умови, які залежать від інших пунктів, посилання на додатки, юридично значущі формулювання.
• Складні міркування. Розрахунки з кількома кроками, порівняння варіантів за багатьма критеріями, висновки з неповних даних.
• Довгі залежності. Відповідь залежить від інформації, розкиданої по довгому документу чи листуванню.
• Висока ціна помилки. Гроші, персональні дані, юридичні наслідки, комунікація з ключовим клієнтом.

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

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

Як організувати порівняння

Чесне порівняння моделей має кілька обов’язкових умов:

• Однакові входи. Той самий набір реальних задач — знеособлених, якщо там є персональні дані — для всіх моделей.
• Еталони. Для кожної задачі заздалегідь записано правильний результат. Їх готують люди, які знають процес.
• Зафіксовані версії. Точна назва і версія моделі, дата тесту, налаштування. Інакше через місяць результат неможливо буде відтворити.
• Мова. Якщо робота українською, тестовий набір українською — включно з суржиком, помилками і змішаними мовами, якщо вони трапляються в реальному потоці.
• Однакові критерії. Правильна категорія, точні значення полів, відповідність формату. Не «яка відповідь красивіша»: гарний стиль легко сплутати з правильністю.
• Однаковий промпт або окремо налаштований під кожну модель — але тоді це треба записати.

Скільки прикладів потрібно, залежить від частоти помилок і різноманітності задач. Для першого відсіву вистачить кількох десятків прикладів на клас задач; для рішення про запуск у робочий процес — більше, з окремою увагою до рідкісних, але дорогих випадків.

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

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

Як побудувати ескалацію

Компактна модель не повинна вирішувати все сама. Потрібен механізм передачі задачі далі — сильнішій моделі або людині. Сигнали для ескалації мають бути зовнішніми й перевірюваними:

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

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

Навчальний приклад правил для рахунків: компактна модель вилучила номер, дату, суму і податковий номер постачальника. Далі код перевіряє, що сума — додатне число, дата — не в майбутньому і не старша за рік, податковий номер має правильну довжину і є в довіднику контрагентів, а сума збігається з сумою замовлення. Якщо хоча б одна перевірка не пройдена, рахунок іде на сильнішу модель; якщо і після цього розбіжність лишається — бухгалтеру з позначкою, яке саме правило спрацювало. Людина бачить не «модель не впевнена», а конкретну причину, і перевіряє швидше.

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

Як розрахувати свою частку

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

Навчальний портфель задач

Це ілюстрація методу, а не результат проведеного тесту. Припустимо, за місяць надходить 1 000 задач: 600 — класифікація звернень, 250 — вилучення полів із рахунків, 150 — складні відповіді клієнтам.

Якщо перші два класи на контрольному наборі пройшли заздалегідь задані критерії, потенційне охоплення компактною моделлю — (600 + 250) ÷ 1 000 = 85% цього потоку. Але це не частка успішно оброблених задач: усередині класів теж бувають помилки й ескалації.

Додамо навчальні припущення: 5% класифікацій і 10% вилучень не проходять перевірку правилами і йдуть на сильнішу модель. Розміри запитів теж умовні: класифікація — 1 500 вхідних і 50 вихідних токенів, вилучення — 3 000 і 300, складна відповідь — 6 000 і 800. Для навчального розрахунку використано тарифи Standard для короткого контексту, перевірені 11.10.2026: gpt-6-luna — $0,10 / $0,50 за мільйон токенів, gpt-6.1-sol — $2 / $10.

Для порівняння: якби все обробляла сильніша модель, модельний рахунок склав би 600 × $0,0035 + 250 × $0,009 + 150 × $0,02 = $7,35.

Частка задач, оброблених компактною моделлю без ескалації: 570 + 225 = 795, тобто 79,5%, а не 85%.

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

Підсумок і перші кроки

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

Що зробити:

1. Скласти перелік задач з фактичною частотою за місяць і ціною помилки для кожного класу.
2. Вибрати 2–3 класи-кандидати: обмежені відповіді, відома схема, короткий контекст, перевірюваний результат.
3. Зібрати контрольний набір реальних знеособлених прикладів з еталонами українською.
4. Протестувати кілька моделей з однаковими входами, зафіксованими версіями і критеріями.
5. Описати правила ескалації і ліміт повторів.
6. Порахувати потенційне охоплення, фактичну частку без ескалації і вартість прийнятого результату з урахуванням помилок.

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

Часті запитання