WEBVTT

00:00:00.040 --> 00:00:03.980
Ваши лоу-код автоматизации ломаются, потому что они слишком умны для своего же блага.

00:00:04.100 --> 00:00:07.980
Жесткая логика, если-то это приговор, когда вы сталкиваетесь с хаосом реальных данных,

00:00:08.140 --> 00:00:12.760
ежедневно обрушивающим ваши системы. Допущение, что данные чисты, это первородный грех лоу-код

00:00:12.760 --> 00:00:16.820
проектирования. Мы построили весь наш мир на модели, если-то, но для ее работы требуется

00:00:16.820 --> 00:00:21.420
абсолютная определенность. Данные в реальном мире неопределены. В них есть опечатки. В них не

00:00:21.420 --> 00:00:25.780
хватает контекста. Это хаотичный поток человеческих ошибок. Когда детерминированная система

00:00:25.780 --> 00:00:29.820
сталкивается с отклонением в 1%, она не гнется и уж точно не адаптируется. Она

00:00:29.820 --> 00:00:32.960
просто ломается. Это создает ловушку хрупкости, где ваша автоматизация

00:00:32.960 --> 00:00:36.760
сильна лишь настолько, насколько чиста ваша самая чистая точка данных. Для корпоративного сектора

00:00:36.760 --> 00:00:41.140
это слишком низкая планка успеха. Но проблема не в данных, а в модели, которую мы используем

00:00:41.140 --> 00:00:45.780
для их обработки. Смерть детерминизма. Детерминированная логика – это пережиток эпохи

00:00:45.780 --> 00:00:51.180
структурированных данных. Она работала, когда все жило в SQL-таблицах, и работала, когда мы заставляли

00:00:51.180 --> 00:00:56.680
людей втискиваться в заранее заданные рамки. Но этот мир ушел. Сегодня 80% корпоративных данных

00:00:56.680 --> 00:01:01.500
не структурированы. Они содержатся в письмах, чатах и записях голоса. Традиционные потоки

00:01:01.500 --> 00:01:07.700
Power Automate воспринимают яблоки и четыре яблока, как две разные вселенные. Для бинарной системы

00:01:07.700 --> 00:01:12.840
это совершенно не связанные строки. Мы достигли точки перелома, когда затраты на ручную очистку

00:01:12.840 --> 00:01:17.140
данных превышают ценность самой автоматизации. Если вам нужно тратить два часа на исправление

00:01:17.140 --> 00:01:21.860
CSV-файла, чтобы поток отработал пять секунд, вы ничего не автоматизировали. Вы просто переложили

00:01:21.860 --> 00:01:26.540
трудозатраты. И это не просто блестящая новая функция, которую мы приклеили к Power Platform.

00:01:26.740 --> 00:01:31.540
Это фундаментальный переход от точного совпадения к сходству. Старая модель спрашивает,

00:01:31.540 --> 00:01:36.200
это А. Новая модель спрашивает, насколько это похоже на А. Подумайте о том, как вы ориентируетесь

00:01:36.200 --> 00:01:40.440
в своем почтовом ящике. Вы не запускаете в уме регулярные выражения, чтобы найти счет. Вы ищите

00:01:40.440 --> 00:01:46.120
паттерны. Вы ищите контекст. Вы понимаете, что INV-202 и счет номер 202 – это одно и то же,

00:01:46.280 --> 00:01:51.280
даже если символы не совпадают. Детерминированные системы так не умеют. Они слепы к намерениям. Они

00:01:51.280 --> 00:01:56.240
видят только синтаксис. И по мере приближения к 2026 году синтаксис становится менее важным,

00:01:56.360 --> 00:02:00.920
чем семантика. Мы наблюдаем колоссальный взрыв объемов данных от IoT-датчиков, потоков в реальном

00:02:00.920 --> 00:02:05.760
времени и сводок, созданных LLM. Если попытаться управлять этим объемом с помощью жестко закодированных

00:02:05.760 --> 00:02:10.060
ветвлений, если-то ваша логика превратится в лабиринт. В итоге вы получите потоки с 50-10

00:02:10.060 --> 00:02:14.060
вложенными условиями, которые все равно сломаются, как только поставщик изменит свою подпись в письме.

00:02:14.240 --> 00:02:18.780
Модель, если-то, предполагает идеальный мир, где входные данные всегда соответствуют схеме.

00:02:18.780 --> 00:02:24.180
Но в реальности все наоборот. Данные – это переменная. Логика должна быть константой. Но наша

00:02:24.180 --> 00:02:28.680
логика оказалась слишком жесткой для столкновения с реальностью. Мы строили стеклянные дома в мире,

00:02:28.920 --> 00:02:33.820
где постоянно идет град. А потом удивляемся, почему полусыпана сколками. Переход к вероятностному

00:02:33.820 --> 00:02:39.360
проектированию – это строительство из резины, а не из стекла. Это создание систем, которые поглощают

00:02:39.360 --> 00:02:44.820
последствия опечаток, не разрушаясь. Мы уходим от идеи, что система должна быть на 100% правой

00:02:44.820 --> 00:02:50.380
или на 100% неправой. Ведь в реальном мире ничего не бывает на 100%. Мы десятилетиями лгали себя

00:02:50.380 --> 00:02:54.540
о качестве наших данных. Мы создавали стерильные условия для нашей логики, а потом делали вид,

00:02:54.680 --> 00:02:59.740
что удивлены, когда грязные данные от отдела продаж приводили к краху всей системы. Крах детерминизма – это

00:02:59.740 --> 00:03:04.080
крах этой лжи. Это признание того, что мы не можем контролировать входные данные, поэтому должны

00:03:04.080 --> 00:03:08.940
модернизировать обработку. Мы вступаем в эру приближенных вычислений, где принимаем, что достаточно

00:03:08.940 --> 00:03:14.820
близко, лучше, чем абсолютно неверно. Потому что система, способная обработать 90% совпадения,

00:03:15.000 --> 00:03:20.460
бесконечно ценнее системы, которая отвергает все, кроме 100% совпадения. Это не просто техническое

00:03:20.460 --> 00:03:25.400
изменение, это психологический сдвиг. Вы должны привыкнуть к мысли, что ваша система может быть

00:03:25.400 --> 00:03:30.500
лишь довольно уверена в данных. Нужно учиться проектировать с учетом сомнений, ведь сомнение – единственный

00:03:30.500 --> 00:03:34.720
честный способ работы с неструктурированной информацией. Этот сдвиг требует перехода от бинарных

00:03:34.720 --> 00:03:39.220
триггеров к чему-то более тонкому – показателю уверенности архитектуре неопределенности.

00:03:39.360 --> 00:03:43.900
Если мы признаем, что эра бинарной логики прошла, мы должны заменить ее новой структурой.

00:03:44.040 --> 00:03:48.760
Я называю это моделью симфонического оркестра. В традиционной ИТ-архитектуре каждый – солист,

00:03:48.900 --> 00:03:53.240
играющий по жесткой партитуре, и если один пропускает ноту, все выступление останавливается.

00:03:53.420 --> 00:03:57.520
Но в вероятностной архитектуре у нас есть детерминированные дирижеры, управляющие вероятностными

00:03:57.520 --> 00:04:03.120
музыкантами. Дирижер – это ваш поток Power Automate. Он задает структуру, темп и определяет границы.

00:04:03.120 --> 00:04:09.080
Музыканты – это модели И. Они талантливы, но экспрессивны и не всегда попадают в одну и ту же

00:04:09.080 --> 00:04:14.980
частоту при каждом исполнении. Задача дирижера – не заставлять музыкантов быть роботами. Задача – слушать

00:04:14.980 --> 00:04:19.680
их и решать, достаточно ли хороших звук, чтобы продолжать. Это подводит нас к главному столпу

00:04:19.680 --> 00:04:23.880
современного дизайна – показателю уверенности. Показатель уверенности – это значение от нуля до

00:04:23.880 --> 00:04:28.900
единицы, которое количественно выражает сомнения. Это способ модели сказать «Я думаю, что это совпадение,

00:04:29.100 --> 00:04:33.020
и вот сколько я готова поставить на это». В старом мире у нас были жестко заданные пути.

00:04:33.120 --> 00:04:37.440
Если в теме письма есть слово «счет» – «сохранить вложение», в новом мире мы используем

00:04:37.440 --> 00:04:42.160
маршрутизацию на основе уверенности. Мы делаем внутренние сомнения моделей, видимыми для системы.

00:04:42.280 --> 00:04:46.780
Мы больше не считаем и черным ящиком, а воспринимаем его как свидетеля с определенным

00:04:46.780 --> 00:04:50.840
уровнем достоверности. Вот как реализовать это в Power Platform. При использовании

00:04:50.840 --> 00:04:55.560
iBuilder или Azure AI вы получаете не только извлеченные данные. Вы получаете слой метадомных,

00:04:55.700 --> 00:04:59.760
который раскрывает вероятность для каждого отдельного поля. Если модель извлекает общую сумму в

00:04:59.760 --> 00:05:05.460
$1500, она также сообщает, что уверена в этом числе на 95%. Как архитектор, теперь вы имеете

00:05:05.460 --> 00:05:11.760
три четкие зоны действий. Первая – зеленая зона. Уверенность 0,90 или выше. Риск ошибки низок,

00:05:12.000 --> 00:05:16.040
цена ошибки управляема, и в итоге вы автоматизируете процесс. Система продолжает

00:05:16.040 --> 00:05:22.100
работу без вмешательства человека. Вторая – желтая зона. Уверенность от 0,60 до 0,89.

00:05:22.640 --> 00:05:27.180
Модель довольно уверена, но не до конца. Возможно, документ был слегка размыт или почерк был

00:05:27.180 --> 00:05:31.660
неразборчивым. В этой зоне вы ставите пометку. Система направляет данные человеку-оператору

00:05:31.660 --> 00:05:37.460
для быстрой проверки. Третья – красная зона. Уверенность ниже 0,60. Модель просто гадает. В этой

00:05:37.460 --> 00:05:41.340
зоне вы отклоняете данные или отправляете их на эскалацию. Вы не допускаете эти данные в свою

00:05:41.340 --> 00:05:45.440
рабочую базу данных. Это прозрачный уровень управления рисками. Он позволяет масштабировать

00:05:45.440 --> 00:05:49.780
автоматизацию, сохраняя при этом предохранительный клапан. Подумайте о последствиях для управления.

00:05:49.960 --> 00:05:54.500
В детерминированной системе ошибки незаметны. Поток выполняется, выбирает неверное число из-за

00:05:54.500 --> 00:05:58.800
опечатки и записывает его в вашу ERP-систему. Вы узнаете об этом только в конце квартала.

00:05:58.960 --> 00:06:02.760
В вероятностной системе ошибка имеет сигнатуру. Система знает, что испытывает трудности,

00:06:02.880 --> 00:06:07.040
и говорит вам, я обработала это, но мой уровень уверенности составил лишь 62%. Это невероятно

00:06:07.040 --> 00:06:10.900
мощный сигнал. Он позволяет вам создать панель мониторинга сомнений. Вы можете точно увидеть,

00:06:11.120 --> 00:06:15.080
где ваши модели дают сбой. Вы видите, какие поставщики присылают документы, которые и не может

00:06:15.080 --> 00:06:19.260
распознать, и какие этапы процесса постоянно попадают в желтую зону. Вы не просто строите поток,

00:06:19.460 --> 00:06:24.200
вы создаете интеллектуальный цикл. И именно здесь Azure AI и iBuilder показывают себя во всей красе.

00:06:24.200 --> 00:06:28.100
Они предоставляют эти оценки на детальном уровне, позволяя увидеть уверенность для конкретной

00:06:28.100 --> 00:06:32.240
таблицы, ячейки или намерения. Вы даже можете использовать PowerFX для создания динамических

00:06:32.240 --> 00:06:36.300
пороговых значений. Возможно, для отчета о расходах на 50 долларов уровня уверенности 0,70

00:06:36.300 --> 00:06:41.420
достаточно. Но для заказа на покупку стоимостью 50 тысяч долларов вам нужно значение 0,98. Вы

00:06:41.420 --> 00:06:45.120
наконец-то приводите техническую логику в соответствии с бизнес-рисками. Мы привыкли

00:06:45.120 --> 00:06:49.660
относиться к каждой точке данных как к равнозначной, но это не так. Вероятностное проектирование

00:06:49.660 --> 00:06:53.680
позволяет по-разному обрабатывать важные и второстепенные решения в рамках одного

00:06:53.680 --> 00:06:58.380
процесса. Вы больше не строите систему для идеального мира, а для мира, где вы точно знаете,

00:06:58.580 --> 00:07:02.920
какой уровень неопределенности готовы допустить. И как только вы освоите оценку, вы сможете

00:07:02.920 --> 00:07:07.340
заняться логикой, которая заполняет пробелы. Нечеткое сопоставление и семантическая логика.

00:07:07.500 --> 00:07:11.340
Но как на самом деле обрабатывать данные, которые попадают в эту зону неопределенности?

00:07:11.340 --> 00:07:14.900
Мы начнем с признания того, что точное сопоставление не работает. Оно не работает,

00:07:15.100 --> 00:07:19.120
потому что ему не хватает контекста. В старой модели, если в названии поставщика не хватало одной точки,

00:07:19.120 --> 00:07:23.560
поиск давал сбой. Поиску нет дела до вашего намерения, он заботится только об ESCI и i-кодах.

00:07:23.720 --> 00:07:28.440
Здесь на помощь приходит нечеткое сопоставление. Это метод, который находит и связывает неодинаковые

00:07:28.440 --> 00:07:33.300
записи путем расчета показателя сходства, выступая мостом между IBM и IBM, и эффект от этого

00:07:33.300 --> 00:07:37.200
отнюдь не теоретический. Исследования показывают, что внедрение нечеткого сопоставления может

00:07:37.200 --> 00:07:42.680
повысить точность совпадений на 24%. Это 24% ваших данных, которые раньше были бы отклонены или отправлены

00:07:42.680 --> 00:07:47.120
человеку для исправления вручную. В условиях большого объема работы это тысячи часов сэкономленного времени.

00:07:47.120 --> 00:07:51.120
Однако нужно понимать принципы работы. Существует два основных подхода к этому вопросу.

00:07:51.180 --> 00:07:55.280
Во-первых, посимвольная логика. Ее часто называют расстоянием Левенштейна. Она подсчитывает

00:07:55.280 --> 00:07:59.140
количество правок, необходимых для превращения одной строки в другую. Это идеально подходит для

00:07:59.140 --> 00:08:04.060
опечаток. Если кто-то пишет менедж вместо менеджмент, система видит недостающие е, и ей она

00:08:04.060 --> 00:08:09.680
вычисляет расстояние и понимает, что они почти идентичны. Во-вторых, семантическая логика. Вот где

00:08:09.680 --> 00:08:15.180
начинается самое интересное. Семантической логике нет дела до написания. Ей важно значение. Если одна система

00:08:15.180 --> 00:08:18.820
использует слово «костомер», а другая — клиент, посимвольное сопоставление будет каждый раз

00:08:18.820 --> 00:08:22.860
терпеть неудачу. Но семантическая модель понимает, что это одно и то же. Это переход от

00:08:22.860 --> 00:08:27.120
сопоставления символов к сопоставлению понятий. Объединяя показатели достоверности с нечетким

00:08:27.120 --> 00:08:31.440
поиском, вы создаете систему, способную работать с запутанными данными бизнеса. Вы больше не

00:08:31.440 --> 00:08:36.100
ограничены жесткими правилами, которые ломаются при любой опечатке пользователя. Вы создаете систему,

00:08:36.280 --> 00:08:40.460
которая понимает нюансы. Именно так происходит переход от простой автоматизации к подлинному

00:08:40.460 --> 00:08:44.460
цифровому интеллекту через самокорректирующиеся рабочие процессы. Даже при лучшем в мире

00:08:44.460 --> 00:08:49.040
нечетком поиске мы должны признать, что и все еще склонен к галлюцинациям. Такова специфика

00:08:49.040 --> 00:08:53.460
современных технологий. Текущие данные показывают, что даже у самых продвинутых моделей уровень

00:08:53.460 --> 00:08:58.800
галлюцинации составляет от 15 до 20%. Если вы создаете бизнес-системы, нельзя игнорировать

00:08:58.800 --> 00:09:04.260
уровень ошибок 1 к 5, и здесь точно не помогут одни лишь подсказки. Нужно принять, что достижение

00:09:04.260 --> 00:09:09.340
нулевого уровня галлюцинаций — это не фокус. Это осознанный архитектурный выбор. Здесь мы выходим

00:09:09.340 --> 00:09:13.260
за рамки простой автоматизации и начинаем строить устойчивые самокорректирующиеся процессы.

00:09:13.360 --> 00:09:17.220
Мы делаем это с помощью структуры, которую я называю шаблоном двухконтурной проверки. Она

00:09:17.220 --> 00:09:21.180
служит защитой, не дающей творческой фантазии и испортить ваши реальные данные.

00:09:21.360 --> 00:09:25.000
Для современного архитектора есть одно фундаментальное правило. Никогда не позволяйте

00:09:25.000 --> 00:09:29.380
большой языковой модели заниматься математикой. ЛЛМ — это движки для мягких рассуждений,

00:09:29.520 --> 00:09:33.880
поэтому они отлично понимают намерения или находят детали в неструктурированном тексте.

00:09:33.880 --> 00:09:37.860
Однако они статистически ненадежны, когда дело доходит до базовой арифметики.

00:09:37.860 --> 00:09:41.640
Если вы просите и извлечь три позиции из счета и рассчитать итоговую сумму,

00:09:41.740 --> 00:09:45.800
вы фактически провоцируете сбой системы. В самокорректирующемся дизайне вы используете

00:09:45.800 --> 00:09:50.860
ЛЛМ для мягких рассуждений, например, для извлечения данных из нечеткого PDF. Получив эти числа,

00:09:51.000 --> 00:09:54.720
вы передаете их в детерминированную систему для работы с жесткими ограничениями.

00:09:54.880 --> 00:09:59.840
Ваш поток Power Automate или базовый движок правил должен заниматься сложением. Именно он должен

00:09:59.840 --> 00:10:04.720
проверять налоги или подтверждать конвертацию валют. Если ЛЛМ утверждает, что итог 500 долларов США,

00:10:04.720 --> 00:10:09.200
а ваши вычисления показывают 480 долларов США, система обнаруживает галлюцинацию в реальном

00:10:09.200 --> 00:10:13.080
времени. Вместо того, чтобы упасть, система активирует путь восстановления. Она может

00:10:13.080 --> 00:10:17.900
попробовать другой запрос или пометить ошибку для проверки человеком. В этом разница между потоком,

00:10:18.000 --> 00:10:22.880
который ломается, и тем, что способен исцелить себя сам. Мы видим такие же изменения в роботизированной

00:10:22.880 --> 00:10:27.720
автоматизации процессов. Традиционная RPA очень хрупка, так как зависит от точных координат на экране.

00:10:27.860 --> 00:10:31.280
Если кнопка сместится всего на три пикселя влево, весь бот перестанет работать.

00:10:31.280 --> 00:10:35.940
Самовосстанавливающаяся RPA меняет это, используя вероятностное зрение. Бот больше не ищет

00:10:35.940 --> 00:10:40.440
конкретные пиксельные координаты. Вместо этого он ищет кнопку, похожую на значок сохранения в

00:10:40.440 --> 00:10:45.100
верхней части страницы. Когда интерфейс меняется, бот использует контекст, чтобы адаптироваться на

00:10:45.100 --> 00:10:50.600
лету. Он распознает новую разметку, обновляет свою логику и завершает задачу. Это создает устойчивый

00:10:50.600 --> 00:10:55.400
цикл, в котором система видит потенциальный сбой и находит решение, прежде чем пользователь поймет,

00:10:55.640 --> 00:10:59.800
что возникла проблема. Такой подход смещает наш фокус с показателей успеха на показатели

00:10:59.800 --> 00:11:03.720
восстановления. Мы перестаем пытаться сделать и идеальным, что все равно невозможно,

00:11:03.920 --> 00:11:08.240
и начинаем делать систему незыблемой. Речь идет о внедрении уровня контроля и баланса в каждую

00:11:08.240 --> 00:11:12.920
отдельную транзакцию. Вам следует относиться к и как к быстрому, но легко отвлекающемуся стажеру.

00:11:13.080 --> 00:11:17.640
Вы поручаете ему тяжелую работу по чтению тысяч писем, но никогда не позволяете подписывать чеки

00:11:17.640 --> 00:11:22.520
без проверки подписи старшим аудиторам. В данном случае ваш детерминированный код и есть этот аудитор.

00:11:22.680 --> 00:11:27.640
Разделяя мышление и вычисления, вы строите систему, которая справляется с хаосом человеческого

00:11:27.640 --> 00:11:31.980
языка, сохраняя точность швейцарских часов. Вот как можно перевести и из стадии

00:11:31.980 --> 00:11:35.980
тестирования в основу вашего бизнеса. Вы доверяете не модели, а архитектуре,

00:11:36.120 --> 00:11:40.100
которую вы выстроили вокруг нее. Вы создаете настолько прочную систему безопасности,

00:11:40.340 --> 00:11:44.560
что редкие ошибки модели даже не считаются с боями. Они становятся просто частью цикла

00:11:44.560 --> 00:11:50.660
самокоррекции. Это отлично звучит в лаборатории, но в реальности, при внедрении, главное препятствие,

00:11:50.920 --> 00:11:55.820
не и, а необходимость участия человека. Это отлично звучит в лаборатории, но в реальности,

00:11:55.820 --> 00:12:00.740
при внедрении, главное препятствие, не и, а человек. Обычно мы говорим об автоматизации,

00:12:00.840 --> 00:12:05.400
как о простом выборе между человеком и машиной, но вероятностная природа заставляет нас искать

00:12:05.400 --> 00:12:09.740
сложные компромиссы. Отраслевые показатели демонстрируют довольно отрезвляющую правду.

00:12:09.920 --> 00:12:14.940
Около 50% рабочих процессов и все еще требуют проверки экспертам перед их завершением. Это главная

00:12:14.940 --> 00:12:18.340
причина кризиса перехода от пилотных проектов к производственным. Если взглянуть на цифры,

00:12:18.480 --> 00:12:22.200
88% пилотных проектов и проваливаются в течение года. Они проваливаются не потому,

00:12:22.200 --> 00:12:25.860
что технологии неисправны. Они проваливаются, потому что их разработчики пытаются

00:12:25.860 --> 00:12:30.120
автоматизировать 100% задачи слишком рано. Они создают систему, которая работает на чистых

00:12:30.120 --> 00:12:33.800
тестовых данных, но логика рушится, как только сталкивается с реальностью рабочего отдела.

00:12:33.920 --> 00:12:38.900
Игнорируя человеческий фактор, вы создаете непосильное бремя проверок. Если ваш и экономит 10 минут

00:12:38.900 --> 00:12:42.940
на вводе данных, но добавляет 50 минут на их проверку, потому что команда ему не доверяет,

00:12:43.120 --> 00:12:47.700
вы на самом деле теряете в продуктивности. Вы создали абузу, а не актив. Успешные проекты

00:12:47.700 --> 00:12:52.980
2026 года будут рассматривать верификацию как ключевую функцию. В них проверка человеком не

00:12:52.980 --> 00:12:57.320
считается сбоем системы. Напротив, она воспринимается как необходимая часть архитектуры.

00:12:57.500 --> 00:13:01.060
Стоимость такой проверки закладывается в окупаемость инвестиций с первого же дня.

00:13:01.280 --> 00:13:05.480
Секрет успеха здесь – в многоуровневой логике проверки. Именно так можно масштабировать

00:13:05.480 --> 00:13:10.380
процессы, не сходя с ума. Транзакции с высокой уверенностью проходят незаметно. Если модель уверена

00:13:10.380 --> 00:13:15.400
на 98% и расчеты верны, система просто продолжает работу. Но случай с низкой уверенностью,

00:13:15.400 --> 00:13:19.700
как та желтая зона, о которой мы говорили, вызовут эскалацию. Это полностью меняет роль

00:13:19.700 --> 00:13:24.580
человека. Мы уходим от ввода данных к их аудиту. В старой модели человек был двигателем,

00:13:24.800 --> 00:13:29.340
так как выполнял всю ручную работу. В новой модели человек – это контролер. Он обрабатывает

00:13:29.340 --> 00:13:33.220
исключения и добавляет те нюансы, которые вероятностная модель не всегда понимает.

00:13:33.300 --> 00:13:37.800
Подумайте, как это ощущается для команды. Когда люди знают, что им нужно заниматься только 5%

00:13:37.800 --> 00:13:42.000
действительно сложных случаев, они работают с большим интересом. Их больше не утомляет рутина.

00:13:42.000 --> 00:13:46.700
Их привлекает сложность нестандартных задач. Но чтобы это работало, нужно создать правильный

00:13:46.700 --> 00:13:51.080
интерфейс. Нельзя просто отправить письмо о том, что что-то пошло не так. Нужно показать данные

00:13:51.080 --> 00:13:55.600
для сравнения, бок о бок. Покажите человеку исходный документ. Покажите, что извлек И,

00:13:55.780 --> 00:13:59.920
и подсветите поле, где уровень уверенности оказался низким. Если вы хотите масштабироваться,

00:14:00.100 --> 00:14:03.100
перестаньте считать, что проверка человеком – признак слабости автоматизации.

00:14:03.260 --> 00:14:08.080
На самом деле, все наоборот. Грамотное вовлечение человека делает вероятностную систему

00:14:08.080 --> 00:14:12.900
достаточно надежной для реального мира. Это завершающий уровень вашей самокорректирующейся

00:14:12.900 --> 00:14:18.220
архитектуры. Будущее агентов. Мы смотрим на новый горизонт, называемый агентным предприятием.

00:14:18.360 --> 00:14:23.740
Это логический финал всего, что мы обсуждали сегодня. Мы входим в мир, где агенты – это уже не

00:14:23.740 --> 00:14:27.780
просто скрипты или базовые цепочки, а полноценные цифровые сотрудники.

00:14:27.920 --> 00:14:32.420
Power Platform меняется прямо у нас на глазах. Она превращается из обычного конструктора

00:14:32.420 --> 00:14:36.880
приложений в полноценный центр оркестрации. В старой модели вы создавали конкретное приложение

00:14:36.880 --> 00:14:41.680
для решения конкретной задачи. Но в агентной модели вы создаете среду, где агенты сами решают

00:14:41.680 --> 00:14:46.280
эти задачи за вас. Эти агенты не просто следуют статичному списку шагов. Они наблюдают за своей

00:14:46.280 --> 00:14:50.160
средой, оценивают собственный уровень уверенности и решают, какой инструмент действительно лучше

00:14:50.160 --> 00:14:54.740
использовать дальше. К 2026 году управление будет выглядеть совсем не так, как два года назад.

00:14:54.920 --> 00:14:59.320
Такие инструменты, как Perview и Sentinel, переходят к вероятностному обнаружению аномалий.

00:14:59.440 --> 00:15:03.780
Они больше не ищут просто слитые пароли. Вместо этого они ищут модели поведения,

00:15:03.780 --> 00:15:08.380
которые выглядят подозрительно. Они применяют ту же логику сходства, которую мы используем при

00:15:08.380 --> 00:15:12.580
извлечении данных к безопасности всего вашего клиента. Этот сдвиг необратим. Люди,

00:15:12.720 --> 00:15:16.340
придерживающиеся жесткой логики, если-то останутся управлять сломанными системами с

00:15:16.340 --> 00:15:20.700
разочарованными командами. Они застрянут в цикле постоянного обслуживания, пытаясь латать стеклянный

00:15:20.700 --> 00:15:25.180
дом, который не был рассчитан на такую погоду. Агентское предприятие начинается с одного осознания.

00:15:25.360 --> 00:15:29.420
Нам не нужно контролировать каждую переменную, чтобы получить надежный результат. Нам нужно

00:15:29.420 --> 00:15:33.800
контролировать только архитектуру. Наша задача – определить пороги и установить границы,

00:15:34.040 --> 00:15:38.600
чтобы агенты могли работать в этих рамках. В этом мире ваша бизнес-логика становится эластичной.

00:15:38.760 --> 00:15:42.600
Она адаптируется к новому поставщику или формату документов, не требуя от разработчика

00:15:42.600 --> 00:15:46.940
переписывать ни строчки кода. В этом и заключается истинное обещание лоу-код. Это способность

00:15:46.940 --> 00:15:51.120
двигаться со скоростью мысли, а не со скоростью синтаксиса. Но чтобы прийти к этому, нужно начать

00:15:51.120 --> 00:15:54.860
уже сегодня. Перестаньте строить для идеального мира и начните строить для того несовершенного,

00:15:54.860 --> 00:15:59.960
в котором мы живем. Нужно принять сомнения. Задача по внедрению. Вот ваши домашние задания на

00:15:59.960 --> 00:16:04.100
неделю. Я хочу, чтобы вы нашли свой самый проблемный поток. Не выбирайте самый сложный,

00:16:04.280 --> 00:16:08.680
а найдите тот, который чаще всего падает из-за плохих данных. Цель – не исправить данные. Вы не

00:16:08.680 --> 00:16:12.520
можете контролировать то, что присылают вам пользователи или поставщики. Вместо того,

00:16:12.640 --> 00:16:17.580
чтобы бороться с реальностью, добавьте порог уверенности. Зайдите в свой iBuilder или действие LLM и

00:16:17.580 --> 00:16:22.920
выведите этот показатель вероятности. Создайте простое условие. Если показатель уверенности ниже 85%,

00:16:22.920 --> 00:16:26.720
не давайте потоку завершаться с ошибкой. Перенаправьте этот случай в папку для проверки или

00:16:26.720 --> 00:16:31.220
список SharePoint для ручного контроля. Посмотрите, что произойдет с вашим уровнем успеха. Вы увидите,

00:16:31.340 --> 00:16:34.600
как напряжение покинет систему, как только вы перестанете притворяться, что все входные данные

00:16:34.600 --> 00:16:37.700
будут идеальными. Если этот сдвиг в мышлении изменил ваш подход, подпишитесь на меня,

00:16:37.860 --> 00:16:41.600
Мирку Питерса, в LinkedIn. Я постоянно делюсь глубокими разборами этих архитектурных

00:16:41.600 --> 00:16:46.100
паттернов. Поделитесь этим с командой, особенно если ваши потоки ломаются прямо сейчас. Нам пора перестать

00:16:46.100 --> 00:16:50.280
строить из стекла и начать строить с намерением. Это и есть метод, который сокращает время простоя вдвое,

00:16:50.280 --> 00:16:54.020
как только вы начнете его практиковать. Если вам нужна продвинутая версия, которую использует

00:16:54.020 --> 00:16:57.800
профи, посмотрите это следующее видео. Подписывайтесь, чтобы увидеть больше уроков.

00:16:57.900 --> 00:17:01.720
Перестаньте бороться с беспорядком в данных и начните проектировать с учетом этой реальности.

00:17:01.900 --> 00:17:06.540
Используя показатели уверенности, вы превращаете хрупкие процессы в надежные рабочие системы.

00:17:06.640 --> 00:17:10.340
Но вот в чем дело. Модель работает только в том случае, если вы создали ее правильно.

00:17:10.540 --> 00:17:15.060
Если хотите узнать, как настроить это в Капайлот Студия, посмотрите следующее видео прямо сейчас.

00:17:15.060 --> 00:17:20.180
И если это изменило ваш взгляд на ИИ, подписывайтесь на меня в LinkedIn или на рассылку Master the New Model.