Od promptu do produktu: jak przekuć LLM-y w prawdziwe aplikacje
Praktyczna metodyka budowania aplikacji LLM: ewaluacje, mechanizmy zabezpieczające, budżety opóźnień i kosztów, człowiek w pętli oraz świadomość, czego nie automatyzować.
Autor Vitor Lima
Prompt, który działa w piaskownicy, to demo, a nie produkt. Przepaść między nimi to miejsce, w którym po cichu umiera większość projektów AI. Budowanie aplikacji LLM, które przetrwają zderzenie z prawdziwymi użytkownikami, ma znacznie mniej wspólnego ze sprytnym promptowaniem, niż sugerują to dema, a znacznie więcej ze zwyczajną dyscypliną inżynierii oprogramowania. Wdrożyliśmy ich dość — Youp, MadaiOps, a teraz Linea — żeby mieć zdanie na temat tego, co naprawdę zasypuje tę przepaść. Nic z tego nie jest efektowne.
Pułapka polega na tym, że pierwsza wersja sprawia wrażenie skończonej. Wklejasz sprytny prompt, model zwraca coś imponującego i kusi, żeby opakować to w interfejs i ogłosić premierę. Potem pojawiają się prawdziwi użytkownicy z danymi wejściowymi, których nigdy sobie nie wyobrażałeś, model z pełnym przekonaniem robi coś błędnego, a ty odkrywasz, że nie masz jak stwierdzić, czy twoja poprawka polepszyła, czy pogorszyła sytuację. Ten tekst jest o rusztowaniu, które zamienia to imponujące demo w coś, co możesz uruchomić na produkcji i spokojnie przespać noc.
Zacznij od ewaluacji, a nie od promptów
Rzeczą o największej dźwigni, którą możesz zbudować na wczesnym etapie, jest zestaw ewaluacyjny. Nie benchmark, nie ranking — folder z prawdziwymi danymi wejściowymi w parze z tym, jak wygląda dobra odpowiedź. Dwadzieścia przykładów bije zero, a pięćdziesiąt starannie dobranych bije tysiąc zeskrobanych z sieci.
Powód jest prosty. Gdy masz ewaluacje, inżynieria promptów przestaje być zgadywanką na czuja. Zmieniasz linię, uruchamiasz zestaw, patrzysz, jak liczba się zmienia. Bez tego każda korekta jest przesądem. Widzieliśmy zespoły, które spędziły tydzień na ulepszaniu promptu, by cofnąć się na przypadkach rozwiązanych miesiące wcześniej, bo nic nie mierzyło tych przypadków, na które nie patrzyły.
Kilka opinii, których trzymamy się mocno:
- Oceniaj po wynikach, a nie po sformułowaniach. W przypadku wszystkiego, co ustrukturyzowane — ekstrakcja, klasyfikacja, routing — asertuj na przetworzonym wyniku, a nie na podobieństwie łańcuchów znaków. Dla tekstu otwartego LLM jako sędzia z precyzyjną rubryką jest w porządku, ale najpierw zwaliduj tego sędziego względem garści ludzkich etykiet, bo inaczej mierzysz jedynie gust jednego modelu.
- Prowadź plik regresji. Każda awaria na produkcji staje się trwałym przypadkiem testowym. To dzięki temu twój zestaw ewaluacyjny pozostaje uczciwy — rośnie dokładnie w tych kierunkach, w których napiera na niego rzeczywistość.
- Wersjonuj ewaluacje razem z promptami. Prompt bez zestawu ewaluacyjnego to nieprzetestowana zmiana w kodzie.
Jeśli z tego artykułu zbudujesz tylko jedną rzecz, zbuduj właśnie to. Wszystko dalej zależy od tego, czy potrafisz odpowiedzieć na pytanie: czy to coś polepszyło?
Mechanizmy zabezpieczające są tańsze niż przeprosiny
Modele zawodzą w sposób, w jaki zwyczajne oprogramowanie nie zawodzi. Wymyślą API, które nie istnieje, przytakną fałszywej przesłance użytkownika albo wyprodukują poprawnie wyglądający JSON ze zmyślonym polem. Mechanizmy zabezpieczające to warstwa, która wyłapuje to, zanim dotrze do użytkownika lub, co gorsza, do kroku wykonawczego.
Myśl w kategoriach trzech pozycji.
- Zabezpieczenia wejścia odrzucają lub oczyszczają dane, zanim model ruszy: prześwietlanie pod kątem wstrzyknięć promptów, redakcja danych osobowych, filtrowanie treści poza tematem.
- Zabezpieczenia wyjścia walidują to, co wraca: walidacja schematu, sprawdzanie ugruntowania cytatów, filtry polityk.
- Zabezpieczenia działań siedzą pomiędzy modelem a wszystkim, co ma efekty uboczne.
To trzecie jest miejscem, gdzie mieszka prawdziwe ryzyko. W Linei, naszych agentach do automatyzacji przepływów pracy, model może proponować działania — wywołać API, przenieść rekord, wysłać wiadomość. Propozycja i wykonanie są celowo osobnymi krokami. Każde brzemienne w skutki działanie przechodzi przez typowany kontrakt i kontrolę polityki, zanim cokolwiek się wydarzy, a działania niszczące lub nieodwracalne wymagają jawnej bramki potwierdzenia. Agent sugerujący niewłaściwą rzecz to problem UX, nad którym możesz iterować. Agent wykonujący niewłaściwą rzecz to incydent. Trzymaj te dwa tryby awarii po przeciwnych stronach twardej granicy.
Wersja z jasnym stanowiskiem: waliduj ustrukturyzowane wyjście względem schematu i ponawiaj przy niepowodzeniu, zamiast ufać, że model będzie spójny. I nigdy nie pozwalaj, by surowe wyjście modelu było tym, co wyzwala nieodwracalne działanie. Zawsze wstaw pomiędzy deterministyczną kontrolę.
Budżetuj opóźnienia i koszty jak funkcje produktu
Opóźnienia i koszty to nie rzeczy, które mierzysz na końcu. To ograniczenia, przeciwko którym projektujesz od samego początku, bo zmieniają architekturę, a nie tylko rachunek.
Ustal jawne budżety dla każdego działania widocznego dla użytkownika: cel opóźnienia w percentylu p95 i pułap kosztu na wywołanie. Gdy je spiszesz, decyzje projektowe stają się łatwiejsze. Kilka wzorców, po które sięgamy raz za razem:
- Dobierz rozmiar modelu do kroku. Większość potoków ma jeden lub dwa kroki, które faktycznie potrzebują flagowego modelu, oraz kilka takich, z którymi mniejszy i szybszy poradzi sobie bez problemu. Skierowanie prostej klasyfikacji do taniego modelu i zarezerwowanie tego drogiego dla trudnego kroku rozumowania to optymalizacja o najwyższym zwrocie, a zwykle poprawia też opóźnienia.
- Strumieniuj pierwszy token. W czymkolwiek konwersacyjnym postrzegane opóźnienie zdominowane jest przez czas do pierwszego tokena. Strumieniowana odpowiedź, która zajmuje cztery sekundy, sprawia lepsze wrażenie niż blokująca, która zajmuje dwie.
- Buforuj agresywnie. Buforowanie promptów na stabilnym kontekście systemowym, zwykłe buforowanie wyników na powtarzających się wejściach. Znacząca część ruchu produkcyjnego to niemal duplikaty.
Kompromis, który warto trzymać w głowie: większe modele zmniejszają twój wysiłek inżynierski, ale na zawsze podnoszą koszt krańcowy i opóźnienia. Tańsze modele przerzucają pracę na ciebie — więcej dbałości o prompty, więcej zabezpieczeń, więcej ewaluacji — ale ta praca to koszt jednorazowy w zamian za trwałą oszczędność. Przy czymkolwiek o dużym wolumenie zainwestuj w inżynierię.
Trzymaj ludzi w pętli, świadomie
„Człowiek w pętli" powtarzane jest tak często, że przestało cokolwiek znaczyć. Dobrze zrobione, nie jest zabezpieczeniem na wypadek, gdy AI zawiedzie — jest zaprojektowanym podziałem pracy. Pytanie nie brzmi czy włączyć człowieka, lecz gdzie osąd człowieka wart jest więcej niż opóźnienie, które dokłada.
Wzorzec, który sprawdził nam się najlepiej, to eskalacja bramkowana pewnością. System obsługuje pewną większość automatycznie i kieruje niepewną mniejszość do człowieka, z dołączonym rozumowaniem modelu, tak by człowiek zdecydował w sekundy, a nie minuty. W MadaiOps operacje na zleceniach w normalnych parametrach przechodzą swobodnie; cokolwiek anomalne wypływa do operatora z kontekstem, zamiast wykonywać się po cichu. Recenzent nie niańczy maszyny. Poświęca swoją uwagę tylko tam, gdzie jest ona rzadka i cenna.
Jeszcze jedna zasada: instrumentuj korekty człowieka i zawracaj je do zestawu ewaluacyjnego oraz do promptów. System z człowiekiem w pętli, który nie uczy się od swoich ludzi, po prostu płaci dwa razy za tę samą pracę.
Wiedz, czego nie automatyzować
Najtrudniejszym osądem w tej dyscyplinie jest powściągliwość. Nie każde zadanie należy przekazać modelowi, a dojrzałość to wiedza, które zostawić w spokoju.
Nasz zgrubny test: automatyzuj tam, gdzie koszt pomyłki jest niski albo pomyłkę łatwo wykryć i cofnąć. Redagowanie, streszczanie, ekstrakcja, klasyfikacja, routing — dobrzy kandydaci. Zły szkic się edytuje; złe streszczenie wyłapuje się przy czytaniu. Bądź znacznie ostrożniejszy tam, gdzie błędy są kosztowne, trudne do wykrycia lub nieodwracalne: cokolwiek, co przesuwa pieniądze, wysyła nieodwołalną komunikację albo podejmuje decyzję prawną czy medyczną. Tam model przynależy do roli wspomagającej — wypływanie opcji, redagowanie do przeglądu — a nie za kierownicą.
Linia, której się trzymamy: jeśli nie potrafisz opisać, jak wyłapałbyś, że model się myli, nie jesteś gotów, by ten krok zautomatyzować. Zdolność do wykrycia awarii jest prawdziwym warunkiem wstępnym, bardziej niż sama dokładność. Krok o 95% dokładności, który możesz w pełni zweryfikować, jest bezpieczniejszy do wdrożenia niż taki o 99% dokładności, którego zweryfikować nie możesz.
Kształt tej pracy
Przekucie promptu w produkt to w większości ta nieefektowna część: ewaluacje, żeby móc mierzyć, zabezpieczenia, żeby awarie pozostawały opanowane, budżety, żeby było szybko i przystępnie, ludzie ulokowani tam, gdzie osąd ma znaczenie, oraz dyscyplina, by pewne rzeczy zostawić niezautomatyzowane. Model to może dwadzieścia procent systemu. Pozostałe osiemdziesiąt to inżynieria, która sprawia, że na jego okazjonalną błyskotliwość można bezpiecznie polegać.
Dobra wiadomość jest taka, że to znajoma praca. Nagradza te same instynkty, które tworzą dobre oprogramowanie każdego rodzaju: mierz, zanim zmienisz, ogranicz promień rażenia, szanuj czas swoich użytkowników. Model jest nowy. Rzemiosło nie.