Podłączanie OpenAI lub Anthropic do Twojego produktu: wybór, zachęta i kontekst, na który nikt nie przeznacza budżetu

Który dostawca – OpenAI czy Anthropic – jest pytany podczas niemal każdej rozmowy inauguracyjnej, jakby to była najważniejsza decyzja w projekcie. Rzadko tak jest. Obydwa APIs generują strukturalne wyniki, oba wywołują narzędzia/funkcje, oba przesyłają strumieniowo, a istotne różnice – rozmiar okna kontekstu, cena za token, to, jak ściśle model podąża za schematem, jak zachowuje się w przypadku niejednoznacznych instrukcji – są ustalane na podstawie testowania rzeczywistych podpowiedzi z rzeczywistymi danymi, a nie na podstawie tabeli wyników testu porównawczego.

Decyzje, które faktycznie kształtują kompilację, zapadają później: w jaki sposób zachęta jest zapisywana i wersjonowana jak kod, a nie poprawiana na placu zabaw i zapominana, w jaki sposób sprawdzana jest odpowiedź, zanim aplikacja jej zaufa, oraz w jaki sposób zarządzasz kontekstem, gdy konwersacja, dokument lub zadanie wsadowe przekracza to, co mieści się w jednym wywołaniu.

1. Decyzja OpenAI kontra Anthropic rzadko kiedy ma znaczenie

Wybieram na podstawie zadania, a nie lojalności wobec marki: która obsługa ustrukturyzowanych wyników jest bardziej rygorystyczna w przypadku potoku zawierającego dużo schematów, które okno kontekstowe faktycznie musi pomieścić dany dokument, który poziom cenowy przetrwa oczekiwaną liczbę połączeń i – niedoceniane – które zachowanie odmowy pasuje do przypadku użycia związanego z drażliwym tematem. Dwóch różnych dostawców może „pracować” w wersji demonstracyjnej i znacznie się od siebie różnić, gdy prawdziwi użytkownicy prześlą prawdziwe przypadki Edge.

Trzymam dostawcę za jednym cienkim adapterem w bazie kodu, więc ta decyzja jest odwracalna. Klient proszący o zmianę dostawcy po sześciu miesiącach z powodu zmiany cen, limitu stawek lub wycofania modelu powinien oznaczać zmianę konfiguracji i serię szybkich testów regresyjnych, a nie przepisanie.

2. Szybka inżynieria to specyfikacja, którą należy przetestować

Podpowiedź, która żyje w głowie jednego programisty, jest ulepszana na czacie i wyświetlana, gdy „wygląda prawidłowo” w trzech przykładach, staje się problemem w momencie, gdy ruch przekroczy te trzy przykłady. Piszę podpowiedzi w postaci plików z wersjonowaniem, z małym zestawem testowym rzeczywistych danych wejściowych i oczekiwanych kształtów wyników, a następnie poddaję je testom regresyjnym w taki sam sposób, jak w przypadku funkcji - zwłaszcza przed zmianą modeli lub dostawców.

Ustrukturyzowane dane wyjściowe i wywoływanie narzędzi/funkcji zmieniają podpowiedź w coś, co w ogóle można przetestować: zamiast oceniać dowolny tekst na podstawie wzroku, sprawdzam, czy ładunek JSON pasuje do schematu i czy zawarte w nim wartości spełniają reguły biznesowe. To jest faktyczny rezultat „szybkiej inżynierii” w przypadku prawdziwego projektu, a nie mądry akapit.

3. Zarządzanie kontekstem: część, na którą nikt nie przeznacza budżetu

Każda integracja LLM w końcu spotyka się z konwersacją, dokumentem lub zadaniem wsadowym większym niż okno kontekstowe, a to, co dzieje się dalej, decyduje o tym, czy funkcja pozostanie tania i dokładna, czy też działa powoli i zaczyna mieć halucynacje. Naiwne dodawanie każdej wiadomości do historii działa w wersji demonstracyjnej, a potem cicho się psuje: koszty rosną na turę, opóźnienia rosną wraz z nią, a po przekroczeniu pewnego punktu model zaczyna tracić kontrolę nad rzeczywistym pytaniem ukrytym pod starymi zakrętami.

Poprawka polega na połączeniu przycinania starych tur, podsumowywania tego, co wydarzyło się wcześniej, zamiast odtwarzania tego ponownie, oraz pobierania tylko odpowiedniego wycinka poprzez osadzanie i wektorową bazę danych, gdy źródłem jest dokument, a nie rozmowa. Dane wejściowe multimodalne — obraz lub strona PDF — to po prostu inny rodzaj kontekstu, którym można zarządzać w ten sam sposób: liczy się w tym samym oknie i wymaga tej samej dyscypliny co do tego, co faktycznie musi się tam znajdować.

Wniosek: wywołanie API to najmniejsza część integracji

Podłączenie LLM do produktu w większości nie polega na wywołaniu modelu - to adapter umożliwia wymianę dostawcy, zachęta traktowana jako przetestowana specyfikacja, schemat wychwytujący zniekształconą odpowiedź, zanim dotrze ona do użytkownika, oraz strategia kontekstu, która działa po pierwszej łatwej rozmowie demonstracyjnej. Buduję to wszystko wokół OpenAI lub Anthropic, które faktycznie pasuje do tego zadania. Wpisz w formularzu, co chcesz, aby LLM zrobiło w Twoim produkcie, a powiem Ci, czego tak naprawdę wymaga integracja.