[Obserwacje z Apsara] Konferencja Apsara nie jest odpowiedzią — to mapa zakładów, które stawia branża AI

Największą wartością, jaką wyniosłem w tym roku z konferencji Apsara (云栖大会), nie były kolejne zapamiętane modele ani start-upy, lecz zmiana sposobu, w jaki patrzę na tego typu wydarzenia.

Na wcześniejszych konferencjach technologicznych łatwo było przyjmować domyślne założenia: kierunki, które duzi gracze mocno komunikują, z dużym prawdopodobieństwem wyznaczają przyszłość; koncepcje powtarzane na scenie to niemal na pewno konsensus branżowy; produkt, który trafił na stoisko wystawiennicze, wydaje się wystarczająco dojrzały. Po pewnym czasie łatwo jednak wpaść w drugą skrajność — uznać, że konferencja to czysty marketing, stoisko to reklama, a slajdy to opakowanie.

Oba podejścia to zbyt duże uproszczenie.

Marketingowa natura tych wydarzeń jest oczywista, ale sam marketing też niesie informację. Gdy producent angażuje budżet, product managerów, zespoły inżynieryjne i sprzedażowe oraz powierzchnię wystawienniczą w jeden kierunek, mówi to przynajmniej dwie rzeczy: w co chce, aby rynek uwierzył, oraz dla jakich problemów podejmuje próby produktowe.

Dlatego dziś wolę traktować duże konferencje technologiczne jak gęsto próbkowane pole obserwacji branży. Nie dają odpowiedzi, ale dostarczają próbek, sygnałów, kontrprzykładów i mapy „na jaką przyszłość stawia branża”.

1. Najpierw rozbierzmy „hałas” konferencji na różne warstwy dowodów

Podczas tegorocznej edycji zacząłem świadomie rozkładać każdy kierunek technologiczny na pięć warstw:

Warstwa narracji → Warstwa produktu → Warstwa produkcyjna → Warstwa biznesowa → Warstwa przychodowa
(Narrative → Product → Production → Business → Revenue)

Na szczycie znajduje się warstwa narracji (Narrative) — to, co dostawcy chcą, by rynek przyjął za pewnik. Na przykład: agenty staną się nowym punktem wejścia do pracy, firmy potrzebują architektur AI-native, kontekst stanie się kluczowym zasobem, a systemy wieloagentowe przejmą coraz bardziej złożone zadania. Te narracje mają znaczenie, bo pokazują, dokąd zmierza uwaga organizacji i gdzie płynie kapitał — ale wciąż są jedynie osądami i zakładami.

Poniżej znajduje się warstwa produktu (Product) — to, co zostało zbudowane i można pokazać, wywołać oraz dostarczyć. Na stoiskach stoją gotowe interfejsy, API, konsolę i platformy governance — a to oznacza, że dany kierunek wyszedł już z fazy koncepcji i wszedł w fazę produktową. Między „da się zademonstrować” a „da się stabilnie eksploatować długoterminowo” wciąż zieje ogromna przepaść.

Jeszcze niżej znajduje się warstwa produkcyjna (Production) — produkt faktycznie wchodzi do procesów klienta, pracuje w trybie ciągłym i zaczyna obijać się o realne problemy: uprawnienia, dane, audyt, odtwarzanie po awarii, koszty, współpracę między działami. Dopiero wówczas można mówić o środowisku produkcyjnym.

Jeszcze niżej znajduje się warstwa biznesowa (Business) – i tu trzeba drążyć dalej: co konkretnie zmieniło się po wdrożeniu? Skrócenie cyklu dostarczania? Wzrost konwersji? Spadek kosztów operacyjnych? Większa liczba wariantów kreacji do testów? A może uruchomienie procesu biznesowego, który wcześniej był po prostu niewykonalny?

Na samym dole – i zarazem najbardziej konkretna – leży warstwa przychodowa (Revenue): czy klient jest gotów płacić długofalowo, za jaki efekt sięga do portfela i przy jakich warunkach dochodzi do odnowienia współpracy.

Sens tego frameworku polega na tym, by nie mieszać ze sobą dowodów różnej kategorii. Stoisko targowe potwierdza, że dany kierunek jest wart pokazania, forum sygnalizuje narrację, którą dostawca chce wzmocnić, wdrożenia u realnych klientów podnoszą wiarygodność warstwy produkcyjnej i biznesowej, a dopiero powtarzalne przychody weryfikują warstwę przychodową.

Samo zainteresowanie danym kierunkiem na konferencji nie oznacza więc automatycznie „wdrażajmy już teraz”.

II. Najbardziej widoczna zmiana tej edycji: nad modelem wyrasta coraz więcej warstw

Jeszcze kilka lat temu rozmowa o AI kręciła się niemal wyłącznie wokół modelu: liczba parametrów, benchmarki, zdolności rozumowania, cena, okno kontekstu, jakość obrazu, umiejętności kodowania.

Na miejscu wyraźnie widać, że punkt ciężkości się przesunął.

Modele nadal mają znaczenie, ale warstwa systemowa wokół nich wyraźnie staje się grubsza. Baza danych, dostęp do modeli, zarządzanie tokenami, środowisko uruchomieniowe agentów (Agent Runtime), piaskownice (Sandbox), kontekst (Context), pamięć (Memory), umiejętności (Skill), obsługa przeglądarki (Browser Use), obsługa komputera (Computer Use), weryfikacja (Verification), obserwowalność (Observability), uprawnienia, audyt, kontrola kosztów — coraz więcej tych zdolności jest wyodrębnianych w osobne produkty.

Powód jest prosty: między modelem, który potrafi odpowiadać na pytania, a modelem, który trafia do środowiska produkcyjnego i niezawodnie wykonuje pracę, stoi cały zestaw systemów inżynieryjnych.

Spędź jeden dzień na targach branżowych, a zobaczysz pięć–sześć produktów o zupełnie różnych nazwach, które w gruncie rzeczy zbiegają się ku tej samej strukturze. QwenWork pokazuje, jak agent w izolowanym środowisku wywołuje wiele narzędzi, by zrealizować zadanie. Qoder opowiada o kontekście, specyfikacji wymagań (Spec), frameworku testowym (Harness), weryfikacji (Verification), pamięci i routingu między modelami. Niezależny wystawca TinyFish umożliwia agentom wchodzenie do prawdziwego świata stron WWW i wykonywanie zadań. WonderClip rozkłada produkcję wideo na scenariusz, storyboard, materiały, generowanie, przegląd, wersjonowanie i produkcję wsadową. Z kolei wyszukiwanie agentowe (Agentic Search) w Alibaba Cloud OpenSearch ponownie rozciąga sam proces wyszukiwania na planowanie (Planning), rozumowanie (Reasoning), pamięć (Memory), działanie (Action) i ocenę (Evaluation).

Na pierwszy rzut oka dzielą je kompletnie różne dziedziny, ale bazowa struktura okazuje się zbieżna:

Kontekst → Planowanie → Umiejętność → Wykonanie → Weryfikacja → Pamięć → Wynik biznesowy
(Context → Planning → Skill → Execution → Verification → Memory → Business Outcome)

Modele stopniowo stają się jednym z kluczowych komponentów, lecz prawdziwa wartość produktu przenosi się w coraz większym stopniu do warstw położonych wyżej.

III. Kontekst (Context) — z „materiału wejściowego” w długoterminowy zasób

Slajd z prezentacji Qoder ujmuje to wprost:

Model power is a commodity. Context is the asset.

Zdanie to odzwierciedla oczywiście perspektywę dostawcy, ale trafia w realny problem: im większa moc modelu i im niższy koszt jego pozyskania, tym bardziej o zdolność agenta (Agent) do długofalowej, niezawodnej pracy decyduje to, „co tak naprawdę wie”.

W dojrzałym projekcie programistycznym mamy ograniczenia architektoniczne, historyczne decyzje, zależności między modułami, standardy kodowania, błędy już napotkane oraz rejestry wdrożeń. W przedsiębiorstwie — struktury organizacyjne, uprawnienia, procedury operacyjne (SOP), dokumentację, czaty grupowe, reguły biznesowe i statusy klientów. W marce — informacje o produktach, wytyczne wizualne, historyczne materiały, dane z kampanii i ograniczenia kanałów sprzedaży.

Tego rodzaju informacje nie pojawiają się automatycznie po wymianie modelu na mocniejszy.

Dlatego Qoder tworzy Wiki repozytorium kodu (Repo Wiki), pamięć (Memory) i karty wiedzy (Knowledge Cards), QwenWork kładzie nacisk na kontekst biznesowy (Enterprise Context), a OpenSearch — na pamięć długoterminową, pamięć zadań i kompresję kontekstu. Wszystkie te narzędzia próbują rozwiązać ten sam problem: żeby agent nie musiał za każdym razem zaczynać rozumienia świata od zera.

To jednocześnie oznacza, że wiele zespołów przez lata gromadziło biblioteki promptów (Prompt Library), których długoterminowa wartość prawdopodobnie nie jest tak wysoka, jak się wydawało. Prompt jest raczej sposobem wywołania pojedynczego zadania — tym, co naprawdę procentuje z biegiem czasu, jest kontekst biznesowy, historia decyzji, wyniki walidacji, przyczyny porażek i możliwe do ponownego użycia umiejętności.

Cztery. Jednostka konkurencji w produktach AI przesuwa się z „pojedynczej funkcji” na „kompletny przepływ pracy”

WonderClip zrobił na mnie szczególnie wyraźne wrażenie.

Jeśli patrzeć tylko na listę możliwości, wiele z nich nie jest niczym nowym: generowanie obrazów, generowanie wideo, tłumaczenie, dubbing, podmiana materiałów, produkcja wsadowa. Wyciągnięte pojedynczo, każda z tych funkcji łatwo może zostać stopniowo przejęta przez dostawców modeli, oprogramowanie do montażu wideo czy inne platformy SaaS.

Ale struktura produktu pokazana na żywoły zmierza już w stronę bardziej kompletnego systemu produkcyjnego:

Prześślij skrypt → Przejrzyj podział → Przygotuj zasoby → Generuj hurtowo

Dalej dochodzą Storyboard, Canvas, niestandardowe umiejętności, współdzielone zasoby, współpraca zespołowa i zarządzanie wersjami. Produkt wstawia „generowanie” z powrotem w środek procesu.

To bezpośrednio podsuwa pewną myśl przy budowaniu aplikacji AI.

Jeśli rdzeniem produktu nadal pozostaje „wgraj coś, niech AI to obrobi, pobierz wynik”, przy kolejnej aktualizacji modelu jego wartość łatwo da się zmarginalizować. Znacznie stabilniejszy kierunek to przejęcie całego zadania, które użytkownik i tak musi wykonać.

Weźmy scenariusz treści e‑commerce: osobne podmienianie towaru, zmiana tła, tłumaczenie czy lektor — to wszystko brzmi bardzo płytko. Warstwę wyżej obiektem produktu powinny stopniowo stać się marka (Brand), pojedynczy produkt (SKU), kampania (Campaign), rynek (Market), strategia kreatywna (Creative Strategy), warianty kreacji (Variants), kanały dystrybucji (Distribution) i wyniki kampanii (Performance). Generowanie jest tylko egzekutorem — prawdziwa wartość płynie z całego Creative Operations Workflow.

V. Agenty (Agent) przechodzą od „odpowiadania na pytania” do „realizowania zadań”

Słuchając dziś prezentacji o wyszukiwaniu agentowym w ramach Alibaba Cloud OpenSearch, natknąłem się na diagram ewolucji, który wyjątkowo trafnie oddaje zachodzące zmiany.

Klasyczne wyszukiwanie sprowadzało się do pary: zapytanie (Query) → lista wyników (Results). Generatywna AI przesunęła ten paradygmat do postaci: pytanie (Question) → odpowiedź (Answer). Wyszukiwanie agentowe (agentic search) idzie o krok dalej — redefiniuje cel jako: cel (Goal) → działanie (Action).

To oznacza, że samo wyszukiwanie zostaje na nowo zdefiniowane.

W przyszłości agent badawczy (Research Agent) będzie mógł automatycznie dekomponować złożone pytania, tworzyć plan zapytań, odpytywać wiele źródeł, uzupełniać iteracyjnie wyszukiwanie (retrieval), dokonywać weryfikacji krzyżowej, formułować wnioski pośrednie, a następnie sięgać po kolejne narzędzia, by kontynuować realizację zadania. Interfejsy wyszukiwania (API) coraz bardziej przypominają infrastrukturę, za pośrednictwem której agenci pozyskują kontekst zewnętrzny.

Zmienia to także sposób, w jaki obserwujemy SEO (Search Engine Optimization) i GEO (Generative Engine Optimization). Dotąd kluczowe były: wyświetlenia (Impressions), kliknięcia (Clicks), pozycja w rankingu (Ranking). Teraz do obserwowanych metryk trzeba będzie dodać widoczność w AI (AI Visibility), cytowania (Citations), wzmianki (Mentions) i ruch napływający z AI (AI Referral) — a także sprawdzać, czy ten ruch ostatecznie prowadzi do rejestracji (Signup), konwersji płatnej (Paid) i utrzymania użytkownika (Retention).

Wyszukiwanie nie znika — zaczyna być wbudowywane w coraz większe, zamknięte pętle zadaniowe.

Sześć. Prawdziwa bariera enterprise AI zaczyna się od organizacji

Na konferencji wiele mówiono o technicznych aspektach AI w przedsiębiorstwach — danych, uprawnieniach, bezpieczeństwie, governance, dostępie do modeli, architekturze chmury i platformach Agent.

To wszystko jest istotne. Po zapoznaniu się jednak z kilkoma przypadkami korporacyjnymi bardziej nurtuje mnie inne pytanie:

Kto tak naprawdę ma motywację, żeby z tego korzystać?

Wyobraźmy sobie pracownika, który dzięki AI mieści swoją ośmiogodzinną pracę w pięciu godzinach. Dokąd trafiają odzyskane trzy godziny? Jeśli jedyną odpowiedzią jest „dostanie kolejnych zadań”, jego motywacja do aktywnego forsowania AI będzie prawdopodobnie ograniczona.

Inny przykład: jeśli KPI zespołu AI to liczba wdrożonych Agentów i liczba wywołań, zespół ten ma bodziec, by nieustannie dorzucać kolejne funkcje. Zespół biznesowy ponosi koszty przebudowy procesów, zespół IT i bezpieczeństwa — ryzyko błędów, a końcowego wzrostu przychodów nie sposób nikomu jednoznacznie przypisać. W takiej strukturze organizacyjnej, nawet gdy technologia jest gotowa, samo wdrożenie postępuje powoli.

Enterprise AI nie sprowadza się do architektury (Architecture) — prawdziwą barierą jest projektowanie zachęt (Incentive Design).

Problem natury technicznej rozwiążesz za pieniądze. Problem organizacyjny — już nie zawsze. Każdy projekt wymaga odpowiedzi na co najmniej sześć pytań: kto pełni jaką rolę (Role), jakim wskaźnikiem (KPI) jest mierzony, jaki przynosi zysk (Benefit), ile kosztuje (Cost), jakie niesie ryzyko (Risk) i komu przysługuje prawo decyzji (Decision Right). Kto czerpie zysk, ten dźwiga ryzyko. Kto decyduje, ten odpowiada za efekt.

Większość tak zwanych „problemów z wdrażaniem AI” to w istocie problemy z projektowaniem organizacji.

VII. Najbardziej mylące bywają te wskaźniki, które na pierwszy rzut oka wydają się najprostsze

Jeden ze slajdów w prezentacji Qoder mocno zapadł mi w pamięć:

Generation rate is a vanity metric.

Prelegent zestawił udział kodu generowanego przez AI na poszczególnych etapach procesu, równocześnie podkreślając, że cykl dostarczania oprogramowania (Delivery Cycle) nie skrócił się w tej samej proporcji. Konkretne liczby pochodzą z materiałów konkretnego dostawcy i nie mogą służyć jako branżowy benchmark — ale stojąca za nimi logika jest trafna.

Gdy AI obniży koszt samego kodowania (Coding), wąskie gardło przesunie się w stronę wymagań (Requirement), kontekstu (Context), architektury (Architecture), przeglądu (Review), testów (Test), integracji (Integration), wdrożenia (Deployment) i odbioru (Validation).

Dlatego wskaźniki takie jak tempo generowania kodu, liczba tokenów, liczba agentów AI, liczba wywołań czy wolumen wygenerowanych obrazów mogą stać się lokalnymi miarami efektywności. Naprawdę istotne są jednak rezultaty end-to-end: czy skrócił się czas dostarczenia (Lead Time), czy zmalała liczba roboczogodzin (Human Minutes), czy wzrósł wskaźnik akceptacji za pierwszym razem (First-pass Acceptance Rate), czy spadł koszt przypadający na zaakceptowane zadanie (Cost per Accepted Task) i czy zmieniły się docelowe wskaźniki biznesowe.

Tegoroczna konferencja uświadomiła mi jedno: nie dajmy się zwariować pytaniem „ile zrobiło AI” — liczy się to, „co w efekcie zmieniło się w całym systemie”.

8. Konferencja podpowiada kierunki, ale decyzje i tak zostają po naszej stronie

Najczęstsza pułapka konferencji: pozwalamy światu zewnętrznemu decydować za nas o priorytetach.

Gdy o jakimś kierunku dużo mówi się ze sceny, mamy ochotę go zbadać; gdy jakiś technologiczny gigant mocno w niego inwestuje, czujemy, że warto podążyć jego śladem; gdy jakiś produkt wygląda nowocześnie, dochodzimy do wniosku, że sami też powinniśmy coś takiego zbudować.

Tym razem chcę sprowadzić wszystkie te informacje do jednego, prostszego pytania:

Jaką moją decyzję zmienia ta informacja?

Jeśli po niej czuję tylko „fajne” – to nadal zwykły input.

Jeśli każe mi na nowo przeliczyć opcje build / buy / ignore, przesunąć granice produktu, zatrzymać niskowartościową inwestycję, przeprojektować obieg pracy albo przedefiniować metrykę eksperymentu — dopiero wtedy naprawdę wchodzi do mojej decyzji.

Konferencja Apsara nie jest odpowiedzią.

To bardziej mapa zakładów branży. Mapa pokazuje, dokąd zmierzają inni, które szlaki zaczynają się zatłaczać, jaka infrastruktura się kształtuje, jakie problemy zaczynają trafiać do masowej produkcji.

Ostateczna trasa i tak wraca do naszych własnych celów, ograniczeń, zasobów i dowodów.

To jest też to, co chcę dziś wynosić z konferencji technologicznych: widzieć więcej zakładów, ale decyzję zostawiać sobie.

Jeśli zastanawiasz się, od czego zacząć AI w przedsiębiorstwie, w które kierunki warto zainwestować, a które z nich to bańka napędzana narracją — porozmawiajmy. Prowadzimy specjalistyczne doradztwo w obszarze transformacji AI w firmach: od wyboru technologii, przez projektowanie organizacji, aż po systemy pomiaru efektów. Pomagamy przełożyć „konferencyjny szum” na „własną, świadomą decyzję”. Kontakt: [email protected].

Dalsza lektura: „Siedmiostopniowy framework transformacji AI” — systematyczny opis pełnej ścieżki wdrożenia AI w przedsiębiorstwie.

O tej serii

Yunqi – Obserwacje (云栖观察) to cykl obserwacji terenowych prowadzony przez IAIUSE. Punktem wyjścia jest konferencja Yunqi 2026; patrzymy oczami badacza na realne zmiany zachodzące w branży AI – bez podążania za medialnym szumem, za to z uwagą na kierunki, w które rynek faktycznie lokuje środki, oraz na jakość dowodów, które za tymi decyzjami stoją.

Seria obejmuje około 10 tekstów: o warstwie systemowej ponad modelami, wdrażaniu Agentów, aktywach kontekstowych (Context assets), projektowaniu struktur AI w przedsiębiorstwach oraz przesuwaniu się osi konkurencji w produktach AI.

Mam niemal 8 lat doświadczenia w doradztwie dla dużych przedsiębiorstw i w analizie biznesowej. Pracowałem w IBM, prowadząc projekty dla sektora telekomunikacyjnego, finansowego, ubezpieczeniowego i produkcyjnego. Następnie kontynuowałem pracę na pierwszej linii – przy produktach operatorskich, internetowych oraz aplikacjach AI – zajmując się analizą wymagań, projektowaniem produktów i wdrożeniami międzyzespołowymi. Oceny formułowane w tej serii wynikają z moich obserwacji terenowych oraz krzyżowej weryfikacji branżowej. Prezentuję w nich wyraźne stanowisko autorskie i nie reprezentuję poglądów żadnego dostawcy.