025: Automatyzacja e-commerce z AI - hit czy kit?

Postaram się tutaj nakreślić trochę ten kontekst i pokazać czy faktycznie korzystanie z AI ma sens, jeśli ma to kiedy, jeśli nie to dlaczego i co z tym w praktyce można zrobić. Pierwsza sprawa, która jest bardzo ważna to taka, że jak myślimy o LLM-ach, bo o nich będziemy dzisiaj mówić, bo jakby tutaj już, żeby być też precyzyjnym, generalnie sztuczna inteligencja to nie są tylko te rozwiązania, o których teraz słyszymy na co dzień, typu chat GPT, typu te sieci właśnie LLM, tak zwane Large Language Models. To jest cały szereg różnych innych rozwiązań związanych z obszaru uczenia maszynowego czy jakiegoś rozumowania logicznego.

Tych rzeczy dzisiaj nie będę poruszał, no bo tym najbardziej hype'owym obecnie tematem są LLM, czyli te rozwiązania, które są obecnie dostępne i które pozwalają nam zarówno wspomagać nas w researchu, wspomagać nas jakby w rozwiązywaniu różnego rodzaju Również wspomagają nas w tworzeniu kodu. I tu nie ma co się czarować. Wykorzystanie czy pojawienie się tych rozwiązań typu Cloud Code, Codex, Cursor i innych, bez wątpienia sprawiły, że ten dostęp do kodu jest dużo łatwiejszy niż kiedykolwiek. Czyli nastąpiła taka demokratyzacja trochę tego kodu. Więc nie dziwne, że pierwsze co przychodzi do głowy osobom, które prowadzą e-commerce czy prowadzą swoje firmy, no to czy nie da się tego wykorzystać do tego, żeby zastąpić jeden z większych kosztów w rozwoju firmy ostatnich lat, czyli oprogramowanie.

I jeśli spojrzymy na to w ten sposób, to przede wszystkim dobrym pomysłem jest myślenie o takim LLM-ie jako takim programiście ze średnim poziomem doświadczenia, tak bym powiedział. Czyli co do zasady jest to narzędzie, które faktycznie wytwarza nam kod, Całkiem dobrej jakości, jeśli zostanie dobrze pokierowany, ale o tym zaraz powiemy. Natomiast wciąż to jest ten poziom junior-mid, czyli poziom taki, gdzie my musimy poinstruować jednak ten model, jak on pewne rozwiązania ma realizować, nadać mu kontekst, w szczególności kontekst biznesowy, żeby on po prostu wiedział, co ma wytworzyć.

Bo pamiętajmy, że te modele uczyły się na pewnych dużych zbiorach danych, no ale głównie opierając się, szczególnie te wytwarzające kod, na kodzie. W związku z tym te rozwiązania techniczne, architektoniczne są rzeczami, które LLM-y potrafią rozwiązywać całkiem dobrze. Natomiast w kontekście biznesowym one też są w stanie nam pomóc. Wszelkie prawa zastrzeżone.

www.endora.com.pl Jak będziemy wziąć to pod uwagę, to wydawanie poleceń LLM-owi będzie dużo prostsze. Pomyślimy sobie, że przed nami siedzi jakiś programista, którym musimy przekazać tę wiedzę. I to, co jest ważne, to nie jest programista,

Names mentioned in English. My oczywiście wiemy, jak to wszystko funkcjonuje, po prostu w tym siedzimy i przez to paradoksalnie zapominamy bardzo często o tym, żeby przekazać komuś te informacje. Więc efekt na koniec dnia jest taki, że ten biedny LLN tworzy coś w ograniczonym kontekście, no bo po prostu nie rozumie twojego biznesu. No i na koniec dnia to rozwiązanie jest takie, że trzeba go później poprawiać.

I to prowadzi do tego drugiego Wniosku, który bym wysnuł na bazie tej całej historii z LLM-ami. Pierwszy, traktujmy tego LLM-a jako takiego właśnie mida, takiego po prostu średnio rozgarniętego programistę, o tak powiedzmy. To prowadzi z kolei do drugiego wniosku, to znaczy, że powinniśmy, najlepiej tak by było, żeby mieć osobę, która jest takim specjalistą, konsultantem, osobą, która rozumie zarówno tę część biznesową, jak i technologiczną, czyli działa na styku biznesu i technologii. Bo taka osoba z kolei będzie w stanie świadomie instruować tego LLM-a, rozumiejąc Twój kontekst biznesowy, rozumiejąc jak łączyć biznes z technologią, gdzie są te punkty styku.

Dlaczego to jest ważne? Zazwyczaj jak posłuchacie osób, które działają z tymi LLM-ami, czyli z rozwiązaniami AI, to usłyszycie, że właśnie musicie instruować tego LLM-a, podać mu dobry kontekst, dobrze opisać, wyspecyfikować to, co chcecie osiągnąć i przekazać mu Names mentioned in English.

LLM tego za Was nie załatwi, czyli może o ile wcześniej jako programista trzeba było ten kod pisać, o tyle w dzisiejszych czasach przy LLM-ach programiści raczej są teraz, a raczej powinny być, powinni być takimi osobami, które opisują dość precyzyjnie to, co ma wytworzyć LLM, łącząc aspekty biznesowe i aspekty techniczne. Czyli to jest tzw. podejście spec-driven development, czyli wytwarzanie zorientowane na specyfikację. Czyli to, czego większość programistów nie lubi, staje się standardem branżowym. Tak naprawdę większość programistów woli siedzieć w kodzie i programować, wytwarzać ten kod.

Natomiast praktyka z LLM-ami jest zupełnie inna, to znaczy my powinniśmy teraz być takimi analitykami, którzy Którzy analizują biznes klienta, analizują jakiś proces biznesowy, który chcielibyśmy zautomatyzować poprzez oprogramowanie, poprzez AI i powinni opisywać ten proces przekładając te rzeczy biznesowe na rzeczy techniczne. No, smutna sprawa dla programistów, ale za to bardzo wesoła dla product ownerów czy dla właścicieli biznesu, no bo właśnie to oni musieli robić wcześniej, przekazując np. software house'om jakiś tam brief czy specyfikację tego, co chcą osiągnąć. To oczywiście nie oznacza, że biznes tego ma nie robić i nie będzie tego robił.

On będzie to robił cały czas, tylko teraz jest to po prostu łatwiejsze do przetransformowania w kod. Więc to jest bardzo dobra informacja. No ale na koniec dnia oznacza to, O ile biznes jest w stanie zbudować tę część specyfikacji biznesową bardzo dobrze, o tyle brakuje tutaj takiego punktu styku między biznesem i technologią, żeby dospecyfikować te rzeczy, które chce osiągnąć klient tak, żeby już LLM nie miał wątpliwości co do tego, jak ma rzeczy realizować. W architekturze oprogramowania to się nazywa no właśnie architekturą, czyli w zasadzie w wytwarzaniu oprogramowania mówimy o architekturze oprogramowania, czyli o takich podstawowych zasadach, regułach, które muszą zostać spełnione w danym oprogramowaniu, w danym systemie, żeby on realizował cele techniczne i biznesowe, także spełniać swoje

No, żeby nieść po prostu wymierną korzyść drugiej stronie. Także zalecam, warto jest skorzystać, szczególnie na początku tej naszej drogi, jak w organizacji chcemy wytwarzać te rozwiązania AI, bo mówię tu zarówno o produktach, jak i o umieszczaniu, integrowaniu się tak naprawdę istniejących systemów z AI. Warto na początku skorzystać z takich konsultacji, nawet kilku, kilkunastogodzinnych konsultacji z taką osobą, żeby ona dospecyfikowała te wasze założenia biznesowe i żeby też was nauczyła tego, Jak dokładać tego typu elementy, żeby później już po prostu w organizacji móc rozwijać się i pisać specyfikacje w taki sposób, żeby już nie był ten konsultant potrzebny, ale zarazem żeby ten LLM rozumiał co ma wytworzyć.

Tym większa szansa na to, że LLM nie będzie się mylił i nie będzie robił pewnych rzeczy po swojemu. Także to jest bardzo ważna rzecz. Czy tworzycie produkt z AI, czy tworzycie własne systemy do zastosowania wewnętrznego, tego typu dokumentację warto pisać. No i przede wszystkim w dzisiejszych czasach to powinien być właśnie ten Wsad na wejściu dla LLM do wytworzenia oprogramowania. Jeszcze bardziej istotne jest to, niż wcześniej, żeby pisać takie specyfikacje. Te specyfikacje na koniec dnia wytworzą nam też dokumentację oprogramowania, także możemy jednocześnie tworząc produkt, możemy jednocześnie doprowadzić do tego, żeby tworzyła się równolegle dokumentacja podstawowa do tego produktu, do czego zresztą zachęcam, żeby tak robić, bo później na koniec dnia nawet do użytku wewnętrznego

I te systemy zaczynają się ze sobą komunikować i to też jest istotne, żeby każdy z tych agentów wiedział, jak komunikować się z tym nowym oprogramowaniem. Także tak na to patrzmy. Czyli w pierwszej kolejności, jak tworzymy jakieś oprogramowanie z wykorzystaniem LLM-ów, tworzymy precyzyjną, wyspecyfikowaną i ustrukturyzowaną specyfikację taką biznesową. Elementy techniczne. Konwersacja z LLM

Dlatego to jest ważne, żeby te wszystkie rzeczy wyspecyfikować. No i teraz w praktyce, co znaczy taniej i szybciej. Z mojej praktyki, jak tworzymy wewnętrzne narzędzia dla klientów, albo właśnie jak tworzymy ten swój produkt Endora Commerce, no to wygląda to mniej więcej tak, że to przyspieszenie maleje oczywiście wraz ze złożonością produktu. Czyli im bardziej produkt jest rozbudowany, Tym dłużej on będzie się wytwarzał przez LLM i tym drożej nas to będzie kosztowało, no bo spalamy tokeny.

Co już wcale nie oznacza, że będzie to mniej kosztowało. Także warto mieć to na względzie i to jest kluczowy aspekt, który znowu cofa nas do tego sformułowania, o którym mówiłem wcześniej, czyli do sformułowania, że powinniśmy dobrze wyspecyfikować to, co chcemy wytworzyć, że powinniśmy skonsultować to i wziąć pod uwagę ten aspekt technologiczny. No i wziąć pod uwagę to, że też ten programista w postaci LLM-a nie jest idealny i gdzieś tam z tyłu głowy mieć to, że trzeba będzie go koordynować. Także tyle jeśli chodzi o koszty i czas. Oczywiście, jak najbardziej, dowód Endora Commerce jest dowodem na to, że

Które musimy w naszym produkcie zapewnić, żeby po prostu inne organizacje mogły z tego skorzystać. Także to też wpływa na złożoność, to też powinno być zawarte w specyfikacji. Czyli istotne jest to czy np. tworzymy produkt na własne potrzeby, czy tworzymy produkt jednorazowego użytku, czy tworzymy produkt, który chcemy rozwijać, który ma mieć swoją roadmapę i generalnie to ma być produkt rynkowy. To też powinno być zawarte w specyfikacji, bo to też wpływa na to, jakie LLM podejmuje decyzje podczas implementowania takich rzeczy, czy tworzenia tych narzędzi. Miejmy też to na względzie.

Names mentioned in English. Część wad pośrednio wynika z tego, co mówiłem wcześniej, czyli że musimy jednak przyłożyć większą wagę do specyfikacji, że to my musimy jakieś tam aspekty techniczne też zawrzeć w specyfikacji, żeby ten LLM nam nie odpłynął, a mimo to wciąż jest ryzyko tego, że on nas źle zrozumie i będziemy musieli to poprawiać. Oczywiście jak software house, czy generalnie programista, freelancer, który ktokolwiek wytwarza oprogramowanie, możemy doświadczyć tego samego, to znaczy on też może odpłynąć, bo źle zrozumie naszą specyfikację, więc pod tym względem jest 1 do 1 przy zespole LLM kontra programiści.

No ale jednak mimo wszystko LLM-y częściej halucynują, częściej potrafią właśnie pójść w złym kierunku, co wynika z tego, że po prostu ta specyfikacja często otwiera pole do różnych interpretacji, no i programista jakby ma doświadczenie branżowe, zrobił kilka takich systemów, więc czasami sobie dopowiada Names mentioned in English. Od rozwiązania czy od dostawcy bo pamiętajmy że na koniec dnia jak wytworzymy sobie takie oprogramowanie czy agent wytworzy to oprogramowanie i będziemy chcieli je rozwijać utrzymywać to później.

No ale, żeby było sprawiedliwie, trzeba po prostu to zaznaczyć, więc to zaznaczam. Kolejna rzecz, która jest też ważna, czyli taka garść wniosków na zakończenie. Przede wszystkim LLM-y, te rozwiązania, Przesuwają nam te granice automatyzacji procesów, czyli tak naprawdę jesteśmy w stanie dużo szybciej sięgnąć po rozwiązania, po agenta AI, żeby nam wytworzył jakiś program czy narzędzie czy produkt, który nam zautomatyzuje jakiś proces u nas.

Natomiast pamiętajmy wciąż, że te LLM nie eliminują tej granicy automatyzacji. Co to oznacza? Zmierzam do tego, że wciąż jest ten taki punkt w organizacjach, gdzie pewnych procesów czy pewnych elementów nie warto automatyzować. Więc nawet przy tym W tanim dostępie do kodu wciąż zachęcam do tego, żeby zastanowić się przed ruszeniem do GPT i wpisania prompta. Przed wpisaniem tego prompta zachęcam też do tego, żeby zastanowić się czy warto jest ponieść koszt wytworzenia przez agenta tego oprogramowania, utrzymywania później tego oprogramowania i jego potencjalnego rozwijania.

Idealnym przykładem to jest to, jak często w e-commerce chcemy wykorzystywać chatboty AI albo jakieś wyszukiwarki, kreatory, asystentów, którzy będą nam podpowiadać, jakie to produkty mają zostać dodane do koszyka itd., itd. A potem okazuje się, że jak chcemy w to zainwestować albo nie daj Bóg zainwestowaliśmy, to okazuje się, że np. dane produktowe są nieuporządkowane. I wtedy docieramy do tego momentu, o którym wspominałem, czyli śmietnik na wejściu niesamowicie się multiplikuje na wyjściu w przypadku LLM-a. Czyli mamy asystenta, który po prostu będzie potężnie halucynował albo będzie źle podpowiadał.