Budowanie rozwiązań AI – jaką ścieżkę wybrać?

Microsoft zaprezentował koncepcję podejścia do projektów AI, którą Łukasz Grala omówił podczas darmowych webinarów w ramach serii Microsoft Agentic AI – deep dive (dostępne pod linkiem: YouTube). Poniższa koncepcja została pokazana w drzewie decyzyjnym (Microsoft Cloud Adoption Framework), które zawiera rekomendacje, jaką ścieżkę należy obrać przy budowaniu rozwiązań AI. Choć na pierwszy rzut oka diagram może wydawać się intuicyjny, jego analiza pomaga uporządkować podejście do wdrażania agentów w organizacjach.

Przeanalizujmy poszczególne etapy diagramu:

Etap 1: Ustrukturyzowane lub przewidywalne zadania

Pierwszym krokiem jest ocena, czy dany przypadek biznesowy dotyczy ustrukturyzowanych lub przewidywalnych zadań. Jeśli problemy są już bardzo dobrze znane, stałe i sformalizowane (jak klasyczne use case’y), to nie ma potrzeby stosowania generatywnej sztucznej inteligencji.

• TAK – należy sięgnąć po klasyczne metody implementacji, wykorzystując kod lub modele AI niegeneratywne. Implementacja może odbywać się przy użyciu Machine Learning, poprzez modele AI w Microsoft Foundry lub w Microsoft Fabric.

• NIE – jeśli zadania nie są ustrukturyzowane, należy przejść do etapu drugiego.

Etap 2: Statyczne pozyskiwanie wiedzy (RAG)

Jeśli zadania nie są przewidywalne, musimy zastanowić się, czy chcemy pozyskiwać statycznie zdefiniowaną wiedzę (czyli dane i fakty, które są przechowywane w bazie i nie zmieniają się dynamicznie w procesie realizacji zadania).

• TAK – bardzo dobrym rozwiązaniem jest wówczas budowanie aplikacji RAG (Retrieval-Augmented Generation). Różnica między RAG a modelami LLM polega na tym, że RAG opiera się na zamkniętym zbiorze informacji, co pozwala na kontrolowane wydobywanie danych. Jest to podejście bardziej kontrolowane i mniej podatne na halucynowanie w porównaniu do klasycznych modeli LLM.

• NIE – jeśli wiedza nie jest statyczna i zadanie jest bardziej skomplikowane, przechodzimy do etapu trzeciego.

Etap 3: Wykorzystanie gotowych agentów (SaaS Agents)

Kolejnym pytaniem jest, czy gotowe systemy agentowe (SaaS Agents) realizują nasze cele biznesowe. Są to agenty dostępne w ramach produktów Microsoft, takich jak M365 Copilot, Azure Copilot Agents, Dynamics 365 Agents, czy App Builder.

• TAK – należy użyć gotowych agentów SaaS.

• NIE – jeśli gotowe agenty nie spełniają wymagań, przechodzimy do budowania niestandardowych (spersonalizowanych) rozwiązań AI.

Etap 4: Budowanie własnych agentów (Custom AI Agents)

Wybór ścieżki do budowania niestandardowych agentów AI zależy od preferowanego podejścia deweloperskiego. Można to zrealizować, korzystając z:

1. Kontenerów i GPU (PaaS lub IaaS). Jest to podejście niskopoziomowe, pozwalające na pełną kontrolę nad infrastrukturą i środowiskiem przetwarzania, co jest realizowane w modelach Platform as a Service lub Infrastructure as a Service. W tym scenariuszu, deweloperzy budują rozwiązanie jako kod i potrzebują elementów, które będą przetwarzać.

2. Platformy Microsoft Foundry z podejściem pro-code. Microsoft Foundry (wcześniej znane jako Azure Foundry) to kompleksowa platforma, którą Microsoft przedstawia jako fabrykę aplikacji AI i agentowych. Foundry dostarcza całe środowisko deweloperskie i framework do budowania rozwiązań, z pełną integracją z narzędziami takimi jak GitHub i Visual Studio, ale nadal trzeba napisać kod sterujący tymi procesami.

3. Copilot Studio w podejściu no-code/low-code (SaaS). Jest to podejście przeznaczone dla użytkowników, którzy chcą budować rozwiązania bez konieczności pisania zaawansowanego kodu. Copilot Studio integruje się z całym ekosystemem agentowym Microsoft, umożliwiając szybkie tworzenie agentów i ich integrację, zwłaszcza w procesach Microsoft 365, co jest uznawane za istotny element dla rozwiązań AI.

Etap 5: System jedno- czy wieloagentowy (Single or multiple agents)

Niezależnie od wybranej technologii budowania, ostatnią, kluczową decyzją jest to, czy potrzebujemy rozwiązania wieloagentowego czy jednoagentowego. Odpowiedź na to pytanie decyduje o tym, jak zostanie zbudowana orkiestracja i workflow pracy agentów.

• System wieloagentowy – należy go budować, jeśli projekt zakłada przyszły wzrost czy zaangażowania wielu zespołów. Systemy wieloagentowe wymagają użycia workflow’ów do implementacji wzorców orkiestracji. Jest to podejście, w którym agenci współpracują ze sobą dynamicznie, realizując skomplikowany plan.

• Test pojedynczego agenta – jeśli zadania charakteryzują się niską złożonością, mają jasne role, priorytetem jest szybkie wejście na rynek, niski koszt lub mała ilość przetwarzanych danych.

Jeśli test pojedynczego agenta spełni wszystkie wymagania, należy zbudować system jednoagentowy, wykorzystując workflow do integracji i zarządzania. Jeśli natomiast test nie spełni wszystkich wymagań, należy przejść do zbudowania systemu wieloagentowego.

Powyższa ścieżka pokazuje oczywiście stack Microsoft’owy, wykorzystujący takie narzędzia jak Microsoft Foundry, Fabric, Copilot Studio oraz usługi agentowe i modelowe w chmurze Azure. Taka wizja dostarcza spójną koncepcję, która ma adresować wyzwania związane z zarządzaniem modelami, bezpieczeństwem (governance) i skomplikowanymi procesami workflow.

Jeżeli chcesz zobaczyć, jak podchodzimy do takich rozwiązań u klientów, zapraszamy do kontaktu – chętnie zaprezentujemy case study z wdrożeń w organizacjach z różnych branż. Email: kontakt@tidk.pl