Wybór między RAG a fine tuningiem dotyczy tego, co asystent ma robić. RAG, czyli retrieval-augmented generation, dostarcza odpowiedni materiał źródłowy, gdy model odpowiada; fine tuning oznacza dalsze trenowanie modelu na przykładach. Najpierw należy przetestować jasną instrukcję zadania, czyli prompt. Dopiero potem należy wykorzystać wynik, aby zdecydować, czy przed zleceniem dodatkowych prac zbadać brak materiału źródłowego, niespójność wyników, czy oba problemy.
Jeden dostawca proponuje wytrenowanie systemu AI dla Państwa firmy, a drugi bazę wiedzy umożliwiającą wyszukiwanie. Opisy te nie definiują zadania, które gotowy system ma wykonywać, ani tego, co należałoby uznać za nieudany wynik. Zaczynamy od zapisania tego zadania. Daje ono konkretną podstawę do porównania otrzymanych ofert.
Co zmienia wybór RAG lub fine tuningu?
RAG zmienia materiał dostarczany do odpowiedzi, a fine tuning zmienia model poprzez trening. Przewodnik OpenAI dotyczący dokładności rozróżnia brak kontekstu i niespójne zachowanie. Jest to przydatne rozróżnienie początkowe dla kupującego, o ile pozostawi się miejsce na nakładające się potrzeby. Asystent korzystający z dokumentów może również potrzebować spójnego sposobu formułowania odpowiedzi.
Zgodnie z objaśnieniem baz wiedzy Amazon Bedrock wyszukiwanie wybiera odpowiedni materiał i dołącza go do danych wejściowych generowania. W przypadku proponowanego asystenta odpowiadającego na pytania o zasady zwrotów należy poprosić o wskazanie, który zatwierdzony fragment uzasadnia odpowiedź. Odwołanie do źródła nadal trzeba sprawdzić pod kątem zgodności z treścią odpowiedzi.
Fine tuning wykorzystuje przykłady do dalszego trenowania modelu w zakresie sposobu odpowiadania. Przewodnik OpenAI przedstawia go jako jedną z możliwości poprawy zachowania w określonym zadaniu. Można wyobrazić sobie oczekiwaną notatkę przekazującą sprawę, o uzgodnionej strukturze: dostawca potrzebuje przykładów akceptowalnych notatek oraz danych wejściowych użytych do ich utworzenia. Jest to inny rezultat niż folder dokumentów opisujących zasady.
Żadna z tych nazw nie wskazuje, czy prezentacja spełnia Państwa wymagania. Należy poprosić dostawcę o określenie, co zmienia proponowany komponent, pokazanie wykorzystywanego materiału oraz wyjaśnienie, jak zostanie sprawdzony wynik. Rozmowa powinna pozostawać związana z rzeczywistą pracą, którą Państwo kupują.
Najpierw zadanie i prostsza prezentacja
Przed wyborem podejścia należy opisać dane wejściowe i akceptowalny wynik. Przewodnik Anthropic dotyczący promptów zaczyna od jasnych kryteriów sukcesu, testu z przykładami i roboczej wersji promptu. W tej kolejności przygotowujemy specyfikację zakupową: zapisujemy instrukcję, dostarczamy zatwierdzony materiał i sprawdzamy, co potrafi najprostsza proponowana konfiguracja. Jest to sugerowana przez nas metoda oceny, a nie opublikowany benchmark.
W przykładowym asystencie do obsługi zwrotów danymi wejściowymi mogłyby być pytanie klienta i właściwe zasady. Akceptowalna wersja robocza odpowiada tylko w zakresie uzasadnionym przez te zasady, a wyjątki przekazuje człowiekowi. W przykładowym przekazaniu sprawy sprzedażowej danymi wejściowymi mogłyby być zapytanie i zatwierdzony format notatki. Wynik powinien zachować znaczenie zapytania i pozostawić brakujące szczegóły niewypełnione.
Właściciel procesu powinien zapisać, co sprawia, że każdy wynik jest akceptowalny. Należy uwzględnić prośbę, której asystent powinien odmówić lub którą powinien przekazać człowiekowi. Trzeba korzystać z materiałów, które wolno Państwu udostępniać, po usunięciu zbędnych danych osobowych. Prezentacja zależna od informacji, których nie mogą Państwo dostarczyć, nie jest jeszcze wykonalną propozycją.
Jeśli mają już Państwo asystenta udzielającego niewiarygodnych odpowiedzi, przed podjęciem decyzji o zleceniu prac warto skorzystać z osobnego przewodnika o sprawdzaniu, dlaczego AI udziela błędnych odpowiedzi.
Kolejny test należy dobrać do pozostałej luki
Zaobserwowane niepowodzenie powinno wskazywać, co przetestować dalej. AWS zaleca rozpoczęcie od wyszukiwania w przypadku pytań odwołujących się do niestandardowych dokumentów i zwraca uwagę na trudność utrzymania zgodności treningu z często zmieniającym się materiałem. Dopuszcza również łączne zastosowanie wyszukiwania i fine tuningu. Poniższa tabela sugeruje kolejny test dla luki wykrytej podczas prezentacji.
| Czego nadal brakuje w prezentacji | Co przetestować dalej |
|---|---|
| Informacji z zatwierdzonych, zmieniających się dokumentów | Wyszukiwanie dostarczające odpowiedni aktualny materiał |
| Powtarzalnego wyniku, który pozostaje niespójny po zastosowaniu jaśniejszych instrukcji i przykładów | Trening na zaakceptowanych przykładach, jeśli wybrany model go obsługuje |
| Materiału źródłowego i bardziej spójnej odpowiedzi | Połączona konfiguracja, z kontrolą każdego wymagania |
Jeśli prostsza prezentacja już spełnia wymagania, należy zachować tę opcję w porównaniu. Warto zapytać, jaki dodatkowy problem rozwiązałby proponowany trening lub system wyszukiwania. Decyzja może również pozostać otwarta podczas przygotowywania brakujących danych wejściowych.
AWS zauważa, że fine tuning nie jest dostępny dla każdego modelu. Należy poprosić dostawcę o wskazanie dostawcy modelu i samego modelu, wyjaśnienie, gdzie i w jaki sposób system będzie działał, oraz potwierdzenie aktualnej obsługi proponowanego treningu i wdrożenia.
Kto utrzymuje system po uruchomieniu?
Należy porównać obowiązki, które każda oferta pozostawia Państwa zespołowi. W przypadku wyszukiwania trzeba wskazać osobę zatwierdzającą dokumenty źródłowe i sprawdzającą, czy aktualizacje docierają do asystenta. W przypadku treningu trzeba wskazać osobę przygotowującą zaakceptowane przykłady i weryfikującą późniejsze zmiany. Należy zapisać, kto przyznaje dostęp, kto obsługuje awarie i w jaki sposób pracownicy przywracają zadanie do procesu ręcznego, gdy system nie jest odpowiedni.
Przed wyborem komponentów uwzględniamy te pytania w planowaniu wdrożenia AI. Przydatna specyfikacja zawiera:
- Zadanie, dozwolone dane wejściowe i oczekiwany wynik.
- Wiążące źródła, ich właściciela i proces aktualizacji.
- Przykłady akceptowalnej pracy oraz niedopuszczalnych pominięć lub dodatków.
- Warunki odmowy realizacji prośby lub przekazania jej człowiekowi.
- Kontrole akceptacyjne, osobę weryfikującą i materiały do przekazania.
W przypadku pracy dotyczącej aktywnego zamówienia lub rekordu kontaktu należy zapytać, w jaki sposób proponowany system uzyska dozwolony, aktualny rekord. Wymaganie to trzeba uwzględnić w części specyfikacji dotyczącej integracji CRM. Oferta treningu na wyeksportowanych rekordach nadal wymaga wyjaśnienia sposobu obsługi późniejszych zmian.
Należy zapytać, gdzie będą przechowywane dokumenty, kopie umożliwiające wyszukiwanie, przykłady i wyniki, kto będzie miał do nich dostęp oraz jak będą usuwane. Odpowiedzi trzeba zapisać dla rzeczywistego wdrożenia. Żadnej nazwy architektury nie należy traktować jako rozstrzygnięcia kwestii hostingu lub uprawnień.
Propozycję trzeba sprawdzić na niewykorzystanych wcześniej żądaniach
Żądania testowe należy trzymać poza materiałem użytym do skonfigurowania lub wytrenowania proponowanego systemu. Każdy dostawca powinien wykonać te żądania według tych samych kryteriów akceptacji. Właściciel procesu powinien sprawdzić wyniki, dane wejściowe użyte do ich utworzenia oraz potrzebne poprawki. Pozwala to sprawdzić ofertę w Państwa zadaniu, ale nie dowodzi skuteczności przy każdym przyszłym żądaniu.
- Należy zachować punkt odniesienia. Trzeba zapisać wyniki procesu ręcznego i prostszego promptu wraz z danymi wejściowymi i uwagami z przeglądu.
- Należy sprawdzić aktualizację źródła. Trzeba zmienić zatwierdzony dokument testowy i powtórzyć pytanie, którego zmiana dotyczy. Dostawca powinien pokazać, której wersji użyto i jak aktualizacja dotarła do asystenta.
- Należy sprawdzić reguły wyniku. Trzeba przeformułować żądanie i pominąć część informacji. Następnie należy sprawdzić, czy notatka zachowuje wymaganą strukturę bez wymyślania szczegółów.
- Należy przetestować dostęp i zakres. Warto wypróbować żądanie spoza uzgodnionego zakresu oraz użytkownika, który nie powinien otrzymać dokumentu z ograniczonym dostępem. Trzeba sprawdzić rzeczywistą odmowę lub przekazanie.
- Należy zapisać pracę, którą zespół nadal musi wykonywać. Trzeba odnotować poprawki, czas przeglądu i osobę odpowiedzialną za utrzymanie materiałów. Przed rozszerzeniem prac należy porównać te elementy z punktem odniesienia.
Gdy kontrola zakończy się niepowodzeniem, należy zapisać niespełnione wymaganie i poprosić o poprawioną prezentację. Nie warto płacić za bardziej złożone podejście wyłącznie dlatego, że jego nazwa brzmi jak zapowiedź większych możliwości. Można zaakceptować zakres, który da się zweryfikować, albo pozostawić zadanie ludziom do czasu spełnienia brakujących warunków.
Jak możemy pomóc
Zaczynamy od wspólnego zapisania zadania, dozwolonych danych i kontroli akceptacyjnych. Następnie porównujemy proponowane podejścia z tą specyfikacją i dokumentujemy, kto będzie utrzymywać źródła, przykłady oraz ocenę. Dobrym pierwszym krokiem jest zapisanie rzeczywistego żądania i zatwierdzenie przykładu potrzebnego wyniku.
