WEBVTT

00:00:00.000 --> 00:00:03.960
Ваші лоу-коуди автоматизації ламаються, бо вони занадто розумні для власного блага.

00:00:04.060 --> 00:00:08.120
Жорстка логіка, якщо то, це смертний вирок, коли ви стикаєтеся з безладом реальних даних,

00:00:08.220 --> 00:00:09.860
що щодня обвалюють ваші системи.

00:00:10.080 --> 00:00:13.240
Припущення, що дані чисті, це першородний гріх лоу-коуд дизайну.

00:00:13.360 --> 00:00:17.880
Ми побудували весь наш світ на моделі, якщо то, але ця модель потребує абсолютної визначеності для роботи.

00:00:18.020 --> 00:00:19.480
Реальні дані не є визначеними.

00:00:19.640 --> 00:00:20.940
У них є друкарські помилки.

00:00:21.120 --> 00:00:22.460
У них бракує контексту.

00:00:22.580 --> 00:00:24.460
Це хаотичний потік людських помилок.

00:00:30.000 --> 00:00:30.760
Просто ламається.

00:00:30.940 --> 00:00:35.800
Це створює пастку крихкості, де ваша автоматизація настільки надійна, наскільки надійна найчастіша точка даних.

00:00:35.900 --> 00:00:38.180
Для бізнесу це дуже низька планка для успіху.

00:00:38.320 --> 00:00:41.800
Але проблема не в даних, а в моделі, яку ми використовуємо для їх обробки.

00:00:42.000 --> 00:00:43.280
Смерть детермінізму.

00:00:43.740 --> 00:00:46.900
Детермінована логіка – це релікти епохи структурованих даних.

00:00:46.960 --> 00:00:53.080
Вона працювала, коли все жило в SQL-таблицях, і працювала, коли ми змушували людей вписуватися у визначені рамки.

00:00:53.080 --> 00:00:54.320
Але той світ минув.

00:00:54.320 --> 00:01:00.280
Сьогодні 80% корпоративних даних не структуровані, тобто вони містяться в листах, чатах та записах розмов.

00:01:00.420 --> 00:01:06.140
Традиційні потоки Pava Automate сприймають Яблука та 4PPL3 як два різні всесвіти.

00:01:06.640 --> 00:01:09.520
Для бінарної системи це зовсім не пов'язані рядки.

00:01:09.700 --> 00:01:15.000
Ми досягли критичної точки, коли вартість ручного очищення даних перевищує цінність самої автоматизації.

00:01:15.000 --> 00:01:20.680
Якщо вам потрібно витратити 2 години на виправлення CSV лише для того, щоб потік відпрацював 5 секунд, ви насправді нічого не автоматизували.

00:01:20.820 --> 00:01:22.700
Ви просто переклали роботу на інші плечі.

00:01:22.700 --> 00:01:26.520
ЩІ – це не просто блискуча нова функція, яку ми додаємо з боку до Pava Platform.

00:01:26.740 --> 00:01:29.880
Це фундаментальний перехід від точного збігу до подібності.

00:01:30.140 --> 00:01:32.080
Стара модель запитує, чи є це А.

00:01:32.220 --> 00:01:34.600
Нова модель запитує, наскільки це схоже на А.

00:01:34.740 --> 00:01:37.080
Подумайте про те, як ви орієнтуєтеся у своїй пошті.

00:01:37.200 --> 00:01:39.560
Ви не запускаєте регулярний вираз у голові, щоб знайти рахунок.

00:01:39.700 --> 00:01:41.020
Ви шукаєте закономірності.

00:01:41.160 --> 00:01:42.240
Ви шукаєте контекст.

00:01:42.240 --> 00:01:47.600
Ви розумієте, що INV202 і рахунок номер 202 – це одне і те саме, навіть якщо символи не збігаються.

00:01:47.600 --> 00:01:49.740
Детерміновані системи не можуть цього зробити.

00:01:49.900 --> 00:01:50.980
Вони сліпі до намірів.

00:01:51.140 --> 00:01:52.520
Вони бачать лише синтаксис.

00:01:52.660 --> 00:01:56.800
І в міру наближення до 2026 року синтаксис стає менш важливим, ніж семантика.

00:01:56.960 --> 00:02:02.780
Ми спостерігаємо масивний вибух обсягів даних від AdSensor, потоків у реальному часі та підсумків згенерованих LLM.

00:02:02.940 --> 00:02:08.280
Якщо ви спробуєте керувати цим обсягом за допомогою жорстко закудованих розгалужень, якщо то ваша логіка перетвориться на лабіринт.

00:02:08.280 --> 00:02:14.120
Ви отримаєте потоки з 50-ма вкладеними умовами, і вони все одно зламаються в той самий момент, коли постачальник змінить підпис у своєму листі.

00:02:14.260 --> 00:02:18.640
Модель, якщо то, передбачає ідеальний світ, де вхідні дані завжди відповідають схемі.

00:02:19.080 --> 00:02:20.620
Але насправді все навпаки.

00:02:21.060 --> 00:02:22.080
Дані – це змінна.

00:02:22.280 --> 00:02:26.940
Логіка мала б бути константою, але наша логіка була занадто жорсткою для зіткнення з реальністю.

00:02:27.100 --> 00:02:32.640
Ми будували скляні будинки у світі, де постійно йде град, а потім дивуємося, чому підлога вкрита уламками.

00:02:32.640 --> 00:02:36.780
Перехід до імовірнісного проєктування – це будівництво з гуми, а не зі скла.

00:02:36.960 --> 00:02:41.400
Це створення систем, які можуть витримати наслідки одруку, не розбиваючись.

00:02:41.520 --> 00:02:48.720
Ми відходимо від ідеї, що система повинна бути на 100% правильною або на 100% помилковою, бо в реальному світі нічого не є 100%.

00:02:48.720 --> 00:02:51.660
Ми десятиліттями брехали собі про якість наших даних.

00:02:51.780 --> 00:02:58.180
Ми будували чисті кімнати для нашої логіки, а потім вдавали подив, коли брудні дані від відділу продажів спричиняли збій усієї системи.

00:02:58.180 --> 00:03:00.620
Смерть детермінізму – це смерть цієї брехні.

00:03:00.620 --> 00:03:05.000
Це визнання того, що ми не можемо контролювати вхідні дані, тому мусимо модернізувати обробку.

00:03:05.160 --> 00:03:11.280
Ми вступаємо в еру наближеного підприємства, де приймаємо те, що достатньо близько – це краще, ніж точно неправильно.

00:03:11.480 --> 00:03:19.180
Оскільки система, яка може обробити 90% збіг, нескінченно цінніша, ніж та, що відхиляє все, крім 100% збігу.

00:03:19.340 --> 00:03:22.020
Це не лише технічна зміна, це психологічна зміна.

00:03:22.200 --> 00:03:27.260
Ви повинні звикнути до думки, що ваша система може бути лише досить впевненою щодо певної частини даних.

00:03:27.260 --> 00:03:32.720
Ви повинні навчитися проєктувати з урахуванням сумніву, бо сумнів – єдиний чесний спосіб обробки неструктурованої інформації.

00:03:32.880 --> 00:03:39.120
Цей сув вимагає переходу від бінарних тригерів до чогось більш нюансованого – показника впевненості архітектури невизначеності.

00:03:39.280 --> 00:03:43.860
Якщо ми визнаємо, що ера бінарної логіки закінчилася, нам слід замінити її новою структурою.

00:03:44.040 --> 00:03:46.340
Я називаю це моделью симфонічного оркестру.

00:03:46.340 --> 00:03:53.320
У традиційній IT-архітектурі кожен – соліст, що грає за жорсткою партитурою, і якщо хтось пропускає хоча б одну ноту, увесь виступ зупиняється.

00:03:53.480 --> 00:03:57.960
Але в імовірнісній архітектурі у нас є детерміновані диригенти, які керують імовірнісними музикантами.

00:03:58.140 --> 00:04:03.280
Диригент – це ваш потік, пава-отомейт. Він забезпечує структуру, задає темп і визначає межі.

00:04:03.280 --> 00:04:10.480
Музиканти – це моделі щі. Вони талановиті, але експресивні і не завжди потрапляють у ту саму частоту щоразу, коли грають.

00:04:10.680 --> 00:04:13.860
Робота диригента не в тому, щоб змусити музикантів бути роботами.

00:04:14.060 --> 00:04:18.060
Вона в тому, щоб слухати їх і вирішувати, чи достатньо хороший їхній звук, щоб продовжувати.

00:04:18.060 --> 00:04:21.900
Це підводить нас до головного стовпа сучасного дизайну – показника впевненості.

00:04:22.040 --> 00:04:25.960
Оцінка впевненості – це значення від нуля до одиниці, що кількісно визначає сумнів.

00:04:26.100 --> 00:04:30.560
Це спосіб моделі сказати «Я думаю, що це збіг, і ось скільки я готова поставити на це».

00:04:33.280 --> 00:04:36.140
Якщо тема листа містить слово «рахунок», то збережіть вкладення.

00:04:36.320 --> 00:04:39.280
У новому світі ми використовуємо маршрути за цію на основі впевненості.

00:04:39.440 --> 00:04:42.180
Ми робимо внутрішній сумнів моделі, видимим для системи.

00:04:42.300 --> 00:04:47.540
Ми більше не розглядаємо щі як чорну скриньку, а ставимося до нього як досвідка з певним рівнем довіри.

00:04:47.540 --> 00:04:50.060
Ось як це насправді побудувати у PAVA Platform.

00:04:50.240 --> 00:04:54.180
Коли ви використовуєте AI-білда або Azure AI, ви отримуєте не лише вилучені дані.

00:04:54.340 --> 00:04:58.060
Ви отримуєте рівень метаданих, який розкриває ймовірність для кожного окремого поля.

00:04:58.060 --> 00:05:03.820
Якщо модель вилучає загальну суму 1500 доларів, вона також повідомляє, що впевнена в цьому числі на 95%.

00:05:03.820 --> 00:05:06.640
Як архітектор, ви тепер маєте три чіткі зони дій.

00:05:06.760 --> 00:05:08.020
Перша – зелена зона.

00:05:08.260 --> 00:05:10.780
Впевненість 0,90 або вище.

00:05:10.780 --> 00:05:15.160
Ризик помилки низький, вартість помилки керована і результат полягає в автоматизації.

00:05:15.340 --> 00:05:17.400
Система працює без втручання людини.

00:05:17.560 --> 00:05:18.720
Друга – жовта зона.

00:05:18.940 --> 00:05:21.880
Впевненість від 0,60 до 0,89.

00:05:22.520 --> 00:05:24.620
Модель досить впевнена, але непевна на всі 100.

00:05:24.620 --> 00:05:27.780
Можливо, документ був трохи розмитим або почерк був нерозбірливим.

00:05:27.900 --> 00:05:29.540
У цій зоні ви ставите позначку.

00:05:29.760 --> 00:05:32.420
Система спрямовує дані рецензенту для швидкої перевірки.

00:05:32.580 --> 00:05:33.780
Третя – червона зона.

00:05:34.000 --> 00:05:35.620
Впевненість нижче 0,60.

00:05:36.140 --> 00:05:37.240
Модель просто вгадує.

00:05:37.240 --> 00:05:39.480
У цій зоні ви відхиляєте або ескалюєте.

00:05:39.640 --> 00:05:42.280
Ви не допускаєте ці дані до вашої робочої бази даних.

00:05:42.380 --> 00:05:44.280
Це прозорий рівень управління ризиками.

00:05:44.440 --> 00:05:47.760
Це дозволяє масштабувати автоматизацію, зберігаючи запобіжний клапан.

00:05:47.760 --> 00:05:49.680
Подумайте про наслідки для управління.

00:05:49.820 --> 00:05:52.360
У детермінованій системі помилки залишаються непомітними.

00:05:52.500 --> 00:05:56.620
Потік запускається, вибирає неправильне число через одруківку і записує його у вашу ERP.

00:05:56.780 --> 00:05:58.920
Ви дізнаєтеся про це лише наприкінці кварталу.

00:05:58.920 --> 00:06:01.340
У ймовірнісній системі помилка має свою ознаку.

00:06:01.500 --> 00:06:06.220
Система знає, що їй важко, і каже вам «Гей, я це опрацювала, але моя впевненість лише 62%.

00:06:06.220 --> 00:06:07.860
Це неймовірно потужний сигнал.

00:06:08.020 --> 00:06:09.800
Він дозволяє створити панель сумнівів.

00:06:09.940 --> 00:06:12.100
Ви можете точно бачити, де ваші моделі дають збій.

00:06:12.100 --> 00:06:18.000
Ви бачите, які постачальники надсилають документи, які ще не може прочитати, і які кроки процесу постійно потрапляють у жовту зону.

00:06:18.100 --> 00:06:21.080
Ви не просто будуєте потік, ви будуєте інтелектуальний цикл.

00:06:21.180 --> 00:06:24.120
І саме тут Azure AI та AI Builder справді виблизкують.

00:06:24.240 --> 00:06:29.600
Вони надають ці показники на детальному рівні, тож ви можете бачити впевненість для конкретної таблиці, клітинки чи наміру.

00:06:29.760 --> 00:06:33.060
Ви навіть можете використовувати PAVAFX для створення динамічних порогових значень.

00:06:33.200 --> 00:06:37.080
Можливо, для звіту про витрати на 50 доларів рівня впевненості 0,70 достатньо.

00:06:37.080 --> 00:06:40.760
Але для замовлення на 50 тисяч доларів вам потрібно 0,98.

00:06:41.260 --> 00:06:44.360
Ви нарешті узгоджуєте свою технічну логіку з бізнес-ризиками.

00:06:44.520 --> 00:06:48.200
Ми звикли вважати, що кожна точка даних має однакову вагу, але це не так.

00:06:48.360 --> 00:06:54.140
Імовірнісний підхід дозволяє ставитися до важливих рішень інакше, ніж до дрібних, навіть у межах одного процесу.

00:06:54.260 --> 00:07:00.880
Ви більше не будуєте систему для ідеального світу, ви будуєте її для світу, де точно знаєте, який рівень невизначеності готові прийняти.

00:07:00.880 --> 00:07:05.080
А як тільки опануєте ці показники, зможете перейти до логіки, що долає прогалини.

00:07:05.220 --> 00:07:07.160
Нечіткий пошук і семантична логіка.

00:07:07.360 --> 00:07:11.360
Але як нам насправді обробляти дані, що потрапляють у цю сіру зону невизначеності?

00:07:11.500 --> 00:07:14.200
Почнемо з визнання того, що точне співставлення не працює.

00:07:14.360 --> 00:07:16.300
Воно не працює, бо йому бракує контексту.

00:07:16.420 --> 00:07:19.960
У старій моделі, якщо в назві постачальника не вистачало однієї крапки, пошук не вдавався.

00:07:20.100 --> 00:07:23.400
Пошуку байдуже до ваших намірів, йому важливі лише ASCI-значення.

00:07:23.400 --> 00:07:25.920
Ось тут і з'являється нечіткий пошук в фазі Мечін.

00:07:26.040 --> 00:07:30.600
Це метод, який знаходить і пов'язує неідентичні записи шляхом розрахунку показника схожості,

00:07:30.720 --> 00:07:32.740
виступаючи містком між IBM і IBM.

00:07:32.940 --> 00:07:34.740
І цей вплив не є суто теоретичним.

00:07:34.920 --> 00:07:39.320
Дослідження показують, що впровадження нечіткого пошуку може підвищити показник збігів до 24%.

00:07:39.320 --> 00:07:43.880
Це 24% ваших даних, які раніше були б відхилені або відправлені людині для ручного виправлення.

00:07:44.020 --> 00:07:47.280
В умовах великих обсягів це означає тисячі годин з економленого часу.

00:07:47.280 --> 00:07:49.000
Але ви повинні розуміти механізми.

00:07:49.180 --> 00:07:50.920
Є два основні способи підійти до цього.

00:07:51.080 --> 00:07:52.540
По-перше, посимвольна логіка.

00:07:52.700 --> 00:07:54.500
Це часто називають відстанню Левенштина.

00:07:54.720 --> 00:07:57.620
Вона рахує кількість редагувань, необхідних для перетворення одного рядка в інший.

00:07:57.760 --> 00:07:59.700
Це ідеально підходить для друкарських помилок.

00:07:59.860 --> 00:08:02.180
Якщо хтось пише «менедж» замість «менеджмент»,

00:08:02.180 --> 00:08:04.180
система бачить відсутні літери «і» та «ей»,

00:08:04.180 --> 00:08:07.140
вона обчислює відстань і розуміє, що вони майже ідентичні.

00:08:07.280 --> 00:08:09.320
По-друге, у нас є семантична логіка.

00:08:09.320 --> 00:08:10.960
Тут починається найцікавіше.

00:08:11.240 --> 00:08:13.140
Семантичній логіці байдуже до написання.

00:08:13.360 --> 00:08:14.380
Їй важливий зміст.

00:08:14.520 --> 00:08:17.140
Якщо одна система каже «кастома», а інша «клаянт»,

00:08:17.140 --> 00:08:19.360
посимвольне порівняння щоразу видаватиме помилку.

00:08:19.540 --> 00:08:22.080
Однак семантична модель знає, що це одне й те саме.

00:08:22.200 --> 00:08:24.840
Це перехід від зіставлення символів до зіставлення понять.

00:08:25.020 --> 00:08:27.400
Коли ви поєднуєте оцінки впевненості з нечітким пошуком,

00:08:27.480 --> 00:08:30.780
ви створюєте систему, здатно орієнтуватися в складній реальності бізнес-даних.

00:08:30.780 --> 00:08:33.040
Ви більше не обмежені жорсткими правилами, що ламаються,

00:08:33.180 --> 00:08:35.040
як тільки людина припускає цедрукарської помилки.

00:08:35.180 --> 00:08:37.400
Ви будуєте систему, яка розуміє нюанси.

00:08:37.520 --> 00:08:41.160
І саме так ви переходите від простої автоматизації до справжнього цифрового інтелекту,

00:08:41.260 --> 00:08:43.400
створюючи робочі процеси, що самокоригуються.

00:08:43.580 --> 00:08:46.720
Навіть із найкращим нечітким пошуком у світі ми маємо визнати реальність,

00:08:46.840 --> 00:08:47.840
що і все ще галюцинує.

00:08:47.980 --> 00:08:50.240
Це просто спосіб роботи технології на даний момент.

00:08:50.420 --> 00:08:53.680
Поточні дані показують, що навіть у найдосконаліших моделей рівень галюцинації

00:08:53.680 --> 00:08:55.680
становить від 15 до 20%.

00:08:55.680 --> 00:08:57.460
Якщо ви створюєте системи для бізнесу,

00:08:57.520 --> 00:08:59.460
ви не можете ігнорувати рівень відмов 1 до 5,

00:08:59.620 --> 00:09:02.460
і ви точно не можете просто промп-інженірингом вирішити цю проблему.

00:09:02.620 --> 00:09:06.020
Ви повинні прийняти той факт, що досягнення нульового рівня галюцинацій –

00:09:06.020 --> 00:09:06.860
це не магічний трюк.

00:09:06.940 --> 00:09:08.580
Це свідомий архітектурний вибір.

00:09:08.740 --> 00:09:10.620
Саме тут ми виходимо за межі простої автоматизації

00:09:10.620 --> 00:09:13.260
та починаємо створювати стійкі робочі процеси, що самокоригуються.

00:09:13.260 --> 00:09:16.960
Ми робимо це за допомогою структури, яку я називаю шаблоном двошляхової перевірки.

00:09:17.120 --> 00:09:21.080
Він діє як запобіжник, що заважає творчій уявіщі зіпсувати ваші реальні дані.

00:09:21.240 --> 00:09:23.980
Існує одне фундаментальне правило для сучасного архітектора.

00:09:24.140 --> 00:09:26.940
Ніколи не дозволяйте великій мовній моделі займатися математикою.

00:09:27.100 --> 00:09:29.340
LLM – це механізми для гнучкого мислення,

00:09:29.440 --> 00:09:34.060
тому вони чудово розуміють наміри або знаходять конкретну деталь у купі безладного тексту.

00:09:34.180 --> 00:09:37.600
Однак вони статистично ненадійні, коли йдеться про базову арифметику.

00:09:37.600 --> 00:09:41.880
Якщо ви попросите ще витягнути три позиції з рахунку фактури та підрахувати загальну суму,

00:09:41.980 --> 00:09:43.660
ви фактично прирікаєте систему на збій.

00:09:43.800 --> 00:09:47.420
У дизайні, що самокоригується, ви використовуєте LLM для гнучкого мислення,

00:09:47.520 --> 00:09:49.800
наприклад, для вилучення даних із хаотичного PDF.

00:09:50.000 --> 00:09:54.380
Отримавши ці цифри, ви передаєте їх у детерміновану систему для вирішення жорстких обмежень.

00:09:54.540 --> 00:09:59.140
Ваш потік Power Automate або базовий механізм правил мають бути тими інструментами, що виконують додавання.

00:09:59.140 --> 00:10:02.420
Саме вони мають перевіряти податки або верифікувати конвертацію валют.

00:10:02.600 --> 00:10:05.240
Якщо LLM стверджує, що загальна сума становить 500 доларів США,

00:10:05.340 --> 00:10:09.460
а ваша математика показує 480 доларів США, система виявила галюцинацію в реальному часі.

00:10:09.600 --> 00:10:12.540
Замість того, щоб зупинитися, система запускає шлях відновлення.

00:10:12.700 --> 00:10:16.380
Вона може спробувати інший промп або позначити помилку для перевірки людиною.

00:10:16.520 --> 00:10:20.580
У цьому різниця між потоком, що ламається, і потоком, який фактично відновлюється сам.

00:10:20.740 --> 00:10:24.020
Ми бачимо такий самий сув у сфері роботизованої автоматизації процесів.

00:10:24.020 --> 00:10:27.700
Традиційна RPA дуже крихка, оскільки залежить від точних координат на екрані.

00:10:27.800 --> 00:10:31.300
Якщо кнопка зміщується всього на три пікселі ліворуч, увесь бот виходить із ладу.

00:10:31.420 --> 00:10:34.900
RPA з функцією самовідновлення змінює це за допомогою імовірнісного зору.

00:10:35.060 --> 00:10:37.580
Бот більше не шукає конкретні координати пікселів.

00:10:37.720 --> 00:10:41.360
Натомість він шукає кнопку, схожу на іконку збереження у верхній частині сторінки.

00:10:41.520 --> 00:10:45.340
Коли інтерфейс змінюється, бот використовує контекст, щоб адаптуватися на льоту.

00:10:45.340 --> 00:10:49.380
Він розпізнає нову розкладку, оновлює власну логіку і завершує завдання.

00:10:49.560 --> 00:10:53.660
Це створює стійкий цикл, де система бачить потенційний збій і знаходить рішення,

00:10:53.780 --> 00:10:56.400
перш ніж користувач зрозуміє, що виникла проблема.

00:10:56.620 --> 00:11:00.340
Цей підхід зміщує наш фокус з показників успіху на показники відновлення.

00:11:00.480 --> 00:11:03.700
Ми припиняємо намагатися зробити щі ідеальним, що все одно неможливо,

00:11:03.800 --> 00:11:05.660
і починаємо робити систему непохитною.

00:11:05.820 --> 00:11:09.200
Йдеться про впровадження рівня контролю та балансу в кожну транзакцію.

00:11:09.200 --> 00:11:12.760
Вам варто ставитися до щі як до швидкого, але легковажного стажера.

00:11:12.920 --> 00:11:16.000
Ви дозволяєте йому виконувати важку роботу з читання тисяч листів,

00:11:16.100 --> 00:11:19.340
але ніколи не даєте підписувати чеки без перевірки старшим аудитором.

00:11:19.480 --> 00:11:22.600
У цьому випадку ваш детермінований код і є тим самим аудитором.

00:11:22.940 --> 00:11:25.680
Відокремлюючи мислення від обчислень, ви будуєте систему,

00:11:25.820 --> 00:11:30.040
яка справляється з хаосом людської мови, зберігаючи точність швейцарського годинника.

00:11:30.300 --> 00:11:33.780
Саме так ви виводите шість фази тестування в основу свого бізнесу.

00:11:33.780 --> 00:11:37.460
Ви довіряєте не моделі, а архітектурі, яку ви навколо неї збудували.

00:11:37.620 --> 00:11:39.840
Ви створюєте настільки надійний захисний механізм,

00:11:39.960 --> 00:11:42.380
що випадкові помилки моделі навіть не вважаються збоями.

00:11:42.540 --> 00:11:45.620
Це стає лише ще однією частиною циклу самокорекції.

00:11:45.780 --> 00:11:52.820
Це чудово звучить у лабораторії, але у виробництві головною перешкодою є нещі, а реальність у часті людини.

00:11:53.320 --> 00:11:58.420
Це чудово звучить у лабораторії, але у виробництві головною перешкодою є нещі, а людина.

00:11:58.420 --> 00:12:03.220
Ми зазвичай говоримо про автоматизацію як про простий вибір між людиною та машиною,

00:12:03.300 --> 00:12:06.620
але ймовірнісний підхід змушує нас шукати складні компроміси.

00:12:06.760 --> 00:12:09.580
Галузеві показники демонструють досить тверезу істину.

00:12:09.780 --> 00:12:14.380
Близько 50% робочих процесів ще все ще потребують перевірки експертом перед завершенням.

00:12:14.500 --> 00:12:17.340
Це головна причина кризи переходу від пілотного проєкту до виробництва.

00:12:17.500 --> 00:12:21.020
Якщо подивитися на цифри, 88% пілотних проєктів ще зазнають невдачі протягом року.

00:12:21.160 --> 00:12:23.440
Вони зазнають невдачі не тому, що технологія несправна.

00:12:23.440 --> 00:12:28.100
Вони провалюються, тому що їхні розробники намагаються автоматизувати 100% завдання занадто швидко.

00:12:28.240 --> 00:12:33.780
Вони створили систему, що працює на чистих тестових даних, але логіка ламається, як тільки стикається з реальністю відділу.

00:12:33.880 --> 00:12:37.060
Коли ви ігноруєте людський фактор, ви створюєте тягар перевірок.

00:12:37.220 --> 00:12:41.840
Якщо вас ще економить 10 хвилин на введенні даних, але додає 50 хвилин на перевірку роботи через те,

00:12:41.960 --> 00:12:44.800
що команда йому не довіряє, ви фактично втрачаєте продуктивність.

00:12:44.920 --> 00:12:46.780
Ви створили тягар замість активу.

00:12:46.780 --> 00:12:51.500
Успішні проєкти 2026 року розглядатимуть роботу з верифікації як ключову функцію.

00:12:51.640 --> 00:12:54.280
Вони не вважають перевірку людиною провалом системи.

00:12:54.400 --> 00:12:57.220
Натомість вони бачать у цьому необхідну частину архітектури.

00:12:57.380 --> 00:13:01.000
Вони закладають вартість цієї перевірки в окупність інвестицій з першого дня.

00:13:01.240 --> 00:13:04.000
Секрет успіху тут – у багаторівневій логіці перевірки.

00:13:04.180 --> 00:13:06.600
Ось як можна масштабувати процеси і не збожеволіти.

00:13:06.780 --> 00:13:09.500
Транзакції з високим рівнем впевненості проходять непомітно.

00:13:09.500 --> 00:13:13.900
Якщо модель впевнена на 98% і розрахунки вірні, система просто працює далі.

00:13:14.020 --> 00:13:18.180
Але випадки з низькою впевненістю, як та жовта зона, про яку ми говорили, спричинять ескалацію.

00:13:18.320 --> 00:13:20.040
Це повністю змінює роль людини.

00:13:20.200 --> 00:13:22.720
Ми відходимо від введення даних до аудиту даних.

00:13:22.840 --> 00:13:26.500
У старій моделі людина була двигуном, бо виконувала всю роботу з друку та клікання.

00:13:26.680 --> 00:13:28.740
У новій моделі людина стає регулятором.

00:13:28.940 --> 00:13:33.120
Вона обробляє винятки і додає нюанси, які ймовірнісна модель не може повністю зрозуміти.

00:13:33.300 --> 00:13:35.140
Подумайте, як це впливає на команду.

00:13:35.140 --> 00:13:40.340
Коли люди знають, що мають дивитися лише на ті 5% випадків, які дійсно складні, вони працюють набагато залученіше.

00:13:40.500 --> 00:13:42.060
Рутина їх більше не втомлює.

00:13:42.240 --> 00:13:44.440
Їх захоплює складність непростих завдань.

00:13:44.620 --> 00:13:47.140
Але для цього потрібно створити правильний інтерфейс.

00:13:47.280 --> 00:13:50.060
Не можна просто надіслати лист про те, що щось пішло не так.

00:13:50.200 --> 00:13:52.340
Потрібно показати порівняння пліч-о-пліч.

00:13:52.500 --> 00:13:54.400
Покажіть людині вихідний документ.

00:13:54.520 --> 00:13:58.280
Покажіть, що витягнув щі, і виділіть поле, де рівень впевненості впав.

00:13:58.280 --> 00:14:03.240
Якщо ви хочете маштабуватися, ви повинні припинити думати, що перевірка людиною означає слабкість вашої автоматизації.

00:14:03.400 --> 00:14:04.560
Насправді, все навпаки.

00:14:04.800 --> 00:14:10.100
Добре інтегрована людина – це те, що робить ймовірнісну систему достатньо сильною для реального світу.

00:14:10.280 --> 00:14:13.220
Це фінальний рівень вашої архітектури самокорекції.

00:14:13.620 --> 00:14:14.700
Агентне майбутнє.

00:14:14.840 --> 00:14:18.200
Ми дивимося на новий горизонт під назвою «агентне підприємство».

00:14:18.200 --> 00:14:21.240
Це логічне завершення всього, що ми сьогодні обговорювали.

00:14:21.420 --> 00:14:25.340
Ми переходимо у світ, де агенти – це більше не просто прості скрипти чи базові потоки,

00:14:25.340 --> 00:14:27.800
бо вони стають повноцінними цифровими працівниками.

00:14:27.920 --> 00:14:30.400
Pava Platform змінюється прямо на наших очах.

00:14:30.580 --> 00:14:34.500
Вона перетворюється зі стандартного конструктора застосунків на повноцінний центр оркестрації.

00:14:34.680 --> 00:14:38.340
У старій моделі ви створювали конкретний застосунок для розв'язання конкретної проблеми.

00:14:38.420 --> 00:14:42.540
А в агентній моделі ви створюєте середовище, де агенти самі розв'язують ці проблеми за вас.

00:14:42.680 --> 00:14:45.320
Ці агенти не просто виконують статичний список кроків.

00:14:45.520 --> 00:14:48.780
Вони спостерігають за середовищем, оцінюють власний рівень впевненості та вирішують,

00:14:48.780 --> 00:14:50.920
який інструмент насправді краще використати далі.

00:14:51.040 --> 00:14:54.680
До 2026 року управління виглядатиме зовсім не так, як два роки тому.

00:14:54.860 --> 00:14:59.140
Такі інструменти, як Perview і Sentinel, переходять до імовірнісного виявлення аномалій.

00:14:59.300 --> 00:15:01.620
Вони більше не просто шукають витоки паролів.

00:15:01.800 --> 00:15:05.520
Натомість вони шукають паттерни поведінки, які просто виглядають підозріло.

00:15:05.680 --> 00:15:07.600
Вони застосовують ту саму логіку подібності,

00:15:07.660 --> 00:15:10.820
яку ми використовуємо для вилучення даних до безпеки всього вашого тенента.

00:15:11.000 --> 00:15:12.320
Цей сув є незворотним.

00:15:12.320 --> 00:15:17.220
Ті, хто тримається жорсткої логіки, якщо то, будуть змушені керувати зламаними системами та розчарованими командами.

00:15:17.380 --> 00:15:19.460
Вони застрягнуть у циклі постійного обслуговування,

00:15:19.580 --> 00:15:22.760
намагаючись полагодити скляний будинок, який не був розрахований на таку погоду,

00:15:22.900 --> 00:15:25.200
агентне підприємство починається з одного усвідомлення.

00:15:25.320 --> 00:15:28.700
Нам не потрібно контролювати кожну окрему змінну, щоб отримати надійний результат.

00:15:28.920 --> 00:15:31.040
Нам просто потрібно контролювати архітектуру.

00:15:31.200 --> 00:15:35.860
Наша робота – визначити пороги та встановити обмеження, щоб агенти могли працювати в цих межах.

00:15:35.860 --> 00:15:38.620
У цьому світі ваша бізнес-логіка стає еластичною.

00:15:38.780 --> 00:15:44.060
Вона адаптується до нового постачальника чи іншого формату документа без потреби переписувати жодного рядка коду.

00:15:44.240 --> 00:15:45.940
Це справжня перевага low-code.

00:15:46.100 --> 00:15:49.360
Це здатність рухатися зі швидкістю думки, а не зі швидкістю синтаксису.

00:15:49.480 --> 00:15:51.540
Але щоб дійти до цього, треба почати сьогодні.

00:15:51.660 --> 00:15:55.500
Припиніть будувати для ідеального світу і почніть будувати для того хаотичного світу, в якому ми живемо.

00:15:55.640 --> 00:15:57.120
Ви повинні прийняти сумніви.

00:15:57.280 --> 00:15:58.520
Завдання на впровадження.

00:15:58.700 --> 00:16:00.420
Ось ваше домашнє завдання на тиждень.

00:16:05.860 --> 00:16:12.020
Ви не можете контролювати те, що ваші користувачі чи постачальники вирішують вам надіслати.

00:16:12.180 --> 00:16:15.140
Замість боротьби з цією реальністю, додайте поріг впевненості.

00:16:15.300 --> 00:16:19.060
Зайдіть у свій AI-білда або дію LLM і виведіть цей показник ймовірності.

00:16:19.220 --> 00:16:20.480
Створіть просту умову.

00:16:20.640 --> 00:16:24.560
Якщо показник впевненості нижчий за 85%, не дозволяйте потоку зупинитися.

00:16:24.700 --> 00:16:28.360
Перенаправте цей випадок до папки перевірки або списку SharePoint для ручного контролю.

00:16:28.480 --> 00:16:30.660
Подивіться, що станеться з вашим рівнем успіху.

00:16:30.660 --> 00:16:35.180
Ви побачите, як напруга зникне з системи, щойно ви перестанете вдавати, що кожен вхідний сигнал буде ідеальним.

00:16:35.320 --> 00:16:38.800
Якщо цей сувумисленні змінив ваш підхід, підпишіться на мене, Мірко Пітерса, у LinkedIn.

00:16:39.100 --> 00:16:41.960
Я постійно ділюся глибокими аналізами цих архітектурних паттернів.

00:16:42.080 --> 00:16:45.220
Поділіться цим зі своєю командою, особливо якщо ваші потоки зараз дають збої.

00:16:45.360 --> 00:16:48.020
Нам потрібно припинити будувати зі скла і почати будувати з наміром.

00:16:48.180 --> 00:16:51.800
Це та сама техніка, і вона скорочує ваш час простою вдвічі, як тільки ви почнете її застосовувати.

00:16:51.800 --> 00:16:55.840
Якщо ви хочете дізнатися розширену версію, яку використовують професіонали, подивіться це відео далі.

00:16:56.120 --> 00:16:57.460
Підписуйтесь на нові туторіали.

00:16:57.620 --> 00:17:01.560
Припиніть боротися з хаотичною реальністю ваших даних і почніть проєктувати з урахуванням цього.

00:17:01.740 --> 00:17:06.480
Коли ви використовуєте показники впевненості, ви перетворюєте крихкі процеси на стійкі системи, які дійсно працюють.

00:17:06.600 --> 00:17:07.600
Але ось у чому річ.

00:17:07.780 --> 00:17:10.200
Модель працює лише тоді, коли ви будуєте її правильно.

00:17:10.200 --> 00:17:15.260
Якщо ви хочете побачити, як саме налаштувати це в Coopilot Studio, подивіться це наступне відео прямо зараз.

00:17:15.360 --> 00:17:20.180
І якщо це змінило ваш погляд на щі, підписуйтесь на мене в LinkedIn або на розсилку Master the New Model.