LLM‑First czy Code‑First? Gdzie inteligencja należy w produkcyjnym AI

Jak zdecydować, co model ma obsługiwać, co Twój kod ma obsługiwać i jak połączyć te dwa elementy.

Kilka lat temu architektura aplikacji AI wyglądała tak: wysłać zapytanie do dużego modelu językowego -> otrzymać odpowiedź -> pokazać ją użytkownikowi. To już nie cała historia. Modele są proszone o interpretację intencji, pobieranie informacji, wybór narzędzi, wywoływanie interfejsów API, tworzenie planów i prowadzenie wieloetapowych przepływów pracy.

Ta zmiana podzieliła dziedzinę na dwie części – LLM‑First lub Code‑First

W architekturze LLM‑First model znajduje się w centrum i decyduje, co nastąpi dalej. Czyta żądanie, wybiera narzędzie, określa kolejność operacji, sprawdza wyniki pośrednie i zmienia kurs, gdy jest to konieczne.

W architekturze Code‑First oprogramowanie/kod pozostaje odpowiedzialny za sekwencjonowanie, reguły biznesowe, walidację, uprawnienia i wykonywanie. LLM w tym przypadku jest jak specjalista, którego kod wywołuje, gdy potrzebne jest rozumienie języka lub generowanie tekstu.

Ludzie lubią debatować, która opcja jest lepsza. Uważam, że to niewłaściwa dyskusja. Lepsze pytanie brzmi, gdzie należy każda forma inteligencji. Najsilniejsze systemy produkcyjne, które widziałem, rzadko są czysto jedną z nich. Łączą rozumowanie probabilistyczne z kontrolą deterministyczną i robią to celowo.

Dlaczego LLM‑First jest tak atrakcyjny

Tradycyjne oprogramowanie działa znakomicie, gdy można precyzyjnie określić wymagania. Na przykład użytkownik wybiera produkt, wprowadza kwotę i dokonuje płatności. W kodzie definiujesz dozwolone stany, reguły walidacji, warunki błędów i kolejność transakcji. Gotowe.

Język naturalny nie współpracuje w ten sposób. Wyobraź sobie użytkownika wpisującego: „Znajdź transakcje, które wydają się nietypowe, wyjaśnij, co się stało, i powiedz, co powinienem najpierw zbadać.”

Nie ma ustalonej ścieżki dla takiego żądania. System musi zdecydować, co oznacza „nietypowe”, określić, które dane są istotne, ewentualnie wywołać kilka narzędzi, ocenić odpowiedź i napisać wyjaśnienie, którego może użyć człowiek. Żaden zespół inżynierów/żaden kod nie będzie w stanie przewidzieć każdej formułacji i każdej kombinacji zapytań z wyprzedzeniem.

To jest miejsce, w którym LLM odgrywa kluczową rolę, działając jako elastyczna warstwa rozumowania pomiędzy językiem człowieka a Twoimi deterministycznymi usługami. To także powód, dla którego agenci przyciągają tak dużą uwagę. wytyczne architektury agentowego AI Google Cloud opisuje agenta jako aplikację, w której model AI działa jako silnik rozumowania, a narzędzia umożliwiają mu dostęp do zewnętrznych systemów i danych.

Anthropic’s Budowanie skutecznych agentów AI wytyczne wprowadza rozróżnienie, do którego ciągle wracam. przepływ pracy, modele i narzędzia podążają ścieżkami określonymi przez Twój kod. agencie, LLM kieruje własnym procesem i decyduje, jak używać swoich narzędzi. Te same wytyczne zalecają rozpoczęcie od najprostszej architektury rozwiązującej problem, zamiast dodawać złożoność agentową odręcznie. Podkreśliłbym tę radę dwukrotnie.

Ograniczenia “Pozwól modelowi decydować”

Model może rozumować o tym, co powinno się wydarzyć. Rozumowanie nie jest tym samym co egzekwowanie reguły.

Na przykład weźmy przepływ finansowy. LLM może doskonale rozumieć „wyślij tę samą kwotę, którą wysłałem w zeszłym miesiącu do tego samego dostawcy”. Czy jednak powinien również decydować, czy przelew jest autoryzowany, obliczać limity regulacyjne, weryfikować własność konta, obejść politykę bezpieczeństwa i wykonać transakcję?

Raczej nie. Te zadania są deterministyczne, testowalne, audytowalne i wymuszalne, i to właśnie tradycyjne oprogramowanie robi najlepiej. Ryzyko rośnie, gdy modele zyskują dostęp do narzędzi. wytyczne bezpieczeństwa generatywnej AI OWASP oznacza nadmierna autonomiczność jako istotne ryzyko: przyznawanie systemowi opartego na LLM większej funkcjonalności, uprawnień lub autonomii niż wymaga tego zadanie. Dziwny lub zmanipulowany wynik modelu to jedno, gdy generuje tekst. To znacznie poważniejsze, gdy model może działać w rzeczywistym świecie.

To nie oznacza, że modele nigdy nie powinny podejmować działań. Oznacza to, że autonomia modelu powinna być ograniczona przez deterministyczny autorytet.

Code‑First wciąż ma znaczenie

Z tak szybkim rozwojem AI łatwo odnieść wrażenie, że tradycyjne inżynierstwo przestało być modne. Ja twierdzę, że jest odwrotnie. AI sprawia, że dobre systemy deterministyczne stają się ważniejsze, nie mniej.

Kod nadal jest właściwym wyborem, gdy zadanie wymaga dokładnej powtarzalności. Autoryzacja jest najprostszym przykładem. Model nie powinien „rozumować” tego, czy ktoś ma uprawnienia administratora. Twoja aplikacja powinna zapytać autorytatywny system zarządzania tożsamością i dostępem. To samo dotyczy obliczeń finansowych, weryfikacji uprawnień, walidacji danych, ograniczeń regulacyjnych, limitów transakcji, walidacji schematów i wszystkiego, co jest nieodwracalne. To wymaga wyraźnych kontraktów, a nie domysłów.

To wpisuje się w szersze myślenie o zarządzaniu. NIST AI Risk Management Framework wymaga od organizacji zarządzania ryzykiem AI na etapach projektowania, rozwoju, wdrażania i użytkowania. Jego towarzysz Generative AI Profile dodaje, że systemy generatywne mogą wymagać dodatkowego nadzoru, dokumentacji, przeglądu i kontroli, w zależności od poziomu ryzyka.

Dlatego uważam za pomocne podzielenie każdej decyzji projektowej na dwa pytania:

Co powinno się stać?

i

Co może się stać?

LLM często może pomóc w pierwszym. Deterministyczne systemy powinny zazwyczaj odpowiadać za drugie.

Wzorzec hybrydowy: rozumowanie probabilistyczne, wykonanie deterministyczne

Dla większości aplikacji korporacyjnych praktycznym rozwiązaniem jest podejście hybrydowe. LLM pełni rolę warstwy interpretacji i rozumowania. Deterministyczne usługi działają jako warstwa wykonania i egzekwowania.

Przykład: asystent AI pomaga programistom tworzyć tymczasowe środowiska testowe API, a programista wpisuje: „Daj mi piaskownicę dla przepływu wdrażania klienta”.

LLM może to zinterpretować, ustalić, który przepływ jest prawdopodobnie zamierzony, przeczytać dokumentację i zasugerować, które API są prawdopodobnie istotne. Jednak faktyczne tworzenie środowiska nie powinno zależeć od swobodnie generowanego tekstu. Kod może potwierdzić istnienie żądanych API, zweryfikować ich kontrakty, sprawdzić autoryzację, wymusić limity zasobów, wygenerować zatwierdzoną konfigurację i uruchomić wdrożenie.

Przybliżony podział wygląda następująco:

• LLM: rozumie, rozumuje, klasyfikuje, proponuje, podsumowuje.
• Kod: waliduje, autoryzuje, oblicza, przechowuje, egzekwuje, wykonuje.

Każda ze stron wykonuje zadania, w których jest najlepsza, i żadna nie jest zmuszana do udawania mocnych stron drugiej.

Granice mają większe znaczenie, gdy agenci stają się potężniejsi

To rozdzielenie staje się ważniejsze, gdy przechodzimy od asystentów do agentów. Asystent, który udzieli złej odpowiedzi, tylko utrudnia komuś pracę. Agent z prawem zapisu w środowisku produkcyjnym może spowodować znacznie większy bałagan.

Rozwiązanie nie polega koniecznie na usunięciu autonomii. Chodzi o stopniowe wprowadzanie autonomii przy zachowaniu wyraźnych punktów kontrolnych. wytyczne Google dotyczące systemów wieloagentowych zaleca łączenie dynamicznego zachowania AI z deterministycznymi kontrolami bezpieczeństwa, obserwowalnością, jasno określoną autonomią oraz nadzorem człowieka w scenariuszach krytycznych dla biznesu.

Zatwierdzenie przez człowieka może być również wbudowane w sam przepływ pracy, zamiast pełnić rolę nieformalnej siatki bezpieczeństwa. Microsoft’s agent framework documentation, na przykład, obsługuje wywołania narzędzi, które wstrzymują się, dopóki osoba nie zatwierdzi wyraźnie żądanej operacji.

Zasada jest prosta: im większe konsekwencje działania, tym silniejsze powinny być deterministyczne kontrole wokół niego.

Pięć pytań, które warto zadać przed powierzeniem zadania LLM

Gdy decyduję, czy komponent powinien być najpierw LLM, czy kodem, przechodzę przez następujące kwestie:

1. Czy zadanie ma jedną obiektywnie prawidłową odpowiedź? Jeśli tak, skłaniaj się ku deterministycznemu kodowi. Obliczenia podatkowe, uprawnienia i walidacja schematu nie powinny się zmieniać, gdy model odczyta je inaczej.
2. Czy obejmuje niejednoznaczny język lub nieustrukturyzowane informacje? Jeśli tak, LLM może wnieść rzeczywistą wartość.
3. Co się stanie, jeśli model się pomyli? Odpowiednia architektura podsumowania spotkania różni się znacznie od architektury inicjowania płatności.
4. Czy wynik można zweryfikować niezależnie? Plany generowane przez LLM stają się znacznie bezpieczniejsze, gdy deterministyczne reguły mogą sprawdzić wynikową akcję przed jej wykonaniem.
5. Czy naprawdę potrzebny jest agent? Jeśli znasz już kroki, zwykły przepływ pracy z kilkoma ukierunkowanymi wywołaniami LLM jest zazwyczaj prostszy, tańszy, łatwiejszy do testowania i obsługi.

To ostatnie pytanie wymaga dodatkowej uwagi. Agenci są potężni właśnie dlatego, że potrafią radzić sobie w sytuacjach, których nie da się przewidzieć krok po kroku. Ale jeśli można przewidzieć kroki, przekształcenie ich w otwarty problem rozumowania często wprowadza zmienność bez dodawania inteligencji.

Niezawodność jest właściwością architektoniczną, a nie podpowiedzią

Wiele zespołów zaczyna od próby zwiększenia niezawodności prawie wyłącznie poprzez inżynierię promptów. Prompt ma znaczenie, ale nie może unieść całego ciężaru.

System produkcyjny powinien zakładać, że wyjście modelu będzie czasami niekompletne, niepoprawne, nieoczekiwane lub po prostu błędne. OWASP Top 10 dla aplikacji LLM wymienia ryzyka takie jak wstrzyknięcie promptu i niewłaściwe obsługiwanie wyjścia, co podkreśla kluczowy nawyk: traktować wyjście modelu jako nieufne dane wejściowe dla systemów downstream, a nie jako instrukcje do automatycznego uruchomienia.

To zmienia zadawane pytanie. Zamiast „Jak napisać prompt, który zawsze sprawi, że model będzie przestrzegał reguły?”, zapytaj „Jak zaprojektować system, aby reguła nie mogła zostać złamana, nawet gdy model popełni błąd?”

To problem architektury oprogramowania, a nie problemu promptowania. Prompt może powiedzieć agentowi, aby nie wykonywał nieautoryzowanej akcji. Usługa autoryzacji może faktycznie ją zatrzymać. Te dwa mechanizmy nie są równoważne.

Poza debatą: systemy intencja‑pierwsze

Rozmyślając o tym wszystkim, doszedłem do wniosku, że debata LLM‑pierwsze kontra kod‑pierwsze wskazuje na trzecią koncepcję: intencja‑pierwszą architekturę.

W systemie intencja‑pierwszym aplikacja zaczyna od zrozumienia, co użytkownik chce osiągnąć. To właśnie miejsce, w którym LLM jest najcenniejszy, ponieważ ludzie rzadko precyzują, czego chcą. Stamtąd system stopniowo przekształca tę niejasność w ustrukturyzowane, deterministyczne operacje.

Żądanie takie jak „Pomóż mi rozwiązać problem płatności klienta” może przekształcić się w pipeline: zrozumienie intencji, pobranie transakcji, zidentyfikowanie przyczyny awarii, rekomendacja rozwiązania, żądanie zatwierdzenia, wykonanie zatwierdzonej operacji.

Niektóre z tych etapów korzystają z rozumowania modelu językowego. Inne powinny być stałymi usługami. Architektura nie jest definiowana przez to, czy AI czy kod „wygrywa”. Jest definiowana przez to, gdzie dopuszczalne jest niepewność.

Podsumowanie

W miarę jak modele się doskonalą, kuszące będzie przekazywanie im kontroli nad coraz większymi fragmentami stosu. Czasami będzie to właściwa decyzja. W innych systemach najbardziej zaawansowany projekt będzie tym, który świadomie przyznaje modelowi mniej uprawnień.

Inżynieria AI w produkcji, w ostatecznym rozrachunku, polega na umieszczaniu inteligencji we właściwej granicy. Stosuj modele językowe tam, gdzie interpretacja, rozumowanie, synteza i adaptacja przynoszą wartość. Stosuj oprogramowanie deterministyczne tam, gdzie liczy się spójność, autoryzacja, precyzja i egzekwowanie. Następnie połącz je za pomocą wąskich, obserwowalnych, dobrze przetestowanych interfejsów.

Przyszłość AI w przedsiębiorstwach prawdopodobnie nie będzie czysto LLM‑pierwsza ani czysto kod‑pierwsza. To LLM tam, gdzie niepewność wymaga inteligencji, oraz kod tam, gdzie pewność wymaga kontroli.

Ta rozróżnienie może mieć znacznie większe znaczenie niż wybór konkretnego modelu.