Na co zwrócić uwagę realizując projekty Generative AI?

Z Agnieszką Niezgodą, Senior Technical Specialist, Data&AI w Microsoft rozmawiamy o tym, czy Generative AI „musi” ograniczać się do konwersacji z chatbotem; Function Calling; integracji chatbotów z usługami zewnętrznymi i dawaniu im dzięki temu konkretnych umiejętności; podejściu do projektów GenAI; roli ustalenia dobrego Use Case’u; łączeniu modeli LLM z „tradycyjnymi” narzędziami AI/ML; a także Prompt Engineeringu.

FUNCTION CALLING, CZYLI DAWANIE CHATBOTOWI UMIEJĘTNOŚCI

W jakich projektach klienci najczęściej używają generatywnej sztucznej inteligencji? Czy wychodzą poza „konwersację z chatbotem”?

Przypomnijmy, trend na usługi Azure OpenAI i ogólnie duże modele językowe LLM rozpoczął się nieco ponad rok temu. Większość klientów chce zacząć projekty z chatbotem. I to nie jest złe rozwiązanie. Chatbot – uruchomiony zwłaszcza na potrzeby wewnętrzne – pozwala pracownikom zaznajomić się z tym, jak: promptować, pracować z kodem. To był i jest nadal bardzo dobry pomysł na zapoznanie się z technologiami GenAI.

Natomiast istnieją bardziej zaawansowane Use Case’y. Jest też ich coraz więcej. Możemy nie tylko konwersować z chatbotem, ale też sprawić, aby robił dla nas różne rzeczy. Wykorzystujemy do tego tzw. Function Calling. Dzięki temu integrujemy chatbota z usługami zewnętrznymi. Dajemy określone umiejętności. Umożliwiamy mu w ten sposób np. stworzenie rekordu w systemie ERP, albo wydobycie potrzebnej nam informacji z systemu CRM. W tym celu można wykorzystywać dowolną usługę, która udostępnia własne API, a także dowolne bazy danych, z którymi można to zintegrować.

Wykorzystanie generatywnej sztucznej inteligencji idzie dziś właśnie w tym kierunku. I co ciekawe, integracja ta obejmuje też tradycyjne modele Machine Learning, bazujące na matematyce. Przykładowo dzięki temu – wykorzystując silniki rekomendacyjne (Recommendation Engine) – możemy dla każdego klienta przygotować zindywidualizowane rekomendacje i wykorzystać je np. w chatbocie, z którego korzystają nasi klienci.

Kiedy więc klient prosi o polecenie jakiegoś produktu, doradca może „uderzyć” do API silnika rekomendacyjnego i wydobyć informację, np. czy dany klient jest skłonny wydać dużo, czy mało i jakie produkty lubi, aby zwiększyć konwersję i jej opłacalność dla sklepu oraz dobór produktu dla klienta. W ten sposób zoptymalizować proces sprzedaży. Czyli chatbot ma już pewną wiedzę na temat klienta, z którym rozmawia, z której może skorzystać.

Silniki rekomendacyjne istnieją od dawna. Czy to, co opisujesz, to coś nowszego, bo np. zostało oparte o model GPT-4?

Silniki rekomendacyjne istnieją od dawna. Dziś chat – mając dostęp do informacji przez API i używając naturalnego języka – może w jeszcze bardziej spersonalizowany i przyjazny sposób doradzić klientom.

Jeśli chodzi o integrację typowych API, to wystarczy dosłownie napisanie kilku linii kodu. W dodatku że możemy dać chatowi dostęp do tych narzędzi, aby on sam – bazując na kontekście wypowiedzi użytkownika – zdecydował, z którego chce skorzystać na podstawie promptu użytkownika. Model może np. zdecydować, czy chce skorzystać z API silnika rekomendacyjnego, żeby sprawdzić, jakie produkty powinien polecić klientowi, czy z API systemu dostawczego, żeby sprawdzić status dostawy produktu, na który ten klient czeka. Może też z takiego promptu „wydobyć” informacje, których potrzebuje do skorzystania z tych dodatkowych narzędzi, np. numer zamówienia podany przez klienta w rozmowie.

Klienci nie obawiają się, że publiczny ChatGTP będzie miał dostęp do kluczowych dla ich firm informacji o klientach, ich preferencjach i będzie uczył się na nich? Nie obawiają się, że pracownicy będą „wrzucać” do niego całe dokumenty firmowe?

Modele korzystają tylko z tych narzędzi i informacji, które im damy. Usługa Azure OpenAI jest bezstanowa, czyli nie przechowuje zapytań, które do niej kierujemy. Wysyłamy je do API. Ani modele Azure OpenAI nie uczą się na naszych danych, ani inni klienci Microsoftu nie mają do nich dostępu.

W ramach tak zwanego Abuse Monitoringu, Microsoft przechowuje zapytania przez 30 dni w obszarze geograficznym, w którym stworzyliśmy sobie usługę, aby podwyższyć poziom bezpieczeństwa, natomiast jest to mechanizm, który klient może wyłączyć.

Podobnie, jeśli tworzymy własne modele, doszkalając te już istniejące np. GPT-3.5 Turbo, w procesie znanym jako fine-tuning, to tylko my mamy dostęp do naszego modelu i możemy go w każdym momencie skasować.

Kwestia bezpieczeństwa aplikacji jest oczywiście kluczowa. Wymaga to po stronie klienta stworzenia tzw. landing zony w środowisku Microsoft Azure, w której można zadbać o cyberbezpieczeństwo i która izoluje nasze środowisko. W kolejnym kroku udzielamy dostępów tym osobom, które powinny go mieć na odpowiednim poziomie.

Oczywiście przed uruchomieniem modeli LLM musimy przeprowadzić całą, typową ścieżkę deweloperską. Po pierwsze, po stworzeniu, odpowiednio je przetestować. W AI Studio jest dostępne narzędzie, które pozwala to łatwo zrobić. Pokazuje np. jakie odpowiedzi system będzie nam zwracał. Jest również wiele zewnętrznych narzędzi, które to umożliwiają, np. MLFlow, który jest standardem wśród narzędziach MLOps.

Ważne jest, aby nowe rozwiązania nie tylko przetestować w fazie developmentu, ale również by je potem monitorować i zbierać logi. Pozwala to analizować w jaki sposób model – już po uruchomieniu – zachowuje się w normalnych sytuacjach, np. w interakcji z klientem. Dzięki temu można wyłapywać i poprawiać ewentualne błędy.

Framework Responsible AI prezentuje całą listę aspektów, na które warto zwrócić uwagę. Przede wszystkim nie powinniśmy ukrywać przed klientem, że rozmawia ze sztuczną inteligencją. Dodatkowo w odpowiedzi możemy na przykład podawać źródło oryginalnej informacji, tak, aby klient mógł sam sprawdzić, czy model się nie pomylił.

ZASILENIE I DOUCZANIE MODELU NASZYMI DOKUMENTAMI

W jaki sposób model LLM korzysta z naszych dokumentów?

Zazwyczaj robi się to w usłudze Azure AI Search. Najpierw fragmentaryzuje się dokumenty źródłowe, a następnie wrzuca je do tego narzędzia, do tzw. indeksu. Tam przeprowadza się ich tzw. wektoryzację, czyli opisuje się semantyczne znaczenie poszczególnych fragmentów liczbami.

Nasza aplikacja wyszukuje potem w AI Search te fragmenty, które najlepiej odpowiadają na zadany prompt i wykorzystuje je, aby sformułować ostateczną odpowiedź. W ten sposób dajemy więc dostęp modelowi do określonych źródeł. Zazwyczaj mówi się o tekstach, ale to mogą być też obrazy, pliki dźwiękowe i inne.

Można dokonać wektoryzacji również tego typu danych, a następnie znajdować i wykorzystywać je do tworzenia podobnych grafik, albo opisywać słowami co chcemy znaleźć na obrazie. Douczać te modele można w tzw. procesie fine-tuningu. Nie uczymy modelu od początku, tylko własną wiedzą douczamy ostatnie warstwy istniejącego modelu LLM, aby zachowywał się w określony sposób.

Jak, krok po kroku, wygląda wykorzystanie takiego modelu LLM w przykładowym projekcie? Najpierw zasilamy go własną bazą dokumentów?

To zależy. Mamy np. klientów, którzy chcieliby dać pracownikom dostęp do zwykłego, standardowego ChatGPT. Nie chcą go karmić własnymi danymi. Chcieliby to jednak zrobić w sposób bezpieczny. Tego typu klientom dostarczamy zazwyczaj tzw. akcelerator, gotowy kod, który przyspiesza pracę z tego typu rozwiązaniami. Można go ściągnąć z GitHuba, wdrożyć we własnym środowisku i dać dostęp do niego pracownikom.

Natomiast jeśli chodzi o bardziej zaawansowane projekty, to ważne jest ustalenie dobrego Use Case’u i podejścia. Dobre to takie, które polegają na wykorzystaniu języka naturalnego, np. tworzeniu nowych tekstów, obrazów, fragmentów kodu źródłowego albo ich analizie.

Mam własnego, stworzonego przeze mnie Copilota, któremu podrzucam fragmenty kodu źródłowego, a on – linijka po linijce – tłumaczy mi czy został prawidłowo napisany, czy też coś w danej linii jest nie tak.

Tego typu asystenci AI mogą też analizować teksty i odnajdywać w nich konkretne informacje. Od kilku tygodni mogą również analizować zdjęcia i diagramy. Pozwala na to model GPT-4 Turbo with Vision. Podobne modele istniały już wcześniej w ramach tzw. Azure Computer Vision. I nadal są wykorzystywane. Są bardzo dobre jeśli chodzi o konkretne use case’y, np. wykrywanie co znajduje się na obrazku albo na nagraniu video, usuwanie tła, tworzenie podpisów obrazków. Natomiast GPT-4 Turbo with Vision jest modelem uniwersalnym o dodatkowych funkcjonalnościach np. potrafi świetnie odczytywać diagramy.

Podsumowując, po pierwsze ustalamy Use Case. Jak już go mamy, to warto byłoby się zastanowić, jak chcemy podejść do projektu. Czy chcemy skorzystać ze wspomnianych akceleratorów czy też samodzielnie coś stworzyć od początku. Wspieramy klientów w obu podejściach. Często idą oni w stronę pracy z akceleratorem, bo chcą coś szybko wypróbować. To jest dobre rozwiązanie, bo gotowych akceleratorów jest bardzo sporo.

Warto mieć również z tyłu głowy wymagania prawne. Upewnić się, że rozumiemy wymagania regulatorów jeśli takie istnieją. Ze strony Microsoftu służymy tutaj chętnie pomocą – mamy gotowe analizy dotyczące konkretnych usług i ich zgodności z regulacjami. To znacząco przyspiesza proces realizacji projektu.

Wspomniałaś na początku o Function Calling. Czy funkcje te są gotowymi rozwiązaniami dostępnymi np. w Azure OpenAI?

Z Function Calling można korzystać na kilka sposobów. Function Calling w kontekście frameworków często nazywa się pluginami albo skillami. Można samemu je pisać, albo skorzystać z gotowych, które znajdują się we frameworkach takich, jak Semantic Kernel, AutoGen czy LangChain. Jest to podejście agentowe – agentom przypisuje się po prostu określone umiejętności. W ramach Azure OpenAI od niedawna jest dostępny Assistants API, które umożliwia podobne podejście. Można też odnaleźć je w naszej dokumentacji.

Jakie to mogą być funkcje?

Ja stworzyłam Copilota, który wyszukuje mi informacje w publicznym internecie, ale tylko na oficjalnych stronach Microsoftu. Modele LLM zostały wyszkolone, ale na danych ograniczonych czasowo, np. GTP-4 do roku 2023. Ja zaś potrzebuję dostępu do bardziej aktualnych informacji, np. tego czy nowa usługa Azure jest już powszechnie dostępna. Wpisuję więc zapytanie, a Copilot samodzielnie wyszukuje potrzebne informacje. Zwraca je w języku naturalnym albo innym formacie, który akurat jest mi potrzebny.

Trzeba mieć duże umiejętności, aby stworzyć własnego Copilota?

Nie. Natomiast warto zdefiniować proces. Wiedzieć czego się szuka. Podejście procesowe wydaje się najbardziej wartościowe. Modele LLM mają wiele, różnych zastosowań i klienci czasami się w tym gubią. Warto zdecydować od czego chce się zacząć, co chcemy przetestować i jaki wynik osiągnąć. Później można dodawać kolejne funkcjonalności.

KOSZTY PROJEKTÓW GENAI

Jak kontrolować koszty tego typu projektów?

Warto pamiętać, że koszt zapytań mierzony jest w tokenach. Na tokeny przeliczane są zarówno zapytania, jak i odpowiedzi. Można jednak z góry ograniczyć długość tej drugiej np. do 500 tokenów. Dostępna jest zresztą biblioteka tiktoken dedykowana modelom OpenAI. Można wpisać do niej fragment tekstu, który zostanie przeliczony na konkretną liczbę tokenów.

Oprócz tego za każdym razem kiedy odpytujemy API w usłudze Azure OpenAI dostajemy w odpowiedzi informację o liczbie wykorzystanych tokenów. Można to następnie zbierać w sposób automatyczny. Informacja o kosztach oczywiście znajduje się też w Azure Cost Center, gdzie użytkownicy informowani są o wszystkich kategoriach ponoszonych kosztów usług chmury Microsoft Azure.

W przypadku wykorzystania fine-tuningu, który jest bardziej zaawansowaną metodą pracy z LLM-ami, warto wiedzieć, że płacimy za to dodatkowo, chociaż stworzenie i wykorzystanie takiego modelu, dostosowanego w 100% do naszych potrzeb może nie okazać się w określonych przypadkach opłacalne, bo np. ograniczymy w ten sposób mocno długość kontekstu przekazywanego w promptach.

Tokeny te są odliczane na bieżąco od rachunku klienta?

Tak jest w modelu Pay As You Go. Najczęściej to od niego zaczynamy pracę z modelami LLM. Płacimy wówczas tylko za to, co wykorzystamy. Jest jeszcze druga opcja, tzw. Provisioned Throughput Unit. PTU pozwala na zarezerwowanie konkretnych modeli w Azure OpenAI, na miesiąc lub dłużej. Zaletą PTU jest to, że oferuje stały poziom wydajności wykorzystywanych modeli, czyli szybkość zwracanych odpowiedzi. W polskim regionie Azure dostępny jest na razie tylko ten sposób wykorzystywania LLM-ów.

DOSTĘPNE USŁUGI AZURE OPENAI I SPOSÓB KORZYSTANIA Z NICH

Jakie są dziś dostępne usługi Azure OpenAI w Europie? Gdzieś na Twoim profilu na LinkedIn znalazłem chyba informację o 7, różnych modelach. W komentarzach wszyscy apelują zaś, aby do tej listy dołączyła Sora.

Zawsze jest tak, że jak wchodzi nowy model, to wszyscy od razu chcieliby go przetestować (śmiech). W polskim regionie Poland Central dostępne są obecnie modele: GPT-3.5 Turbo, GPT-4 i GPT-4 Turbo. Dobrym zaś aktualnie pod względem zakresu dostępności usług Azure – i zarazem najbliższym Polski regionem – jest Sweden Central. Dostępny tam jest GPT-4 Turbo with Vision. Drugim jest France Central.

Jeśli zaś chodzi o Sorę, to pamiętajmy, że to rozwiązanie po pierwsze zostało dopiero co ogłoszone przez OpenAI, a po drugie OpenAI to w końcu odrębna od Microsoftu firma. Kiedy nowe modele pojawiają się na Azure OpenAI zostaje to zawsze ogłoszone publicznie i odzwierciedlone w dokumentacji.

Warto wykorzystywać ten sam model LLM w dwóch regionach Azure, np. w Warszawie i Szwecji, czyli zrobić tzw. Load Balancing. Tym bardziej, że istnieją limity na to, ile tokenów możemy wykorzystać na minutę korzystając z jednego modelu w jednym regionie i subskrypcji. Dzięki temu, jeśli zużyjemy je w jednym regionie, możemy automatycznie zostać przekierowani do drugiego.

Przykładowo rezerwujemy PTU w Polsce i z tej usługi korzystamy, aby pokryć nasz zwykły ruch, np. wygenerować odpowiedzi na pytania klientów korzystających z naszego chatbota. W momencie, kiedy wyjątkowo dużo osób korzysta z naszej aplikacji „nadmiarowe” prompty zostają przekierowane do naszego drugiego regionu – Sweden Central i pokryte metodą pay-as-you-go.

Z jakich jeszcze narzędzi AI korzystają Wasi klienci?

Najnowszym trendem jest integracja różnych modeli. LLM istnieją w świadomości publicznej od nieco ponad roku. Natomiast rozwiązania takie, jak: Computer Vision, speech to text czy text to speech wykorzystywane są od lat. Swoją drogą dwa ostatnie są obecnie dostępne również poprzez usługi Azure OpenAI. Możemy nasz tekst dać do odczytania wybranemu lektorowi. Możemy też dokonać transkrypcji nagranego wywiadu.

Integrując różne modele można zwiększyć wartość wykorzystywanego w naszej organizacji narzędzia. Typowym Use Case’m – nad którym pracuje wiele firm – jest Contact Center Analytics. Dotyczy to automatyzacji procesów związanych z obsługą klienta. Dla konsultanta przygotowuje się chatbota, który automatycznie wykrywa, o co pyta klient i podpowiada co można mu zaproponować w odpowiedzi na jego pytania. Albo dajemy klientom bezpośrednio dostęp do naszej aplikacji, gdzie mogą uzyskać szybką odpowiedź na swoje pytania, a nawet – jak powiedzieliśmy wcześniej – bot może dla nich załatwić pewne rzeczy, np. anulować ich zamówienie. Za kilka lat procesy te będą już mocno zautomatyzowane.

Do tego można dodać tzw. Sentiment Analysis oraz analizę tego, co mówi klient albo rozmów między klientem i konsultantem. Integrując te rozwiązania z usługami Azure OpenAI możemy odpytać ChatGPT, czy problem, z którym zgłosił się klient, został rozwiązany. Albo czy konsultant odpowiadający na pytania klienta działał według opracowanego standardu. Albo tego, co o naszym produkcie klienci piszą online. To wszystko można zautomatyzować.

Jakie są główne bariery, które powstrzymują albo opóźniają projekty Generative AI?

Klienci często obawiają się halucynacji modeli. Tymczasem jest to coś, co można i należy kontrolować. Zwłaszcza jeśli narzędzie to udostępniamy użytkownikom zewnętrznym.

Istnieją dobre praktyki w tym zakresie – od tych najprostszych – pracujemy z promptami i ich parametrami, które przekazujemy do modelu, aby ograniczyć jego halucynację. Równolegle pracujemy z procesem, to znaczy np. kiedy chatbot stworzy odpowiedź, to ona nie będzie bezpośrednio zwracana do użytkownika, który zadał pytanie, tylko wpierw zostanie sprawdzona pod kątem jej poprawności i określeniem źródła. Jeśli odpowiedź nie przejdzie takiego testu, to przekierujemy użytkownika na kontakt z doradcą.

Można też stworzyć kilka odpowiedzi, a później wybrać tę dominującą. W ogromnej większości przypadków będzie bowiem prawidłowa.

Dokumenty, z których korzystają nasze aplikacje bazujące na GenAI należy również odpowiednio przygotować. Warto przed ich udostępnieniem sprawdzić czy nie zawierają wrażliwych danych. Następnie zaś uruchomić chatbota, który odpowiada na pytania tylko na podstawie tak sprawdzonych dokumentów.

Pracując z klientami staramy się od początku myśleć w sposób procesowy. Warto przemyśleć, jak narzędzie powinno działać, aby przynieść jak największą wartość naszej firmie, jednocześnie ograniczając wysiłek związany z utrzymaniem dzięki np. automatyzacji procesu przygotowania dokumentów źródłowych, z których nasza aplikacja ma korzystać.

NAJLEPSZE PRZYPADKI UŻYCIA

Z jakimi spotkałaś się najciekawszymi Use Case’ami?

Na mnie największe wrażenie robi personalizacja rozwiązań GenAI oraz odejście od „tradycyjnych” chatbotów. Ich wersja 2.0 pozwala na zasilenie go informacjami o tzw. Customer Journey konkretnego klienta. Tego typu asystent AI wie, gdzie kliknął on na stronie lub w aplikacji. Boty nowej generacji mają dostęp do konkretnych informacji na temat klienta i jego potrzeb.

Niektóre firmy próbują wykorzystywać GenAI do tworzenia rekomendacji strategicznych i interpretacji danych. Aplikacja może zarówno odnaleźć odpowiednie informacje w internecie i wewnętrznych danych firmy, jak i zinterpretować te odpowiednio. Chatbot może więc podpowiadać analitykom oraz managerom, jak uzyskać oczekiwaną odpowiedź na pytania strategiczne, np. powód spadku sprzedaży.

Bardzo ciekawa jest również analiza dokumentów prawnych. Mamy kilka tego typu Use Case’ów. Polski język prawniczy jest co prawda skomplikowany, ale ChatGPT dobrze sobie z nim radzi.

Bank Morgan Stanley dał pracownikom dostęp do wiedzy zgromadzonej w 100 tys. wewnętrznych dokumentów. To inny, możliwy Use Case. Jak podejść do tego typu projektu?

Warto przed zasileniem modelu LLM tymi dokumentami przemyśleć ten proces. Przykładowo jeśli chodzi o dokumenty prawne, to często określają one warunki, które dana firma oferuje klientom. One często się zmieniają. Warto więc np. w ich nazwie zawrzeć okres ważności. Później, jak wspomnieliśmy, dokumenty te są opisywane właściwymi wektorami np. w AI Search.

Warto w indeksie AI Search wprowadzić pole, w którym zapisujemy od kiedy do kiedy dany dokument był ważny, aby np. model po tym terminie nie brał ich już pod uwagę. No chyba, że chcemy, aby nadal były dostępne. W bankach często dokumenty – mimo, że powstały dekady wcześniej – muszą być dostępne np. dla klientów, którzy wzięli kredyt na 30 lat. Jeśli na dokumencie jest sygnatura, w którym opisany jest okres ważności, to taką informację można wydobyć automatycznie.

Warto też przemyśleć jak inaczej te dokumenty trzeba przygotować. Może np. mają różną hierarchię ważności – jedne są ważniejsze od innych – i opisując je w AI Search warto uwzględnić pole, gdzie stopień tej ważności można oznaczyć. Albo chcemy się upewnić, że nie zawierają danych wrażliwych. Ważna jest też decyzja związana z samym procesem przeprowadzania RAG, czyli np. jak bardzo chcemy fragmentaryzować treści, które następnie zostaną zwektoryzowane oraz jak często chcemy przeprowadzać proces wektoryzowania.

Zrobić można wszystko. Trzeba jednak przemyśleć, jaki proces będzie do tego najlepszy.

JAK BUDOWAĆ DOBRY PROMPT

Na co jeszcze warto zwrócić uwagę?

Bardzo ważny jest Prompt Engineering, czyli budowa jak najlepszych zapytań do modelu. Warto komunikować się z modelem w sposób zrozumiały, nie zaprzeczać sobie. Istnieją również bardziej zaawansowane techniki takie, jak: ReAct czy Chain-of-thought. Dzięki nim możemy pokazać modelowi jak ma myśleć. Ich zastosowanie robi ogromną różnicę. Można nawet modelowi określić to, w jakim formacie ma zwrócić odpowiedź.

W tym miejscu warto pamiętać, że jest System Prompt i User Prompt. Pierwszy definiuje m.in. rolę modelu LLM i to, jak ma odpowiadać na pytania. W nim „zapisuje się” także kwestie bezpieczeństwa. Drugi zaś, w kontekście typowych aplikacji-asystentów, opisuje to, co chcemy otrzymać, czyli np. hasło marketingowe, analizę dokumentu pod konkretnym kątem, albo informacje o produkcie jeśli nasza aplikacja ma tworzyć opisy produktów sprzedawanych w naszym sklepie w języku naturalnym.

Prompty, niezależnie od rodzaju, powinny być przede wszystkim dobrze, jasno, zrozumiale napisane. Wyobraźmy sobie, że tłumaczymy coś dziecku. Z ciekawostek, warto też spróbować zaproponować promptowi „napiwek”. Zwrócić uwagę, że odpowiedź będzie miała wpływ na naszą karierę albo jest ważna dla naszych bliskich. Podkreślić, że nie musi się śpieszyć. Możliwe, że wówczas otrzymamy lepszą odpowiedź.

Jak podejść do projektów Generative AI?

1. Nie zawsze trzeba wszystko budować od zera. Warto poszukać gotowych narzędzi: innych usług AI dostępnych na Azure, jednym z nich jest np. Azure AI Translator, albo akceleratorów dostępnych na GitHubie.
2. Jeden token to średnio 2-3 znaki (liczymy te zarówno w zapytaniu, jak i w odpowiedzi). To nimi płaci się korzystając z rozwiązań GenAI w modelu pay-as-you-go.
3. Ważna jest nauka budowania promptów, czyli wprowadzania instrukcji dla modelu, aby wygenerować jak najlepszy wynik.
4. System Prompt definiuje rolę dla modelu LLM i to, jak ma odpowiadać na pytania. W nim zapisuje się także kwestie bezpieczeństwa. User prompt to polecenie użytkownika naszego chatbota albo np. dane produktu jeśli nasza aplikacja ma tworzyć opisy produktu w języku naturalnym.
5. Prompty, niezależnie od rodzaju, powinny być przede wszystkim dobrze, jasno napisane i ustrukturyzowane.
6. Warto spróbować zaproponować promptowi „napiwek”. Zwrócić uwagę, że odpowiedź będzie miała wpływ na naszą karierę albo jest ważna dla naszych bliskich. Podkreślić, że nie musi się śpieszyć. Możliwe, że wówczas otrzymamy lepszą odpowiedź.
7. Często stosowaną architekturą aplikacji bazujących na GenAI jest Retrieval Augmented Generation (RAG). RAG to wzorzec projektowy AI, który obejmuje połączenie dużego modelu językowego z zewnętrznym źródłem „wiedzy” np. wewnętrznych dokumentów firmy lub jej stron internetowych.
8. Pod spodem architektury RAG zazwyczaj stoi usługa Azure AI Search, która oferuje możliwość przechowywania źródeł do wyszukiwania oraz wiele optymalizacji takich jak Semantic Ranker.