Z pięciu haseł ma powstać krótka notatka z rozmowy. Czy przy każdym zapytaniu musi pracować największy dostępny model językowy? Często warto najpierw jasno ograniczyć zadanie i przetestować mniejszy model.
Oczekiwany wynik mieści się w kilku wierszach.
Fikcyjny telefon zostaje zapisany następującymi hasłami: „Klientka pyta o termin dostawy, oferta jest dostępna, wyjaśnienie wewnętrzne w toku, odpowiedź jutro”. Wiadomość ma zrozumiale podsumować treść. Nie może wymyślać terminu dostawy ani tworzyć z tych haseł zamówienia lub obietnicy ceny.
W tym zadaniu liczą się kompletność, poprawne przypisanie informacji i radzenie sobie z brakami. Szczególnie obszerne rozumowanie lub duże okno kontekstowe mogą zwiększać nakład bez poprawy użyteczności notatki.
Najpierw kryteria odbioru, potem wybór modelu.
Zestaw testowy nie zawiera wyłącznie dobrze napisanych przykładów. Obejmuje skróty, literówki, sprzeczne informacje czasowe i brakujących rozmówców. Dla każdego przykładu określa się, co wolno przejąć, a kiedy należy zadać pytanie uzupełniające.
Mniejszy model jest odpowiedni, jeśli niezawodnie spełnia te wymagania. W przeciwnym razie szuka się przyczyny: niejasne dane wejściowe, niewłaściwe przygotowanie, brak walidacji lub rzeczywiście niewystarczające możliwości modelu. Większy model może pomóc, ale nie jest najbardziej ekonomiczną odpowiedzią na każdy błąd.
Kontrolowany router może różnie obsługiwać zadania.
Krótka notatka z rozmowy może przechodzić inną ścieżkę przetwarzania niż złożona analiza umowy lub przegląd kodu. Wybór uwzględnia wymagania ochrony, zatwierdzonych dostawców, jakość i czas odpowiedzi. Przy niewystarczającym wyniku następuje pytanie uzupełniające lub zdefiniowana eskalacja.
Model zastępczy nie może przy tym powodować nowego, niedozwolonego przekazania danych. Kontrola merytoryczna i limity budżetowe obowiązują także wtedy, gdy początkowo wybrane API jest akurat niedostępne.
Cena tokenów to tylko jeden wiersz kalkulacji.
Tanie wywołanie może okazać się kosztowne, jeśli pracownicy muszą często poprawiać wyniki. I odwrotnie: droższy model może być korzystny całościowo, jeśli wykonuje wymagające zadanie przy znacznie mniejszej liczbie poprawek. Porównuje się to samo zadanie z tymi samymi wymaganiami jakościowymi.
- Użycie
- Zużycie danych wejściowych i wyjściowych, dodatkowe wywołania narzędzi oraz konieczne powtórzenia.
- Jakość
- Udział rzeczywiście użytecznych wyników i skutki krytycznych błędów merytorycznych.
- Poprawki
- Czas kontroli, korekty, pytań uzupełniających i ponownego przetwarzania.
- Eksploatacja
- Integracja, monitoring, aktualizacje, limity i obsługa awarii.
Można też poprawić dane wejściowe.
Do notatki przekazuje się potrzebne hasła, a nie na wszelki wypadek całą historię klienta. Jasny format wyniku ułatwia kontrolę. Jeśli usługa to obsługuje, powtarzalne części wejścia mogą korzystać z prompt cachingu. Trzeba zmierzyć, czy następuje trafienie w pamięć podręczną i jaki daje efekt.
Asynchroniczne przetwarzanie wsadowe to kolejna możliwość dla zadań niewymagających natychmiastowej odpowiedzi. Pasuje na przykład bardziej do przygotowanego zbioru dokumentów niż do notatki potrzebnej jeszcze podczas rozmowy.
Dostępny już ryczałt nie oznacza bezpłatnego oczekiwania.
Opłacone już limity mogą wpłynąć na decyzję. Zbędne dane wejściowe, poprawki wykonywane przez ludzi i zajęte zasoby nadal mają znaczenie. Ekonomiczna architektura mierzy koszt skutecznie zakończonej operacji i ponownie go ocenia po zmianach modelu lub produktu.
Specjalistyczna strona Optymalizacja kosztów AI wyjaśnia routing modeli, bramy i lokalną infrastrukturę. Przy ocenie całych procesów artykuł Skrypt, workflow czy agent AI? uzupełnia podstawy decyzji.
Źródła: OpenAI: optymalizacja kosztów · OpenAI: prompt caching · OpenAI: przetwarzanie wsadowe. Bez ogólnych obietnic oszczędności lub cen.
