Не кожній бізнес-задачі потрібен Claude: як обрати між кодом, ML, LLM і людиною

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Привіт, спільното DOU!

Мене звати Ярослав Кацалай, я CTO та співзасновник One Service Consulting. Ми допомагаємо компаніям наводити лад в бізнес-процесах, обирати та впроваджувати ERP-системи.

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

Від передбачуваного до гнучкого

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

Для себе я склав таку архітектуру можливих сценаріїв:

1. описати чіткі правила в коді;
2. застосувати машинне навчання для пошуку закономірностей;
3. використати генеративний AI для роботи з нечіткими запитами;
4. залишити людину для прийняття рішення (так, в даному контексті людський фактор доповнює автоматизацію, а не суперечить їй).

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

Код: коли результат має бути точним

Код добре працює там, де логіка відома й може бути описана правилами «якщо X, то Y». Наприклад, це може тут «розрахувати суму, податок або знижку», або «перевірити формат реквізитів», або «заблокувати операцію при перевищенні ліміту». З останнього досвіду — створити документ за визначеною умовою. Тут логіка в тому, що за однакових вхідних даних алгоритм завжди повертає однаковий результат.

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

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

ML: коли потрібно знайти закономірність

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

І цей напрям теж активно розвивається, хоча далеко не має такого хайпу як LLM. До прикладу, Google нещодавно випустили TabFM. Він дозволяє без довгого навчання ML моделей на льоту працювати з вашими табличними даними для їх класифікації. Щоб навчити ШІ, розуміти її, людині треба довго «готувати» дані: чистити помилки, підписувати стовпчики та створювати формули. Проте TabFM вміє читати таблиці одразу, без підготовки. Він дивиться на таблицю як на текст чи книгу, миттєво схоплює логіку і може одразу робити прогнози (наприклад, який товар розкуплять наступним).

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

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

LLM: коли потрібно зрозуміти текст або людську мову

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

Але мовна модель не гарантує стовідсоткової точності. Вона може сформулювати переконливу, проте неправильну відповідь.

Тому в бізнес-системах часто потрібна комбінація. Розповсюджений приклад:

• LLM розуміє запит;
• код виконує точний розрахунок або перевірку;
• LLM пояснює результат користувачу.

Коли потрібні RAG і MCP

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

Але знову повторюся — якщо документи застарілі або суперечать один одному, AI не зробить їх правильними.

Щодо MCP — цей інструмент або інша інтеграція дає моделі можливість отримувати актуальні дані з ERP та виконувати дії в системі.

Наприклад:

• «Покажи клієнтів із найбільшим простроченням по оплаті»;
• «Які залишки цього товару на складах?»;
• «Сформуй чернетку заявки на закупівлю»;
• «Поясни відхилення фактичних витрат від бюджету».

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

Людина в контурі

Зазвичай коли ми говоримо про автоматизацію, то в першу чергу маємо на увазі прибрати людський фактор. Тож як людина і автоматизація таки можуть поєднуватися? Тут мається на увазі, що людина не продовжує виконувати роботу вручну, а починає контролювати автоматизоване виконання. Для цього навіть є свій термін — human-in-the-loop. Тобто людина може підтверджувати критичні дії, перевіряти результат, розбирати сумнівні випадки або ухвалювати остаточне рішення.

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

Загальне правило: що вища ціна помилки, то більше людського контролю потрібно залишити в процесі.

Як це працює в ERP: п’ять груп кейсів

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

1. Документи та корпоративні знання

Один із найбільш зрозумілих сценаріїв — це обробка первинних документів.

Працівник завантажує скан або фотографію рахунку. LLM розпізнає зміст, а код перевіряє реквізити, виконує точні розрахунки та створює чернетку документа в ERP.

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

2. AI-копілот

Копілот дозволяє працювати з ERP без знання структури звітів або мови запитів.

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

LLM відповідає за розуміння запиту та пояснення, але самі цифри має отримувати з ERP.

3. Якість даних

AI може знаходити потенційні дублікати, суперечливі реквізити та неповні картки.

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

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

4. Фінанси

У фінансових процесах добре видно розподіл ролей між технологіями.

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

Один універсальний AI тут не замінить усі компоненти.

5. Постачання та виробництво

ML може прогнозувати попит, час постачання або ризик поломки обладнання.

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

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

З чого починати

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

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

Коротка послідовність вибору

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

Інструменти AI змінюються дуже швидко. Задача, яка вчора вимагала окремої ML-моделі, сьогодні може вирішуватися вбудованою функцією LLM. А проєкт складного AI-агента іноді можна замінити одним правильно налаштованим правилом або звітом.

Тому повернуся до свого першочергового меседжа — починати потрібно не з моделі, а з бізнес-задачі, якості даних, допустимого ризику та очікуваного результату. На моє переконання, найкорисніше вміння в роботі зі штучним інтелектом на сьогодні, враховуючи хайп навколо, — це розуміти коли AI НЕ потрібен.