Jaką rolę pełni Solution Architect w projektach AI? – rozmowa z Łukaszem Boruniem

Wprowadzenie i zakres pracy

Opowiedz proszę o sobie – jak trafiłeś do roli Solution Architecta

Architektura Rozwiązań to odpowiedź na moje pytanie, co dalej po programowaniu. W IT pracuję od prawie 25 lat. Blisko od 18 lat jestem czynnym programistą backendowym, a mam także kilkuletnie doświadczenie w programowaniu gier komputerowych.

Jeszcze przed pandemią COVID-19, czyli prawie pięć lat temu, mocno zastanawiałem się nad dalszą ścieżką kariery. Nie podobało mi się to, że kierunek współczesnego programowania obiera ścieżkę, w której dostęp do coraz to „lepszych” frameworków i rozwiązań ustępował jakości na rzecz prędkości pisania. Ciężko było nadążyć za nowościami, które z każdej strony starały się być lepsze od swoich rywali czy poprzedników. To tylko moje prywatne odczucie, bardzo możliwe, że po tylu latach i przeróżnych technologiach programowanie mi się po prostu powoli zaczęło nudzić.

Nigdy nie traktowałem technologii jako specjalizacji, dla mnie kod był tylko narzędziem, które służyło mi podczas mojej codziennej pracy. Game Dev, Backend, Frontend, Embedded? Dla mnie to tylko domeny, które musiałem lepiej poznać. Logiczne myślenie i pisanie kodu, dla każdej z tych domen jest praktycznie takie same.

Niemniej na przestrzeni czasu powstawało bardzo wiele pytań odnośnie tego — co dalej? Ponieważ wykazywałem niemałe umiejętności liderskie i biznesowe, czyli miękkie cechy, to postanowiłem, że poświęcę na ich rozwój więcej czasu kosztem rozwoju technicznego. Dla mnie to był strzał w dziesiątkę, nie dość, że czułem po tylu latach pracy bodziec do rozwoju, to także mogłem te umiejętności mocniej testować w pracy podczas współpracy z zespołami technicznymi, biznesowymi i sprzedażowymi. Nawet wymyśliłem nazwę do takiego całościowego rozwoju — Holistyczny Programista. Wspomniana wcześniej pandemia czy recesja na rynku IT, która trwa od dwóch lat, udowodniła mi także, jak bardzo taki rozwój pomaga w utrzymaniu kariery i pracy. Czułem się znacznie bezpieczniejszy wiedząc, że firma może na mnie liczyć w różnych obszarach swojej działalności.

Kiedy GPT-3.5 stał się dostępny dla całego świata, szybko staraliśmy się tak zorganizować, aby sprawdzić jego potencjał w biznesie. Ponieważ wokół niego było tak wiele pytań i brak odpowiedzi, a rynek reagował mocno dynamicznie, w Miquido uznaliśmy, że rola osoby, która dobrze zna podejście biznesowe, odnajduje się w sprzedaży, ale także jest doświadczonym inżynierem oprogramowania, byłaby znacząca w budowaniu mostów pomiędzy biznesem a technologią. A Solution Architect właśnie takie mosty buduje.

Jaką rolę pełni Solution Architect w projektach AI? Jak wygląda Twój typowy dzień pracy?

Różnica pomiędzy Solution Architectem a Software Architectem jest taka, że ten drugi większą część swojej pracy poświęca zagadnieniom technicznym i często też uczestniczy w powstawaniu aplikacji. Natomiast Solution Architect znaczącą część czasu poświęca na biznes, zrozumienie klienta i budowanie relacji (mostu) pomiędzy biznesem a technologią.

Zaraz po tym, jak dział sprzedaży przyprowadzi klienta, spotykam się z nim i przeprowadzam rozmowę na temat problemu, który będziemy chcieli rozwiązać. Z mojej perspektywy jest ważne, aby wybadać, czy dany problem w ogóle wymaga rozwiązań AI, czy nie można tego zrobić poprzez budowanie aplikacji w tradycyjny sposób. Tutaj właśnie mocno przydaje się moja wiedza techniczna z wielu domen. To czas, w którym staram się budować relacje z klientem poprzez zadawanie odpowiednich pytań, które z punktu widzenia biznesu są ważne, aby ostatecznie przekuć wymagania na konkretną pracę. W tym przypadku wykorzystuję warsztat umiejętności miękkich. Ostatecznie, jeżeli rozwiązanie wiele zyska poprzez rozwiązania GenAI, to przekazuję wiedzę biznesową na wiedzę techniczną, tak aby racjonalnie taki projekt wycenić i później go zrealizować. To jest właśnie ten most, który w całym procesie jest najważniejszy. To, jak trwały będzie jego fundament, będzie rzutować na całość relacji pomiędzy biznesem a technologią.

W Miquido pełnię też rolę Team Leadera dla całego działu AI. Ponieważ od co najmniej dwóch lat staram się prowadzić zespoły, czerpiąc przy tym z przywództwa służebnego (Servant Leadership), to nie wtrącam się w procesy realizacji technicznej. Dbam o to, aby komunikacja i bieżący feedback były codziennym elementem naszej pracy.

Technologie i projektowanie rozwiązań

Jakie kryteria bierzesz pod uwagę, dobierając technologię i do konkretnego projektu AI?

Najważniejsze to zrozumieć problem, który AI ma rozwiązać. Najpierw odpowiadam sobie na pytanie, czy AI w ogóle w tym przypadku rozwiązuje go w taki sposób, w jaki nie poradzi sobie tradycyjne programowanie. Jeżeli tak, to konsultuję z zespołem technologicznym, jak do omawianego problemu podchodzimy.

Zdarza się, że sam stack technologiczny jest z góry ustalony przez klienta. Najczęściej tak się dzieje z wyborem dużych modeli językowych. Klienci są przyzwyczajeni do ChatGPT, dlatego w pierwszej kolejności chcą właśnie z modeli GPT skorzystać. Zdarza się też, że klienci posiadają darmowe kredyty na usługi chmurowe, z których chcą skorzystać.

Wybór modelu to kwestia doświadczenia i naszej znajomości rynku. W Miquido nastawiamy się mocno na samorozwój i dzielimy się wiedzą. Dlatego każdy problem indywidualnie rozpatrujemy. Widzimy, że przy analizie dokumentów prawnych najlepiej radzi sobie GPT-4, natomiast Claude 3.5 Sonnet generuje tekst naturalniej od konkurencji. W przypadku skomplikowanych procesów korzystamy z rad naszych Prompt Engineers. Jest to proces, który kilkukrotnie zachodzi podczas rozwiązywania problemu. W znacznej części naszych wdrożeń nie ograniczamy się tylko do jednego modelu.

Jeżeli chodzi o bazy wektorowe, to opieramy wdrożenia o QDranta. Jednak ciągle spoglądamy w stronę Weaviate. Ten temat nie jest u nas jeszcze domknięty, toteż podchodzimy do tej decyzji indywidualnie.

W jaki sposób zapewniasz, że projektowane rozwiązania AI są skalowalne i łatwe do integracji z istniejącymi systemami?

erwisy, które oparte są o AI, to przede wszystkim backendy, które są mocno zintegrowane z usługami trzecimi. W tym przypadku z modelami do obsługi AI. W Miquido nasz zespół DevOps jest mocno doświadczony w usługach chmurowych, takich jak AWS, GCP czy Azure.

W przypadku AWS mamy utworzone szablony, które stawiają nam takie środowiska w kilka minut. Każde z tych środowisk oparte jest o usługi Elastic Container Service (ECS), które zarządzają serwisami w swoim klastrze. Do pełnej skalowalności wykorzystujemy LoadBalancer oparty o podstawowe metryki CPU/RAM, a także o te bardziej zaawansowane, jak na przykład czas odpowiedzi z baz wektorowych czy SQL.

Od strony LLM jesteśmy bardziej uzależnieni od dostawców modeli, ale nasze rozwiązania oparte są o modele w trybie tak zwanego Fallback. Czyli zapasowy model, który zostaje wykorzystany, jeśli poprzedni nie odpowiada lub czasy jego odpowiedzi są zbyt długie. Ten mechanizm jest sercem naszej biblioteki Open Source do konsumpcji dużych modeli językowych — drAIve.

Wyzwania w pracy Solution Architecta

Jakie wyzwania napotykasz podczas projektowania systemów AI, szczególnie w fazie ich integracji z istniejącymi infrastrukturami IT?

Dużo czasu poświęcam na edukację swoich klientów. Dzisiaj modele Generatywnej Sztucznej Inteligencji są bardzo gorącą technologią. Część klientów po prostu uważa, że to recepta na rozwiązania, które wcześniej były niemożliwe do osiągnięcia lub zbyt drogie, aby w nie zainwestować.

Niestety tak nie jest.

Wspomnę po raz kolejny, że bardzo dokładnie weryfikuję, czy w ogóle AI powinno rozwiązać omawiany problem, dopiero potem przechodzę do konkretów. Nie powinniśmy rozwiązywać problemów programistycznych przy użyciu AI, gdy dobrze napisany algorytm poradziłby sobie bez problemu.

Zdarzają się także dokumenty, które są generowane przez modele LLM. To niestety widać. Gdy ktoś pisze artykuły i używa AI do wygenerowania pełnych treści, generyczność jest bardzo widoczna. Pomimo że dokumenty są obszerne, to przez ich prostotę nie wyczerpują tematu, przez co potrzebne są kolejne spotkania, które mają na celu doprecyzowanie projektu, aby umożliwiał on poprawną wycenę.

Najbardziej jednak jestem uczulony na bezpieczeństwo. Szczególnie w przypadku, gdy dajemy ludziom dostęp do interfejsu, w którym mogą wrzucić, co im się podoba. Myślę, że dawno już nowa technologia nie była tak otwarta na ataki. Największym niebezpieczeństwem jest człowiek. Nigdy nie będziemy w stanie przewidzieć w 100% tego, czym nas on zaskoczy. A powiedzmy sobie szczerze, wszystkie obecne znane ataki na duże modele językowe na pewno nie wyczerpały swojego potencjału.

Więcej o bezpieczeństwie pisałem w swoim Newsletterze oraz opowiadałem podczas webinaru AI Waves #10.

Czy widzisz konkretne ograniczenia obecnych modeli generatywnych lub innych rozwiązań AI, które utrudniają pracę Solution Architecta?

GenAI to maszyna losująca, trzeba o tym pamiętać. Nie możemy wciskać jej w każde miejsce jako dodatkowy klocek do dużych procesów. To kluczowe, aby zachować ostrożność i rozwagę przy jej implementacji. Żyjemy w okresie, w którym informacje o nowych modelach, nowych funkcjonalnościach i zastosowaniach podaje się nam codziennie na tacy. Tempo rozwoju tej technologii jest oszałamiające. Coraz ciężej to zweryfikować, a musimy być na bieżąco na ten temat. Śledzenie wszystkich nowości staje się prawdziwym wyzwaniem. Ten chaos powoduje, że oddalamy się od jakiejkolwiek standaryzacji, jeżeli chodzi o wdrożenia serwisów z udziałem AI. Brak jednolitych standardów może prowadzić do wielu problemów w przyszłości.

Jedni powiedzą, że to dobrze, bo różnorodność jest potrzebna, a ja uważam, że ta różnorodność pokaże swoje rogi w odpowiednim czasie. Choć różnorodność może sprzyjać innowacjom, w kontekście AI niesie ze sobą pewne ryzyko. W nastawieniu na bezpieczeństwo, etyczność i poufność danych różnorodność nie jest drogą, która powinna być uwzględniana w drodze do uzyskania jakiejkolwiek normy, która świadczyłaby o jakości wdrożeń rozwiązań AI.

Jak radzisz sobie z balansowaniem wymagań biznesowych, technicznych i etycznych w projektach AI?

W przypadku biznesu i technologii pomaga mi tutaj moje dotychczasowe doświadczenie. Wiem, kiedy mogę wziąć na siebie obszary techniczne, a kiedy przekazać je moim specjalistom. W przypadku biznesu staram się ograniczać sprawy związane na ogół z finansami. Wolę skupić się na budowaniu relacji z klientem i poznania szczegółowo jego pomysłu, aby w jego oczach stać się partnerem biznesowym.

Etyka w kontekście GenAI jest bardzo obszernym zagadnieniem. W Miquido mamy zasady doboru projektów, Jedną z nich jest odrzucanie projektów, które mają znamiona przestępczości, korupcji czy elementami, które dyskryminują inne osoby. Jeżeli pytasz mnie jednak, o sytuację, w której dane rozwiązanie oparte o AI, może spowodować utratę pracy osób trzecich, to w takiej sytuacji nie ingeruje w biznes.

Rozwój technologiczny jest nieunikniony. Technologie na przestrzeni czasu zabierały ludziom pracę, jednak każda z takich rewolucji technologicznych tworzyła jeszcze więcej nowych miejsc pracy, do obsługi danej technologii. To się działo niejednokrotnie. Więcej na ten temat pisałem w swoim artykule:
https://mychaoticcoherence.substack.com/p/ais-ancient-echo-why-todays-tech

Strategia i przyszłość rozwiązań AI

Jakie technologie lub podejścia uważasz za kluczowe w przyszłości rozwoju AI?

Dzisiaj jesteśmy świadkiem wyścigu pomiędzy dużymi graczami, którzy starają się prześcignąć w różnych obszarach generatywnej sztucznej inteligencji. Jedni starają się tworzyć odpowiedniki modeli z jak największym kontekstem. Drudzy koncentrują się na generowaniu kontentu multimedialnego. A jeszcze inni starają się pracować nad modelami w taki sposób, aby na swój ograniczony sposób się dostosowywały do naszego “charakteru”.

Ciężko powiedzieć, które obszary są dzisiaj ważniejsze. Według mnie przyszłość będzie należała do modeli, które będą trenowane do odpowiadania na pytania z konkretnych dziedzin. Na pewno, jeżeli chodzi o ich zastosowanie w branżach wysokiego ryzyka jak medycyna, prawo czy sądownictwo.

Na pewno pojawi się coraz najwięcej narzędzi do weryfikacji kontentu wytworzonego przez AI. To dzisiaj plaga, nie dość, że od dłuższego czasu jesteśmy bombardowaniu clickbaitowymi treściami w internecie, które mało wnoszą, to aktualnie tych treści dzięki AI jest teraz kilkakrotnie set razy więcej. Ich weryfikacja zabiera sporo czasu, Czasu, którego już nikt nam już nie odda.

Marzy mi się model, który wyciągnie z danej książki to, co dla mnie najistotniejsze. Jako osoba neuroatypowa zupełnie inaczej podchodzę do tego, co wyciągam z książek. Dlatego generatywne podejście najczęściej się tutaj nie sprawdza. A ponieważ jestem osobą, która bardzo dużo czyta, to dochodzę do wniosku, że w większości przypadku istotna dla mnie jest treść, która stanowi 25% całej książki. Byłoby super, móc tak mocno oszczędzać czas.

Jak widzisz rolę AI w transformacji biznesowej? Czy masz konkretne przykłady projektów, które znacząco wpłynęły na organizację?

Największym sukcesem cieszą się projekty, które dzięki AI faktycznie usprawniają procesy odczuwalne dla osoby końcowej. Wspominałem już, że nie każde rozwiązanie wymaga AI, prawda? Będę to powtarzał jak mantrę.

Procesy tzw. onboardingowe, czyli takie, które pojawiają się na etapie rejestracji lub post rejestracji, są najczęściej powodem, dla którego klienci nie kończą ich. Popatrzmy na to w ten sposób: gdy mamy do wypełnienia jedno pole, to najpewniej to zrobimy. Trzy? Pewnie też. Jednak gdy jest ich więcej niż 5, to praktycznie nam się nie chce, a gdy jest ich jeszcze więcej, to wytrwają tylko ci, którzy faktycznie widzą sens wykorzystania danego rozwiązania. Ci niepewni (a zarazem największa grupa) jednak proces porzucą.

Dla zobrazowania przykładu weźmy portale, które oferują znalezienie pracy. Na samą myśl o przepisywaniu swojego CV na ich format mam gęsią skórkę. A AI sobie świetnie z tym da radę. Wystarczy poprosić o PDF, zamiast zastanawiać się, jak wymusić na kliencie końcowym, aby został do końca i wypełnił wszystko w 30 minut…

Innym przykładem jest szybsza dostępność do baz wiedzy przedsiębiorstw, która w znaczący sposób skraca czas uzyskiwania odpowiedzi na wciąż te same pytania. Jest to ważne nie tylko dla osoby pytającej, ale także dla tych osób, które w pierwszej kolejności musiały zawsze na te pytania odpowiadać. Mamy też przeprowadzone z sukcesem wdrożenia prowadzenia supportu przez AI jako pierwsza linia wsparcia.

Odpowiadając na zadane pytanie: Tak. Serwisy AI, które rozwiązują realne problemy, znacząco wpływają na transformację biznesową.

Etyka i społeczna odpowiedzialność

Jakie znaczenie mają kwestie etyczne w projektowaniu systemów AI? Czy musiałeś wprowadzać dodatkowe zabezpieczenia lub rozwiązania w tym zakresie? Możesz opisać strategię, jakie stosujesz, by je uniknąć?

Wspomniałem wcześniej o tym, że najbardziej problematycznym dla mnie scenariuszem są rozwiązania z otwartym inputem, np. chatboty. Nie możemy mieć pewności, że konsumowanie zapytania odbędzie się w sposób, w jaki tworzyliśmy cały serwis AI. Wypracowaliśmy sobie proces, który mocno wspomaga nas w obronie przeciw takim nadużyciom.

Przede wszystkim, tzw. guardrails, czyli zestawy reguł, które analizują treść zarówno wejścia (do modelu), jak i wyjścia (z modelu). Dlaczego analizujemy także wyjście? Ponieważ nie jesteśmy nigdy pewni samej odpowiedzi (a to wynika z natury dużych modeli językowych), a scenariusz, w którym wejście było poprawnie zweryfikowane, ale wyjście daje nie akceptowalne wyniki, jest nadal bardzo aktualny. W tym przypadku dzieje się to w czasie rzeczywistym.

Drugie podejście to tworzenie setek scenariuszy, które zawierają zarówno kontent odpowiedni, jak i takie scenariusze, które w sposób jawny atakują wejście. Takie scenariusze tworzone są także przy użyciu AI, a dzięki bibliotece drAIve implementacja ich jest banalnie prosta. Na tym etapie możemy sprawdzać słowa kluczowe, analizować sentyment czy po prostu analizować całe treści w celu wygenerowania ogólnej punktacji, która posłuży nam do oceny całego procesu. Ten proces jest częścią testów wewnętrznych. Dlatego musi przejść pozytywnie, zanim dana zmiana trafi na produkcję.

Rady dla innych

Jakie wskazówki dałbyś młodym inżynierom, którzy chcą zostać Solution Architectami w dziedzinie AI? Od czego powinni zacząć swoją ścieżkę rozwoju?

Najważniejszą radą jest to, aby uświadomić sobie, jak ważne są umiejętności miękkie. Jako programiści często o tym zapominamy. Dzieje się to też mocno z winy samych procesów pracy w przedsiębiorstwach, które nastawiają nas (juniorów/regularów) na to, aby jak najbardziej pracować nad warsztatem technicznym.

Uważam, że proces pozyskiwania umiejętności miękkich powinien być wprost proporcjonalny do naszego doświadczenia i stażu. To także świetny sposób na to, aby w razie czego mieć możliwości rozwoju w kierunku ścieżek alternatywnych, gdzie technologia nie jest głównym atutem.

Brak rozwoju w kierunku miękkich umiejętności czasem powoduje paradoks. Najczęściej osoba z wieloletnim seniorskim czy tech leadowym doświadczeniem zaczyna odczuwać chęć rozwoju w inną stronę. Firma jej na to pozwala, ponieważ zależy jej na doświadczeniu tej osoby. Niestety z punktu widzenia firmy kończy się to w ten sposób, że firma zyskuje kiepskiego menedżera, a traci świetnego programistę. A w przypadku programisty pogłębia się uczucie stania w miejscu.

Rozwój programistów jest dla mnie bardzo ważny w codziennej pracy jako ich lider. W międzyczasie pracuję nad sposobem przekucia swojej wiedzy w „coś”, co pomoże programistom rozwijać się całościowo. Holistyczny Programista właśnie temu ma służyć.

Jakich umiejętności technicznych i miękkich wymaga praca Solution Architecta AI? Co jest kluczowe w tym zawodzie?

Najważniejsze to być otwartym i szczerym w rozmowie z klientem o jego projekcie. I mówię to otwarcie jako osoba introwertyczna. Umiejętność zadawania odpowiednich pytań, które pomogą bardziej otworzyć nam głowę na czytelność projektu, jest równie istotna.

Rola Solution Architecta delikatnie zahacza o elementy sprzedażowe. Mam tutaj na myśli, że zarówno Sales, jak i SA czerpią z tego samego worka, jeżeli chodzi o umiejętności interpersonalne. Często biorę niewygodne pytania na siebie i muszę szczerze odpowiedzieć w takiej formie, aby nikogo nie obrazić i nie zaprzeczyć stawianym wcześniej tezom. Warto wspomnieć, choć powinno być to wiadome, że nie warto kłamać. Jeżeli to robimy, aby przechylić lekko pałeczkę na swoją stronę, to prędzej czy później będzie to podstawą do utraty całego zaufania, na jakie sobie z klientem czy zespołem zapracowaliśmy.

Uważam też, że ta rola wcale nie wymaga wieloletniego doświadczenia w pracy jako programista. Wystarczy, że mamy wieloletnie doświadczenie, które jest zawsze blisko technologii. Dobrze jest poznać programistów od „tej” strony, aby umieć z nimi dojść do porozumienia.

Niemniej ważne jest także, aby mieć otwartą głowę odnośnie nowości i innowacyjności. Jak wspomniałem wcześniej, dzień w dzień jesteśmy zalewani coraz nowszymi informacjami na temat rozwiązań AI.

Dla mnie dużym problemem na początku była koncentracja na rzeczach ważnych. Bardzo szybko zahaczyłem o stronę techniczną, która na etapie pierwszych spotkań nie ma znaczenia. Na szczęście pracuję ze świetnymi ludźmi i w Miquido tego typu rzeczy zgłaszamy sobie na bieżąco. To także bardzo pomaga w rozwoju.