DeepSeek подешевшав: що це означає для вашого AI-продукту

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

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

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

Короткий словник

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

Що насправді змінилося: дешевша і розумніша модель відкриває сценарії, які раніше не окупалися

Раніше рішення про AI-функцію впиралося у дві стіни. Модель була недостатньо розумною, тому результат доводилося переробляти руками. Виклик коштував стільки, що масовий сценарій не окупався навіть при добрій якості. Обидві стіни просідають разом: модель краще тримає довгі інструкції і краще користується інструментами, а виклик стає дешевшим.

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

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

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

Чому бали в тестах моделі цікавлять вас найменше

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

Чому вартість запиту нічого не каже: рахуємо вартість одного доведеного до кінця результату

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

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

З чого складається прохід задачі: виклики моделі, повтори і перевірка

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

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

Які задачі стали рентабельними: від обробки заявок до щоденного розбору відгуків

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

Спільне в усіх випадках одне: сценарій був відомий давно, і єдине, що тримало його поза роботою, була економіка проходу.

Від «відповідає на питання» до «доводить задачу до результату»: різниця на одному прикладі

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

Візьміть запит «порівняй, що пишуть про нас і про конкурента». Чат-бот складе гарний текст про важливість репутації. Інструмент зробить інше: зайде у джерела відгуків, витягне згадки за названий період, розкладе їх за темами, перевірить, чи всі джерела відповіли, і віддасть зведення з прикладами цитат.

Різниця тут не в розумі моделі. Обидва варіанти можна зібрати на одній і тій же моделі, бо відрізняються вони описом задачі.

Чому правильна відповідь ще не означає вирішену задачу

Шаблон опису задачі: вхід, крок, інструмент, правило перевірки, результат, дія при збої

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

Поле	Що вписати	Приклад: відповідь на звернення
Вхід	Що приходить і звідки	Лист клієнта з поштової скриньки
Крок	Одна дія, яку можна перевірити окремо	Знайти в умовах пункт, що стосується звернення
Інструмент	Чим крок виконується	Пошук по базі умов, модель для формулювання
Правило перевірки	За чим видно, що крок вдався	У чернетці закриті всі питання зі звернення
Результат	Що лишається після кроку	Чернетка листа з посиланням на пункт умов
Дія при збої	Що робити, коли правило не пройшло	Переписати чернетку, після другої спроби віддати оператору

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

Як заповнити шаблон, якщо процес у вас ніде не описаний

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

Де межа: що нейромережа робить сама, а що лишається рішенням людини

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

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

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

Як виміряти успіх без аналітика: метрики, які знімаються на малих обсягах

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

Метрика	Що показує	Як зняти на малих обсягах
Частка доведених задач	Чи працює сценарій узагалі	Позначка «доведено» або «ні» на кожну задачу
Точність результату	Чи можна довіряти тому, що вийшло	Вибіркова звірка за правилом перевірки
Частка ручних втручань	Де процес ламається регулярно	Відмітка про правок і причина одним словом
Час проходу	Чи стало швидше, ніж було руками	Час появи запиту і час готового результату
Вартість результату	Чи сценарій тягне економічно	Виклики моделі на задачу плюс час людини

Головна з них перша. Решта уточнює картину і підказує, який крок переписувати наступним.

Що робити з уже наявним чат-ботом: перебудова без переписування з нуля

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

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

Чому не варто гнатися за кожною новою версією моделі і як закласти шлях відходу

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

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

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

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

Чек-лист самоперевірки перед впровадженням ШІ в процес

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