WEBVTT 00:00:00.000 --> 00:00:03.860 Twoje automatyzacje low-code psują się, bo są zbyt inteligentne dla własnego dobra. 00:00:04.080 --> 00:00:09.860 Sztywna logika, jeśli to, to wyrok śmierci, gdy mierzysz się z nieuporządkowanymi danymi, które codziennie zawieszają Twoje systemy. 00:00:10.040 --> 00:00:13.260 Założenie, że dane są czyste, to grzech pierworodny projektowania low-code. 00:00:13.540 --> 00:00:17.880 Zbudowaliśmy nasz świat na modelu, jeśli to, ale ten model wymaga absolutnej pewności, by działać. 00:00:18.060 --> 00:00:19.720 Dane w świecie rzeczywistym nie są pewne. 00:00:19.960 --> 00:00:24.440 Zawierają literówki, brakuje im kontekstu, to chaotyczny strumień ludzkich błędów. 00:00:24.440 --> 00:00:29.400 Gdy deterministyczny system napotyka 1% odchylenia, nie nagina się i z pewnością nie adaptuje. 00:00:29.400 --> 00:00:35.400 Po prostu się psuje, tworzy to pułapkę kruchości, w której automatyzacja jest tak silna, jak Twój najczystszy punkt danych. 00:00:35.560 --> 00:00:41.880 W przedsiębiorstwie to bardzo nisko zawieszona poprzeczka dla sukcesu, ale problemem nie są dane, tylko model, którego używamy do ich przetwarzania. 00:00:42.100 --> 00:00:46.800 Śmierć determinizmu, logika deterministyczna to relikt ery danych strukturalnych. 00:00:47.000 --> 00:00:52.800 Działała, gdy wszystko znajdowało się w tabelach SQL i gdy zmuszaliśmy ludzi do dopasowania się do z góry określonych ram. 00:00:52.800 --> 00:00:54.480 Ale ten świat już przeminął. 00:00:54.620 --> 00:01:00.400 Dziś 80% danych w firmach jest nieustrukturyzowanych, co oznacza, że żyją w e-mailach, czatach i nagraniach głosowych. 00:01:00.600 --> 00:01:06.060 Tradycyjne przepływy Power Automate traktują Jabka i 4PPL3 jak dwa różne wszechświaty. 00:01:06.340 --> 00:01:09.760 Dla systemu binarnego są to całkowicie niepowiązane ciągi znaków. 00:01:09.760 --> 00:01:14.960 Osiągnęliśmy punkt krytyczny, w którym koszt ręcznego czyszczenia danych przewyższa wartość samej automatyzacji. 00:01:15.200 --> 00:01:20.740 Jeśli musisz spędzić dwie godziny na poprawianiu pliku CSV tylko po to, by przepływ działał przez pięć sekund, w rzeczywistości niczego nie zautomatyzowałeś. 00:01:20.860 --> 00:01:22.680 Po prostu przeniosłeś pracę w inne miejsce. 00:01:22.920 --> 00:01:26.220 A i to nie tylko błyszcząca nowa funkcja, którą doklejamy do Power Platform. 00:01:26.500 --> 00:01:30.020 To fundamentalne przejście od dokładnego dopasowania do podobieństwa. 00:01:30.420 --> 00:01:32.120 Stary model pyta, czy to jest A? 00:01:32.300 --> 00:01:34.480 Nowy model pyta, jak bardzo przypomina to A? 00:01:34.480 --> 00:01:37.220 Pomyśl o tym, jak poruszasz się po swojej skrzynce odbiorczej. 00:01:37.220 --> 00:01:39.860 Nie uruchamiasz w głowie wyrażeń regularnych, aby znaleźć fakturę. 00:01:40.040 --> 00:01:40.880 Szukasz wzorców. 00:01:41.100 --> 00:01:42.020 Szukasz kontekstu. 00:01:42.280 --> 00:01:47.440 Rozpoznajesz, że INV202 i numer faktury 202 to to samo, nawet jeśli znaki się nie zgadzają. 00:01:47.700 --> 00:01:49.720 Systemy deterministyczne nie potrafią tego zrobić. 00:01:49.960 --> 00:01:51.080 Są ślepe na intencje. 00:01:51.320 --> 00:01:52.280 Widzą tylko składnie. 00:01:52.440 --> 00:01:56.740 A w miarę zbliżania się do 2026 roku składnia staje się mniej ważna niż semantyka. 00:01:56.940 --> 00:02:02.860 Obserwujemy ogromną eksplozję ilości danych z czujników IOT, strumieni w czasie rzeczywistym i podsumowań generowanych przez LLM. 00:02:02.860 --> 00:02:06.300 Jeśli spróbujesz zarządzać tą ilością za pomocą sztywno zakodowanych rozgałęzień, 00:02:06.300 --> 00:02:08.180 jeśli to Twoja logika stanie się labiryntem. 00:02:08.360 --> 00:02:14.000 Skończysz z przepływami mającymi 50 zagnieżdżonych warunków, które i tak zepsują się w momencie, gdy dostawca zmieni swój podpis w e-mailu. 00:02:14.200 --> 00:02:18.480 Model, jeżeli to zakłada idealny świat, w którym dane wejściowe zawsze pasują do schematu. 00:02:18.640 --> 00:02:20.900 W rzeczywistości jest jednak dokładnie odwrotnie. 00:02:21.080 --> 00:02:22.220 To dane są zmienną. 00:02:22.460 --> 00:02:26.940 Logika powinna być stałą, ale nasza logika była zbyt sztywna, by przetrwać kontakt z rzeczywistością. 00:02:27.200 --> 00:02:32.700 Budujemy szklane domy w świecie, w którym ciągle pada grat, a potem dziwimy się, że podłoga jest pełna odłamków. 00:02:32.700 --> 00:02:36.780 Przejście na projektowanie probabilistyczne to budowanie z gumy zamiast ze szkła. 00:02:37.000 --> 00:02:41.440 Chodzi o tworzenie systemów, które mogą przyjąć uderzenie literówki bez rozpatania się. 00:02:41.640 --> 00:02:48.600 Odchodzimy od przekonania, że system musi być w 100% poprawny lub w 100% błędny, bo w realnym świecie nic nie ma 100%. 00:02:48.600 --> 00:02:51.700 Od dekad okłamujemy samych siebie w kwestii jakości naszych danych. 00:02:51.700 --> 00:02:58.240 Budowaliśmy sterylne pokoje dla naszej logiki, a potem udawaliśmy zaskoczenie, gdy niechlujne dane od zespołu sprzedaży powodowały awarię systemu. 00:02:58.400 --> 00:03:00.600 Śmierć determinizmu to śmierć tego kłamstwa. 00:03:00.760 --> 00:03:04.880 To przyznanie, że nie możemy kontrolować danych wejściowych, więc musimy unowocześnić przetwarzanie. 00:03:05.080 --> 00:03:11.340 Wkraczamy w erę przybliżonego przedsiębiorstwa, w której akceptujemy, że wystarczająco blisko jest lepsze niż precyzyjnie błędnie. 00:03:11.500 --> 00:03:19.260 Ponieważ system, który przetworzy 90% dopasowania, jest nieskończenie cenniejszy niż ten, który odrzuca wszystko poza 100% z godnością. 00:03:19.260 --> 00:03:22.260 To nie tylko zmiana techniczna, to zmiana psychologiczna. 00:03:22.480 --> 00:03:26.880 Musisz oswoić się z myślą, że twój system może być tylko całkiem pewny danych. 00:03:27.140 --> 00:03:32.700 Musisz nauczyć się projektować z myślą o wątpliwościach, bo to jedyny uczciwy sposób na obsługę nieustrukturyzowanych informacji. 00:03:32.880 --> 00:03:39.140 Ta zmiana wymaga przejścia od binarnych wyzwalaczy do czegoś znacznie bardziej subtelnego w wyniku pewności architektury niepewności. 00:03:39.360 --> 00:03:43.920 Jeśli przyjmiemy, że era logiki binarnej dobiegła końca, musimy zastąpić ją nowymi ramami. 00:03:44.160 --> 00:03:46.200 Nazywam to modelem orkiestry symfonicznej. 00:03:46.200 --> 00:03:53.240 W tradycyjnej architekturze id każdy jest solistą grającym ze sztywnego zapisu, a jeśli ktoś chybi choć jedną nutę, cały występ zostaje przerwany. 00:03:53.440 --> 00:03:57.900 W architekturze probabilistycznej mamy deterministycznych dyrygentów zarządzających probabilistycznymi muzykami. 00:03:58.120 --> 00:04:00.280 Dyrygentem jest twój przepływ w powerautomatę. 00:04:00.460 --> 00:04:03.140 Dostarcza strukturę, narzuca tempo i wyznacza granice. 00:04:03.360 --> 00:04:04.700 Muzykami są modele AI. 00:04:05.020 --> 00:04:10.600 Są utalentowani, ale ekspresyjni i nie zawsze trafiają w dokładnie tę samą częstotliwość za każdym razem, gdy grają. 00:04:10.600 --> 00:04:13.780 Zadaniem dyrygenta nie jest zmuszanie muzyków, by byli robotami. 00:04:13.780 --> 00:04:18.220 Chodzi o to, by ich słuchać i decydować, czy dźwięk, który wydają jest wystarczająco dobry, by grać dalej. 00:04:18.380 --> 00:04:21.900 To prowadzi nas do głównego filaru nowoczesnego projektowania wyniku pewności. 00:04:22.140 --> 00:04:25.760 Wynik pewności to wartość od 0 do 1, która określa stopień wątpliwości. 00:04:26.020 --> 00:04:30.420 To sposób, w jaki model mówi, sądzę, że to pasuje i oto ile jestem w stanie na to postawić. 00:04:30.420 --> 00:04:33.060 W dawnym świecie mieliśmy sztywno zakodowane ścieżki. 00:04:33.280 --> 00:04:36.300 Jeśli temat wiadomości zawiera słowo faktura, zapisz załącznik. 00:04:36.460 --> 00:04:39.260 W nowym świecie stosujemy przekierowania oparte na poziomie pewności. 00:04:39.460 --> 00:04:42.160 Uwidaczniamy wewnętrzne wątpliwości modelu dla systemu. 00:04:42.340 --> 00:04:47.440 Nie traktujemy już AI jak czarnej skrzynki, lecz jak świadka o określonym poziomie wiarygodności. 00:04:47.680 --> 00:04:50.020 Oto jak faktycznie zbudować to w Power Platform. 00:04:50.240 --> 00:04:54.060 Korzystając z AI Builder lub Azure AI nie otrzymujesz tylko wyodrębnionych danych. 00:04:54.240 --> 00:04:58.140 Otrzymujesz warstwę metadanych, która ujawnia prawdopodobieństwo dla każdego pojedynczego pola. 00:04:58.140 --> 00:05:03.800 Jeśli model wyodrębni kwotę 1500 dolarów, poinformuje Cię też, że jest tego pewien w 95%. 00:05:03.800 --> 00:05:06.540 Jako architekt masz teraz trzy odrębne strefy działania. 00:05:06.720 --> 00:05:08.080 Po pierwsze, strefa zielona. 00:05:08.300 --> 00:05:10.640 Pewność wynosi 0,90 lub więcej. 00:05:10.940 --> 00:05:15.200 Ryzyko błędu jest niskie, koszt pomyłki akceptowalny, a rezultat to pełna automatyzacja. 00:05:15.480 --> 00:05:17.320 System działa bez interwencji człowieka. 00:05:17.480 --> 00:05:18.720 Po drugie, strefa żółta. 00:05:18.940 --> 00:05:21.780 Pewność mieści się w przedziale od 0,60 do 0,89. 00:05:22.460 --> 00:05:24.820 Model jest dość pewny, ale nie ma pewności całkowitej. 00:05:24.960 --> 00:05:27.720 Może dokument był nieco rozmazany, a może pismo było nieczytelne. 00:05:27.720 --> 00:05:29.360 W tej strefie stosujesz oznaczenie. 00:05:29.620 --> 00:05:32.480 System kieruje dane do weryfikacji przez człowieka w celu szybkiego sprawdzenia. 00:05:32.660 --> 00:05:33.880 Po trzecie, strefa czerwona. 00:05:34.100 --> 00:05:35.720 Pewność jest poniżej 0,60. 00:05:36.260 --> 00:05:37.100 Model zgaduje. 00:05:37.300 --> 00:05:39.500 W tej strefie odrzucasz dane lub eskalujesz sprawę. 00:05:39.660 --> 00:05:41.720 Nie dopuszczasz takich danych w pobliże swojej bazy produkcyjnej. 00:05:42.360 --> 00:05:44.280 To przejrzysta warstwa zarządzania ryzykiem. 00:05:44.500 --> 00:05:47.620 Pozwala ona skalować automatyzację przy jednoczesnym zachowaniu bezpiecznika. 00:05:47.840 --> 00:05:49.900 Pomyśl o implikacjach dla ładu korporacyjnego. 00:05:50.120 --> 00:05:52.220 W systemie deterministycznym błędy są ciche. 00:05:52.220 --> 00:05:56.580 Przepływ działa, wybiera błędną liczbę z powodu literówki i zapisuje ją w systemie ERP. 00:05:56.780 --> 00:05:58.820 Dowiadujesz się o tym dopiero pod koniec kwartału. 00:05:59.000 --> 00:06:01.320 W systemie probabilistycznym błąd ma swoją sygnaturę. 00:06:01.520 --> 00:06:02.940 System wie, że ma trudności i mówi 00:06:02.940 --> 00:06:06.200 Hej, przetworzyłem to, ale moja pewność wyniosła tylko 62%. 00:06:06.200 --> 00:06:07.700 To niezwykle potężny sygnał. 00:06:07.860 --> 00:06:09.820 Pozwala on zbudować pulpit nawigacyjny wątpliwości. 00:06:10.120 --> 00:06:12.120 Możesz dokładnie zobaczyć, gdzie twoje modele zawodzą. 00:06:12.360 --> 00:06:15.500 Widzisz, którzy dostawcy przesyłają dokumenty, których AI nie może odczytać 00:06:15.500 --> 00:06:18.000 i które kroki procesów stale trafiają do strefy żółtej. 00:06:18.000 --> 00:06:20.920 Nie budujesz tylko przepływu, budujesz pętlę inteligencji. 00:06:21.080 --> 00:06:24.060 I właśnie tutaj Azure AI oraz AI Builder naprawdę błyszczą. 00:06:24.320 --> 00:06:26.380 Udostępniają one te wyniki na poziomie szczegółowym, 00:06:26.480 --> 00:06:29.900 więc możesz sprawdzić pewność dla konkretnej tabeli, komórki lub danego zamiaru. 00:06:30.160 --> 00:06:32.760 Możesz nawet użyć PowerFa, aby stworzyć dynamiczne progi. 00:06:33.000 --> 00:06:37.020 Być może dla raportu wydatków na 50 dolarów pewność 0,7 jest w porządku, 00:06:37.220 --> 00:06:40.620 ale dla zamówienia na 50 tysięcy dolarów potrzebujesz 0,98. 00:06:41.140 --> 00:06:44.300 W końcu dostosowujesz swoją logikę techniczną do ryzyka biznesowego. 00:06:44.300 --> 00:06:48.120 Traktowaliśmy każdy punkt danych tak, jakby miał taką samą wagę, ale tak nie jest. 00:06:48.280 --> 00:06:53.020 Projektowanie probabilistyczne pozwala traktować decyzje o wysokiej stawce inaczej niż te o niskiej, 00:06:53.120 --> 00:06:54.340 nawet w tym samym przepływie. 00:06:54.540 --> 00:06:57.460 Nie budujesz już dla idealnego świata, budujesz dla świata, 00:06:57.580 --> 00:07:00.800 w którym dokładnie wiesz, ile niepewności jesteś w stanie tolerować. 00:07:00.980 --> 00:07:04.920 A gdy opanujesz wynik, możesz zacząć przyglądać się logice, która wypełnia luki. 00:07:05.260 --> 00:07:07.280 Dopasowanie rozmyte i logika semantyczna. 00:07:07.280 --> 00:07:11.320 Ale jak właściwie radzimy sobie z danymi, które wpadają w ten obszar niepewności? 00:07:11.540 --> 00:07:14.100 Zaczynamy od przyznania, że dokładne dopasowanie zawodzi. 00:07:14.300 --> 00:07:16.140 Zawodzi, ponieważ brakuje mu kontekstu. 00:07:16.340 --> 00:07:18.660 W starym modelu, jeśli nazwa dostawcy różniła się choćby kropką, 00:07:18.760 --> 00:07:20.060 wyszukiwanie kończyło się niepowodzeniem. 00:07:20.280 --> 00:07:23.420 Wyszukiwanie nie dba o Twój zamiar, liczą się dla niego tylko wartości ASCII. 00:07:23.600 --> 00:07:25.680 W tym miejscu pojawia się dopasowanie rozmyte. 00:07:25.840 --> 00:07:28.600 To technika, która identyfikuje i łączy nieidentyczne rekordy 00:07:28.600 --> 00:07:30.400 poprzez obliczanie wskaźnika podobieństwa 00:07:30.400 --> 00:07:32.700 i działa jako pomost między IBM a IBM. 00:07:32.960 --> 00:07:34.780 A ten wpływ nie jest tylko teoretyczny. 00:07:34.780 --> 00:07:36.920 Badania pokazują, że wdrożenie dopasowania rozmytego 00:07:36.920 --> 00:07:38.780 może poprawić wskaźniki dopasowań nawet o 24%. 00:07:39.320 --> 00:07:42.120 To 24% Twoich danych, które wcześniej zostałyby odrzucone 00:07:42.120 --> 00:07:43.920 lub wysłane do człowieka w celu ręcznej poprawy. 00:07:44.060 --> 00:07:46.940 W środowisku o dużej skali oznacza to tysiące godzin odzyskanego czasu. 00:07:47.180 --> 00:07:48.980 Jednak musisz zrozumieć mechanikę tego procesu. 00:07:49.120 --> 00:07:51.000 Istnieją dwa główne sposoby myślenia o tym zagadnieniu. 00:07:51.120 --> 00:07:52.700 Po pierwsze, logika oparta na znakach. 00:07:52.860 --> 00:07:54.660 Często nazywa się to odległością Lewenshtajna. 00:07:54.880 --> 00:07:56.640 Liczy ona liczbę edycji potrzebnych do przekształcenia 00:07:56.640 --> 00:07:57.740 jednego ciągu znaków w drugi. 00:07:57.740 --> 00:07:59.740 Jest idealna do wykrywania literówek. 00:07:59.900 --> 00:08:02.180 Jeśli ktoś napisze manage zamiast management, 00:08:02.400 --> 00:08:04.120 system widzi brakujące EIA, 00:08:04.120 --> 00:08:07.060 oblicza odległość i widzi, że są niemal identyczne. 00:08:07.260 --> 00:08:09.160 Po drugie, mamy logikę semantyczną. 00:08:09.340 --> 00:08:11.120 Tutaj sprawy robią się interesujące. 00:08:11.340 --> 00:08:13.020 Logika semantyczna nie dba opisownie. 00:08:13.240 --> 00:08:14.320 Liczy się dla niej znaczenie. 00:08:14.580 --> 00:08:16.040 Jeśli jeden system mówi klient, 00:08:16.160 --> 00:08:17.000 a drugi odbiorca, 00:08:17.120 --> 00:08:19.460 dopasowanie oparte na znakach zawiedzie za każdym razem. 00:08:19.680 --> 00:08:21.840 Ale model semantyczny wie, że to to samo. 00:08:21.840 --> 00:08:24.900 To przejście od dopasowywania znaków do dopasowywania pojęć. 00:08:25.060 --> 00:08:27.300 Łącząc wskaźniki pewności z dopasowaniem rozmytym, 00:08:27.380 --> 00:08:28.960 tworzysz system, który potrafi poruszać się 00:08:28.960 --> 00:08:30.840 w chaotycznej rzeczywistości danych biznesowych. 00:08:30.840 --> 00:08:32.580 Nie ograniczają Cię już sztywne reguły, 00:08:32.700 --> 00:08:35.020 które psują się w momencie, gdy człowiek zrobi literówkę. 00:08:35.260 --> 00:08:37.200 Budujesz system, który rozumie niuanse. 00:08:37.460 --> 00:08:39.800 Właśnie w ten sposób przechodzisz od prostej automatyzacji 00:08:39.800 --> 00:08:41.300 do prawdziwej cyfrowej inteligencji, 00:08:41.420 --> 00:08:43.140 tworząc samokorygujące się przepływy pracy. 00:08:43.400 --> 00:08:45.020 Nawet z najlepszym dopasowaniem rozmytym na świecie 00:08:45.020 --> 00:08:46.300 musimy zmierzyć się z rzeczywistością, 00:08:46.400 --> 00:08:48.080 w której sztuczna inteligencja wciąż halucynuje. 00:08:48.080 --> 00:08:50.080 Tak po prostu działa obecnie ta technologia. 00:08:50.300 --> 00:08:51.300 Aktualne dane pokazują, 00:08:51.460 --> 00:08:52.920 że nawet najbardziej zaawansowane modele 00:08:52.920 --> 00:08:55.760 mają wskaźniki halucynacji na poziomie od 15 do 20%. 00:08:55.760 --> 00:08:57.320 Jeśli budujesz systemy dla biznesu, 00:08:57.320 --> 00:09:00.040 nie możesz ignorować współczynnika błędów wynoszącego 1 na 5 00:09:00.040 --> 00:09:02.520 i zdecydowanie nie rozwiążesz tego samym inżynieringiem promptów. 00:09:02.700 --> 00:09:03.820 Musisz zaakceptować fakt, 00:09:04.020 --> 00:09:06.760 że osiągnięcie 0% halucynacji to nie magiczka sztuczka. 00:09:06.920 --> 00:09:08.540 To świadomy wybór architektoniczny. 00:09:08.720 --> 00:09:10.700 W tym miejscu wykraczamy poza prostą automatyzację 00:09:10.700 --> 00:09:13.200 i zaczynamy budować odporne, samokorygujące się przepływy pracy. 00:09:13.200 --> 00:09:14.740 Robimy to stosując strukturę, 00:09:14.820 --> 00:09:16.700 którą nazywam wzorcem weryfikacji dwutorowej. 00:09:16.900 --> 00:09:17.860 Działa ona jak zabezpieczenie, 00:09:18.020 --> 00:09:19.460 które powstrzymuje kreatywną wyobraźnię, 00:09:19.540 --> 00:09:21.300 a i przed zniekształceniem Twoich rzeczywistych danych. 00:09:21.300 --> 00:09:24.040 Istnieje jedna fundamentalna zasada dla nowoczesnego architekta. 00:09:24.220 --> 00:09:26.800 Nigdy nie pozwalaj dużemu modelowi językowemu wykonywać obliczeń. 00:09:27.000 --> 00:09:29.220 LLMY to silniki miękkiego rozumowania, 00:09:29.380 --> 00:09:31.160 co czyni je świetnymi w rozumieniu intencji 00:09:31.160 --> 00:09:34.080 lub znajdowaniu konkretnych szczegółów w stercie niechlujnego tekstu. 00:09:34.300 --> 00:09:36.020 Są jednak statystycznie niewiarygodne, 00:09:36.080 --> 00:09:37.800 jeśli chodzi o podstawową arytmetykę. 00:09:37.800 --> 00:09:41.760 Jeśli poprosisz AI o wyciągnięcie trzech pozycji z faktury i obliczenie sumy, 00:09:41.880 --> 00:09:43.480 w zasadzie prosisz system o porażkę. 00:09:43.700 --> 00:09:45.600 W samokorygującym się projekcie używasz LLM 00:09:45.600 --> 00:09:47.380 do części wymagającej miękkiego rozumowania, 00:09:47.380 --> 00:09:49.780 np. do wyciągania danych z nieczytelnego pliku PDF. 00:09:50.040 --> 00:09:53.000 Gdy masz już te liczby, przekazujesz je do systemu deterministycznego, 00:09:53.160 --> 00:09:54.580 aby obsłużył twarde ograniczenia. 00:09:54.780 --> 00:09:57.500 To Twój przepływ w powerautomatę lub prosty silnik reguł 00:09:57.500 --> 00:09:59.040 powinien zajmować się dodawaniem. 00:09:59.220 --> 00:10:02.280 To on powinien sprawdzać podatek lub weryfikować przeliczenie waluty. 00:10:02.280 --> 00:10:05.060 Jeśli LLM twierdzi, że suma wynosi 500 dolarów, 00:10:05.140 --> 00:10:07.540 a Twoje obliczenia wskazują na 480 dolarów, 00:10:07.680 --> 00:10:09.500 system wykrył halucynację w czasie rzeczywistym. 00:10:09.680 --> 00:10:12.480 Zamiast ulec awarii, system uruchamia ścieżkę odzyskiwania. 00:10:12.720 --> 00:10:14.140 Może spróbować innego promptu 00:10:14.140 --> 00:10:16.380 lub oznaczyć błąd do weryfikacji przez człowieka. 00:10:16.580 --> 00:10:19.040 Na tym polega różnica między przepływem, który się psuje, 00:10:19.140 --> 00:10:20.540 a takim, który sam się naprawia. 00:10:20.740 --> 00:10:22.060 Obserwujemy taką samą zmianę 00:10:22.060 --> 00:10:23.900 w zrobotyzowanej automatyzacji procesów. 00:10:24.060 --> 00:10:25.580 Tradycyjne RPA jest bardzo kruche, 00:10:25.680 --> 00:10:27.800 ponieważ zależy od dokładnych współrzędnych na ekranie. 00:10:27.800 --> 00:10:30.080 Jeśli przycisk przesunie się tylko o 3 piksele w lewo, 00:10:30.200 --> 00:10:31.340 cały bot przestaje działać. 00:10:31.740 --> 00:10:33.140 Samonaprawiające się RPA zmienia to 00:10:33.140 --> 00:10:34.900 dzięki zastosowaniu wizji probabilistycznej. 00:10:35.120 --> 00:10:37.560 Bot nie szuka już konkretnych współrzędnych pikseli. 00:10:37.740 --> 00:10:40.080 Zamiast tego szuka przycisku wyglądającego jak ikona 00:10:40.080 --> 00:10:41.420 zapisu w górnej części strony. 00:10:41.420 --> 00:10:44.160 Gdy interfejs się zmienia, bot wykorzystuje kontekst, 00:10:44.240 --> 00:10:45.340 by dostosować się w locie. 00:10:45.560 --> 00:10:46.700 Rozpoznaje nowy układ, 00:10:46.900 --> 00:10:49.160 aktualizuje własną logikę i kończy zadanie. 00:10:49.380 --> 00:10:50.620 Tworzy to odporną pętlę, 00:10:50.700 --> 00:10:52.740 w której system widzi potencjalną awarię 00:10:52.740 --> 00:10:53.740 i tworzy rozwiązanie, 00:10:53.860 --> 00:10:55.280 zanim użytkownik zorientuje się, 00:10:55.400 --> 00:10:56.240 że wystąpił problem. 00:10:56.460 --> 00:10:58.000 Ta zmiana przesuwa nasz punkt ciężkości 00:10:58.000 --> 00:11:00.500 z wskaźników sukcesu na wskaźniki odzyskiwania sprawności. 00:11:00.720 --> 00:11:02.680 Przestajemy próbować uczynić AI idealną, 00:11:02.760 --> 00:11:03.900 co i tak jest niemożliwe, 00:11:03.960 --> 00:11:05.620 a zaczynamy czynić system niezawodnym. 00:11:05.880 --> 00:11:07.480 Chodzi o wbudowanie warstwy kontroli 00:11:07.480 --> 00:11:09.000 w każdą pojedynczą transakcję. 00:11:09.240 --> 00:11:11.700 Należy traktować AI jak bardzo szybkiego starzystę, 00:11:11.820 --> 00:11:12.880 który łatwo się rozprasza. 00:11:13.020 --> 00:11:15.240 Pozwalasz mu na czarną robotę czytania tysięcy e-maili, 00:11:15.320 --> 00:11:17.120 ale nigdy nie pozwalasz mu podpisywać czeków 00:11:17.120 --> 00:11:19.360 bez weryfikacji podpisu przez starszego audytora. 00:11:19.560 --> 00:11:21.540 W tym przypadku to twój deterministyczny kod 00:11:21.540 --> 00:11:22.500 jest tym audytorem. 00:11:22.760 --> 00:11:24.300 Oddzielając myślenie od obliczeń, 00:11:24.460 --> 00:11:26.040 budujesz system, który radzi sobie 00:11:26.040 --> 00:11:27.440 z nieładem ludzkiego języka, 00:11:27.620 --> 00:11:29.820 zachowując precyzję szwajcarskiego zegarka. 00:11:29.820 --> 00:11:32.140 W ten sposób przenosisz AI z fazy testów 00:11:32.140 --> 00:11:33.900 do samego rdzenia swojej działalności. 00:11:33.900 --> 00:11:36.080 Nie ufasz modelowi, ufasz architekturze, 00:11:36.180 --> 00:11:37.540 którą wokół niego zbudowałeś. 00:11:37.720 --> 00:11:38.900 Tworzysz tak silną siatkę bezpieczeństwa, 00:11:39.680 --> 00:11:41.100 że sporadyczne potknięcia modelu 00:11:41.100 --> 00:11:42.460 nawet nie liczą się jako błąd. 00:11:42.620 --> 00:11:45.400 Stają się po prostu kolejnym elementem cyklu samokorekty. 00:11:46.340 --> 00:11:47.920 Brzmi to świetnie w laboratorium, 00:11:48.120 --> 00:11:50.320 ale w produkcji największym wąskim gardłem 00:11:50.320 --> 00:11:53.060 nie jest AI, lecz człowiek w pętli decyzyjnej. 00:11:53.300 --> 00:11:54.780 Brzmi to świetnie w laboratorium, 00:11:55.000 --> 00:11:57.060 ale w produkcji największym wąskim gardłem 00:11:57.060 --> 00:11:58.600 nie jest AI, lecz człowiek. 00:11:58.900 --> 00:11:59.900 Zazwyczaj mówimy o automatyzacji 00:12:00.540 --> 00:12:03.000 jak o prostym wyborze między człowiekiem a maszyną, 00:12:03.000 --> 00:12:04.620 ale prawdopodobieństwo zmusza nas 00:12:04.620 --> 00:12:06.520 do zajęcia niejednoznacznego stanowiska. 00:12:06.800 --> 00:12:09.660 Standardy branżowe ukazują dość otrzeźwiającą prawdę. 00:12:09.820 --> 00:12:11.200 Około 50% procesów, 00:12:11.280 --> 00:12:13.060 a i wciąż wymaga weryfikacji przez eksperta, 00:12:13.140 --> 00:12:14.160 zanim zostaną zakończone. 00:12:14.320 --> 00:12:15.940 To główny powód, dla którego obserwujemy kryzys 00:12:15.940 --> 00:12:17.420 przy przejściu z fazy pilotażowej do wdrożenia. 00:12:17.680 --> 00:12:18.400 Jeśli spojrzysz na liczby, 00:12:18.460 --> 00:12:19.860 88% programów pilotażowych, 00:12:19.940 --> 00:12:21.100 a i kończy się niepowodzeniem w ciągu roku. 00:12:21.300 --> 00:12:23.360 Nie zawodzą dlatego, że technologia jest zepsuta. 00:12:23.620 --> 00:12:25.300 Zawodzą, ponieważ projektujący je ludzie 00:12:25.300 --> 00:12:28.020 próbują zbyt wcześnie zautomatyzować zadanie w 100%. 00:12:28.020 --> 00:12:30.580 Zbudowali system, który działa na czystych danych testowych, 00:12:30.720 --> 00:12:32.300 ale logika pęka w momencie zetknięcia 00:12:32.300 --> 00:12:33.680 z rzeczywistymi problemami działu. 00:12:33.820 --> 00:12:35.040 Ignorując czynnik ludzki, 00:12:35.160 --> 00:12:37.080 tworzysz ogromne obciążenie weryfikacyjne. 00:12:37.280 --> 00:12:38.560 Jeśli Twoja sztuczna inteligencja 00:12:38.560 --> 00:12:40.180 oszczędza 10 minut wprowadzania danych, 00:12:40.320 --> 00:12:41.940 ale dokłada 50 minut ich sprawdzania, 00:12:42.020 --> 00:12:43.080 ponieważ zespół jej nie ufa, 00:12:43.160 --> 00:12:44.780 to w rzeczywistości tracisz produktywność. 00:12:44.940 --> 00:12:46.740 Zbudowałeś obciążenie, a nie zasób. 00:12:46.980 --> 00:12:48.960 Skuteczne projekty w 2026 roku 00:12:48.960 --> 00:12:50.120 będą traktować weryfikację 00:12:50.120 --> 00:12:51.340 jako kluczową funkcjonalność. 00:12:51.520 --> 00:12:53.420 Nie postrzegają one weryfikacji przez człowieka 00:12:53.420 --> 00:12:54.420 jako porażki systemu. 00:12:54.420 --> 00:12:55.660 Zamiast tego traktują ją 00:12:55.660 --> 00:12:57.280 jako niezbędną część architektury. 00:12:57.440 --> 00:12:58.420 Koszty tej weryfikacji 00:12:58.420 --> 00:12:59.880 wliczają w zwrot z inwestycji 00:12:59.880 --> 00:13:00.840 już od pierwszego dnia. 00:13:01.080 --> 00:13:02.040 Sekretem skuteczności 00:13:02.040 --> 00:13:03.900 jest tutaj warstwowa logika przeglądu. 00:13:04.080 --> 00:13:05.320 W ten sposób skalujesz procesy, 00:13:05.380 --> 00:13:06.840 nie tracąc przy tym zdrowych zmysłów. 00:13:06.960 --> 00:13:08.460 Transakcje o wysokim stopniu pewności 00:13:08.460 --> 00:13:09.520 przebiegają bezszelestnie. 00:13:09.740 --> 00:13:11.720 Jeśli model jest pewny na 98%, 00:13:11.720 --> 00:13:12.700 a matematyka się zgadza, 00:13:12.800 --> 00:13:13.860 system po prostu działa dalej. 00:13:14.080 --> 00:13:15.520 Jednak przypadki o niskiej pewności, 00:13:15.640 --> 00:13:16.420 jak ta żółta strefa, 00:13:16.480 --> 00:13:17.160 o której mówiliśmy, 00:13:17.260 --> 00:13:18.140 wywołają eskalację. 00:13:18.300 --> 00:13:19.960 To całkowicie zmienia rolę człowieka. 00:13:19.960 --> 00:13:21.560 Odchodzimy od wprowadzania danych 00:13:21.560 --> 00:13:22.740 w stronę ich audytowania. 00:13:23.000 --> 00:13:24.640 W starym modelu człowiek był silnikiem, 00:13:24.760 --> 00:13:26.420 bo wykonywał całe pisanie i klikanie. 00:13:26.640 --> 00:13:27.660 W nowym modelu człowiek 00:13:27.660 --> 00:13:28.780 pełni funkcję zarządczą. 00:13:29.040 --> 00:13:29.980 Zajmuje się wyjątkami 00:13:29.980 --> 00:13:30.920 i wprowadza niuanse, 00:13:31.060 --> 00:13:32.300 których model probabilistyczny 00:13:32.300 --> 00:13:33.200 nie do końca rozumie. 00:13:33.360 --> 00:13:35.060 Pomyśl, jak to wpływa na zespół. 00:13:35.280 --> 00:13:35.860 Gdy ludzie wiedzą, 00:13:35.980 --> 00:13:37.320 że muszą zająć się tylko 5% 00:13:37.320 --> 00:13:38.460 faktycznie trudnych przypadków, 00:13:38.580 --> 00:13:40.040 pozostają znacznie bardziej zaangażowani. 00:13:40.260 --> 00:13:41.960 Nie nudzą się już rutynowymi zadaniami. 00:13:42.200 --> 00:13:43.260 Wyzwania stanowi dla nich 00:13:43.260 --> 00:13:44.440 złożoność trudnych spraw. 00:13:44.660 --> 00:13:45.380 Aby to zadziałało, 00:13:45.460 --> 00:13:46.300 musisz jednak stworzyć 00:13:46.300 --> 00:13:47.300 odpowiedni interfejs. 00:13:47.460 --> 00:13:48.520 Nie możesz po prostu wysłać 00:13:48.520 --> 00:13:49.420 e-maila z informacją, 00:13:49.540 --> 00:13:50.320 że coś poszło nie tak. 00:13:50.500 --> 00:13:52.220 Musisz pokazać porównanie obok siebie. 00:13:52.480 --> 00:13:53.920 Pokaż o sobie źródłowy dokument. 00:13:54.240 --> 00:13:55.580 Pokaż, co wyodrębniła AI 00:13:55.580 --> 00:13:56.900 i zaznacz dokładnie to pole, 00:13:57.040 --> 00:13:58.540 w którym poziom pewności spadł. 00:13:58.540 --> 00:13:59.740 Jeśli chcesz się skalować, 00:13:59.860 --> 00:14:00.520 przestań udawać, 00:14:00.640 --> 00:14:01.560 że ludzka weryfikacja 00:14:01.560 --> 00:14:02.540 oznacza słabość automatyzacji. 00:14:03.300 --> 00:14:04.360 Jest wręcz przeciwnie. 00:14:04.620 --> 00:14:05.780 Dobrze zintegrowany człowiek 00:14:05.780 --> 00:14:07.420 sprawia, że system probabilistyczny 00:14:07.420 --> 00:14:08.660 jest wystarczająco silny, 00:14:08.740 --> 00:14:10.160 by przetrwać w świecie rzeczywistym. 00:14:10.340 --> 00:14:11.300 To ostatnia warstwa 00:14:11.300 --> 00:14:13.360 Twojej samokorygującej się architektury. 00:14:13.580 --> 00:14:14.640 Przyszłość agentowa. 00:14:14.880 --> 00:14:16.380 Patrzymy w stronę nowego horyzontu 00:14:16.380 --> 00:14:18.060 zwanego przedsiębiorstwem agentowym. 00:14:18.240 --> 00:14:19.960 To logiczny punkt końcowy wszystkiego, 00:14:20.060 --> 00:14:21.200 o czym dziś rozmawialiśmy. 00:14:21.420 --> 00:14:22.140 Wkraczamy w świat, 00:14:22.140 --> 00:14:23.640 w którym agenci to już nie tylko 00:14:23.640 --> 00:14:24.340 proste skrypty 00:14:24.340 --> 00:14:25.460 czy podstawowe przepływy, 00:14:25.520 --> 00:14:26.280 ponieważ stają się 00:14:26.280 --> 00:14:28.020 pełnoprawnymi cyfrowymi pracownikami. 00:14:28.180 --> 00:14:29.540 Power Platform zmienia się 00:14:29.540 --> 00:14:30.420 na naszych oczach. 00:14:30.600 --> 00:14:31.940 Przekształca się ze standardowego 00:14:31.940 --> 00:14:32.900 kreatora aplikacji 00:14:32.900 --> 00:14:34.320 w pełne centrum orkiestracji. 00:14:34.560 --> 00:14:35.200 W starym modelu 00:14:35.200 --> 00:14:36.660 tworzyłeś konkretną aplikację, 00:14:36.820 --> 00:14:38.140 aby rozwiązać konkretny problem. 00:14:38.380 --> 00:14:39.280 W modelu agentowym 00:14:39.280 --> 00:14:40.180 tworzysz środowisko, 00:14:40.340 --> 00:14:41.540 w którym agenci rozwiązują 00:14:41.540 --> 00:14:42.460 te problemy za Ciebie. 00:14:42.640 --> 00:14:43.800 Ci agenci nie podążają 00:14:43.800 --> 00:14:45.340 tylko za statyczną listą kroków. 00:14:45.540 --> 00:14:46.560 Obserwują swoje otoczenie, 00:14:46.700 --> 00:14:48.000 oceniają własny poziom pewności 00:14:48.000 --> 00:14:48.540 i decydują, 00:14:48.540 --> 00:14:49.820 którego narzędzia najlepiej użyć 00:14:49.820 --> 00:14:50.740 w następnej kolejności. 00:14:50.940 --> 00:14:52.260 Do 2026 roku 00:14:52.260 --> 00:14:53.260 zarządzanie będzie wyglądać 00:14:53.260 --> 00:14:53.880 zupełnie inaczej 00:14:53.880 --> 00:14:54.840 niż jeszcze dwa lata temu. 00:14:55.060 --> 00:14:55.800 Narzędzia takie jak 00:14:55.800 --> 00:14:56.620 Perview i Sentinel 00:14:56.620 --> 00:14:57.520 zmierzają w stronę 00:14:57.520 --> 00:14:59.280 probabilistycznego wykrywania anomalii. 00:14:59.480 --> 00:15:00.520 Nie szukają już tylko 00:15:00.520 --> 00:15:01.520 wyciekłych haseł. 00:15:01.700 --> 00:15:02.800 Zamiast tego wypatrują 00:15:02.800 --> 00:15:03.780 wzorców zachowań, 00:15:03.880 --> 00:15:05.600 które po prostu wyglądają podejrzanie. 00:15:05.880 --> 00:15:07.080 Stosują tę samą logikę 00:15:09.280 --> 00:15:10.880 danych, by chronić cały Twój tenant. 00:15:11.020 --> 00:15:12.200 Ta zmiana jest trwała. 00:15:12.400 --> 00:15:13.260 Osoby trzymające się 00:15:13.260 --> 00:15:13.920 sztywnej logiki, 00:15:14.080 --> 00:15:14.860 jeśli to zostaną 00:15:14.860 --> 00:15:15.940 z uszkodzonymi systemami 00:15:15.940 --> 00:15:17.180 i sfrustrowanymi zespołami, 00:15:17.180 --> 00:15:19.060 utkną w cyklu ciągłej konserwacji, 00:15:19.200 --> 00:15:20.440 próbując łatać szklany dom, 00:15:20.620 --> 00:15:21.720 który nigdy nie był budowany 00:15:21.720 --> 00:15:22.480 na taką pogodę. 00:15:22.640 --> 00:15:23.660 Przedsiębiorstwo agentowe 00:15:23.660 --> 00:15:25.200 zaczyna się od jednego spostrzeżenia. 00:15:25.440 --> 00:15:26.380 Nie musimy kontrolować 00:15:26.380 --> 00:15:27.240 każdej zmiennej, 00:15:27.360 --> 00:15:28.780 aby uzyskać niezawodny wynik. 00:15:28.980 --> 00:15:30.140 Musimy jedynie kontrolować 00:15:30.140 --> 00:15:30.840 architekturę. 00:15:31.060 --> 00:15:31.860 Naszym zadaniem jest 00:15:31.860 --> 00:15:32.860 zdefiniowanie progów 00:15:32.860 --> 00:15:34.060 i ustawienie zabezpieczeń, 00:15:39.280 --> 00:15:40.400 by obsłużyć nowego dostawcę 00:15:40.400 --> 00:15:41.500 lub inny format dokumentu 00:15:41.500 --> 00:15:42.600 bez konieczności przepisywania 00:15:42.600 --> 00:15:44.000 choćby linii kodu przez programistę. 00:15:44.120 --> 00:15:45.240 To jest prawdziwa obietnica 00:15:45.240 --> 00:15:46.180 rozwiązań low-code. 00:15:46.180 --> 00:15:47.360 To zdolność poruszania się 00:15:47.360 --> 00:15:48.180 z szybkością myśli, 00:15:48.360 --> 00:15:49.340 a nie szybkością składni. 00:15:49.480 --> 00:15:50.460 Ale żeby do tego dojść, 00:15:50.620 --> 00:15:51.480 musisz zacząć dzisiaj. 00:15:51.660 --> 00:15:53.040 Przestań budować dla idealnego świata 00:15:53.040 --> 00:15:54.440 i zacznij budować dla tego chaotycznego, 00:15:54.540 --> 00:15:55.380 w którym naprawdę żyjemy. 00:15:55.600 --> 00:15:57.080 Musisz zaakceptować wątpliwości. 00:15:57.400 --> 00:15:58.400 Wyzwanie wdrożeniowe. 00:15:58.600 --> 00:16:00.240 Oto Twoje zadanie domowe na ten tydzień. 00:16:00.420 --> 00:16:01.540 Chcę, żebyś znalazł swój proces 00:16:01.540 --> 00:16:02.920 o najwyższym wskaźniku awaryjności. 00:16:03.120 --> 00:16:04.500 Nie wybieraj tego najbardziej złożonego, 00:16:04.600 --> 00:16:05.820 ale ten, który najczęściej zawodzi 00:16:05.820 --> 00:16:06.640 z powodu złych danych. 00:16:06.860 --> 00:16:08.400 Celem nie jest naprawa samych danych. 00:16:08.620 --> 00:16:09.500 Nie masz kontroli nad tym, 00:16:09.580 --> 00:16:10.580 co zdecydują się wysłać 00:16:10.580 --> 00:16:11.880 Ci użytkownicy lub dostawcy. 00:16:12.100 --> 00:16:13.580 Zamiast walczyć z tą rzeczywistością, 00:16:13.700 --> 00:16:15.060 chcę, żebyś dodał próg ufności. 00:16:15.320 --> 00:16:16.520 Wejdź do swojego AI Builder 00:16:16.520 --> 00:16:17.380 lub akcji LLM 00:16:17.380 --> 00:16:19.200 i udostępnij ten wynik prawdopodobieństwa. 00:16:19.420 --> 00:16:20.440 Stwórz prosty warunek. 00:16:20.640 --> 00:16:23.060 Jeśli wynik ufności jest poniżej 85%, 00:16:23.060 --> 00:16:24.440 nie pozwól, by proces się zawiesił. 00:16:24.640 --> 00:16:25.780 Skieruj ten konkretny przypadek 00:16:25.780 --> 00:16:26.540 do folderu przeglądu 00:16:26.540 --> 00:16:27.260 lub listy SharePoint 00:16:27.260 --> 00:16:28.360 w celu ręcznej weryfikacji. 00:16:28.560 --> 00:16:29.460 Obserwuj, co stanie się 00:16:29.460 --> 00:16:30.780 z Twoim wskaźnikiem sukcesu. 00:16:30.960 --> 00:16:32.500 Zobaczysz, jak stres opuszcza Twój system, 00:16:32.620 --> 00:16:33.700 gdy tylko przestaniesz udawać, 00:16:33.780 --> 00:16:35.080 że każde wejście będzie idealne. 00:16:35.240 --> 00:16:36.140 Jeśli ta zmiana myślenia 00:16:36.140 --> 00:16:37.240 wpłynęła na Twoje podejście, 00:16:37.340 --> 00:16:38.860 obserwuj mnie, Mirko Petersa, na LinkedIn. 00:16:39.160 --> 00:16:40.780 Stale udostępniam tam szczegółowe analizy 00:16:40.780 --> 00:16:41.980 tych wzorców architektonicznych. 00:16:42.140 --> 00:16:43.400 Udostępnij to swojemu zespołowi, 00:16:43.520 --> 00:16:45.240 zwłaszcza jeśli Wasze procesy obecnie zawodzą. 00:16:45.440 --> 00:16:46.720 Musimy przestać budować ze szkła, 00:16:46.720 --> 00:16:48.060 a zacząć budować z zamierzeniem. 00:16:48.200 --> 00:16:48.900 Oto ta technika, 00:16:49.040 --> 00:16:50.440 która skraca czas przestoju o połowę, 00:16:50.540 --> 00:16:51.700 gdy tylko zaczniesz ją stosować. 00:16:51.900 --> 00:16:53.580 Jeśli chcesz poznać wersję dla zaawansowanych, 00:16:53.660 --> 00:16:54.740 której używają profesjonaliści, 00:16:54.860 --> 00:16:55.520 zobacz kolejny film. 00:16:55.840 --> 00:16:57.720 Zasubskrybuj, aby otrzymywać więcej poradników. 00:16:57.940 --> 00:16:59.600 Przestań walczyć z chaotyczną rzeczywistością 00:16:59.600 --> 00:17:00.140 swoich danych 00:17:00.140 --> 00:17:01.680 i zacznij projektować z myślą o nich. 00:17:01.860 --> 00:17:03.360 Korzystając ze wskaźników ufności, 00:17:03.520 --> 00:17:04.620 przekształcasz kruche procesy 00:17:04.620 --> 00:17:05.460 w odporne systemy, 00:17:05.520 --> 00:17:06.420 które naprawdę działają. 00:17:06.600 --> 00:17:07.780 Ale jest pewien haczyk. 00:17:07.940 --> 00:17:08.940 Model działa tylko wtedy, 00:17:09.100 --> 00:17:10.160 gdy zbudujesz go poprawnie. 00:17:10.160 --> 00:17:11.660 Jeśli chcesz dokładnie zobaczyć, 00:17:11.740 --> 00:17:13.280 jak skonfigurować to w Copilot Studio, 00:17:13.440 --> 00:17:14.960 obejrzyj ten kolejny film już teraz. 00:17:15.140 --> 00:17:16.780 A jeśli to zmieniło twój sposób myślenia 00:17:16.780 --> 00:17:17.780 o sztucznej inteligencji, 00:17:17.920 --> 00:17:18.660 śledź mnie na LinkedIn 00:17:18.660 --> 00:17:20.160 lub zasubskrybuj Master The New Model.