Każda organizacja, z którą rozmawiamy, ma folder z proof of concept AI, które pięknie wypadły w demie, a potem po cichu umarły. Wzorzec jest na tyle stały, by go nazwać: prototyp nigdy nie był trudną częścią. Model, który dobrze odpowiada na wyselekcjonowany prompt w notebooku, spełnił dopiero minimalne wymagania projektu.
Ostatnie dziesięć procent to większość pracy
Prototyp odpowiada na jedno pytanie: czy model w ogóle potrafi to zrobić? Produkcja odpowiada na trudniejsze: czy potrafi robić to dalej, wystarczająco poprawnie, na danych wejściowych z rzeczywistego świata, bez człowieka sprawdzającego każdą odpowiedź? Odległość między tymi dwoma pytaniami to miejsce, gdzie znikają budżety, bo jest pełna pracy, której żadne demo nie pokazuje: ewaluacja, retrieval, który nie traci aktualności, opóźnienie i koszt pod obciążeniem oraz zachowanie, gdy zmieni się model lub API, na których się opierasz.
Czego naprawdę wymaga produkcja
Przekształcenie prototypu w system oznacza zbudowanie części, których nikt nie pokazuje w demie:
- Ewaluacja. Powtarzalny sposób, by stwierdzić, czy zmiana --- nowy prompt, aktualizacja modelu, reranker --- poprawiła czy pogorszyła wyniki, zanim zrobią to Twoi użytkownicy. Bez niej każda zmiana to zgadywanie, a regresje trafiają na produkcję po cichu.
- Halucynacje i guardrails. Prawdziwe dane wejściowe rodzą przekonująco brzmiące, ale błędne odpowiedzi. System musi opierać odpowiedzi na źródłach, gdzie to możliwe, ograniczać to, co modelowi wolno, i korzystać z fallbacku zamiast upierać się przy odpowiedzi.
- Retrieval i pipeline'y danych. Odpowiedź RAG jest tylko tak dobra, jak stojący za nią indeks. Dokumenty się zmieniają, a embeddingi tracą aktualność, więc wczorajsza poprawna odpowiedź po cichu staje się dzisiejszą błędną, chyba że pipeline utrzymuje ją w aktualności.
- Opóźnienie i koszt. Jedno żądanie w notebooku jest szybkie i darmowe. Tysiąc równoczesnych użytkowników sprawia, że koszt tokenów i tail latency stają się ograniczeniem, które decyduje, czy rzecz w ogóle trafi na produkcję.
- Awarie i bezpieczeństwo. Dostawcy nakładają rate limity, wycofują modele i zmieniają zachowanie bez uprzedzenia; dane wejściowe próbują obejść ograniczenia promptu (jailbreak). Graceful degradation i least privilege zaprojektowane od początku, a nie doklejone później, to cechy produkcyjne, a nie dodatki.
Projektuj od razu z myślą o drugim systemie
Zespoły, które pokonują tę przepaść, robią jedną rzecz inaczej, i jest ona subtelniejsza, niż brzmi. Nie budują wcześnie infrastruktury produkcyjnej --- żadnego przedwczesnego Kubernetesa, żadnej skalowanej bazy wektorowej dla stu dokumentów. Wcześnie podejmują natomiast decyzje architektoniczne z myślą o produkcji: gdzie trafiają mechanizmy ewaluacji, jak retrieval pozostaje aktualny, co dzieje się, gdy model się myli, które dane mogą opuścić firmę. Prototyp pozostaje tani i tymczasowy; architekturę wokół niego wybiera się z myślą już o systemie produkcyjnym.
Typowy przykład to asystent triage'u wsparcia, który osiągnął 95% na zbiorze testowym kilkuset zgłoszeń. Na produkcji zetknął się z prawdziwym językiem, załącznikami i zgłoszeniami wielojęzycznymi, dokumenty wykorzystywane przez retrieval zdążyły od czasu ewaluacji stracić aktualność, a dostawca po cichu zaktualizował wersję modelu --- dokładność spadła poniżej poziomu, przy którym zespół wsparcia mógł jeszcze nadążać, i nie było systemu ewaluacji, by to wychwycić. W prototypie nic nie było złe; po prostu nie miał jak przetrwać pierwszego kontaktu z rzeczywistym ruchem.
To nie fanaberia; to różnica między prototypem, który można rozwijać, a takim, który trzeba wyrzucić. Wybór tej ścieżki wcześnie to zwykle najtańsza decyzja w całym projekcie.