Kupić produkt AI czy budować wokół systemów, które już działają

Zwykle są trzy opcje

Pytanie brzmi zwykle: kupić czy zbudować, ale większość zespołów wybiera spośród trzech rzeczy. Gotowy produkt ma własny interfejs, własny przebieg pracy i własny model. Rozwiązanie składane kupuje dostęp do modelu i elementy platformy, a buduje tylko warstwę procesu, która łączy je z waszymi systemami. Głębsza budowa dokłada własne modele albo własną infrastrukturę inferencji. Przy automatyzacji procesów warto przetestować opcję środkową, bo porównywalny dostęp do modeli sprzedaje kilku dostawców, a połączenia z waszym systemem szkód, ERP czy zgłoszeń nie ma nigdzie indziej.

Pytania, które rozstrzygają

• Czy przebieg pracy w produkcie pasuje do waszego? Przyjęcie procesu dostawcy jest w porządku przy pracy standardowej, takiej jak notatki ze spotkań. Robi się drogie, gdy wasz proces zawiera reguły, których produkt nie potrafi wyrazić.
• Czy sięga do danych bez kopii? Produkt, który potrzebuje eksportu waszych rekordów, dokłada przepływ danych do zatwierdzenia i synchronizacji. AWS Generative AI Lens zaleca, by przy wyborze modelu poznać zasady wykorzystania danych przez dostawców hostujących modele.
• Kto decyduje, co się dzieje przy błędzie? Sprawdźcie, czy i w jakim stopniu produkt pozwala ustawić progi pewności i ścieżki eskalacji. Jeśli obsługa błędów musi podlegać regułom, których produkt nie potrafi wyrazić, potrzebujecie kontroli nad tą warstwą.
• Do czego dostawca naprawdę się zobowiązuje? Książka Google SRE podsuwa szybki test: jeśli niedotrzymanie celu nie ma konsekwencji, jest to cel, a nie umowa.
• Czy dostawca uruchomi wasze odłożone przypadki przed podpisaniem umowy? Bez tego porównujecie dema.
• Ile kosztuje obsłużona sprawa przy waszym wolumenie? FinOps Foundation opisuje dojrzałe unit economics jako moment, w którym koszt jednostkowy zaczyna kształtować decyzje o zakupie lub budowie, zamiast być raportowany po nadejściu rachunku.

Co utrzymujecie po podpisaniu umowy

Sculley i współpracownicy z Google opisali w 2015 roku, jak systemy uczenia maszynowego gromadzą stałe koszty utrzymania przez zależności od danych, zmiany w świecie zewnętrznym i niezgłoszonych konsumentów. To, ile tej pracy przejdzie na dostawcę, zależy od produktu i umowy, więc traktujcie poniższą listę jako pytania do każdego kandydata.

• Model i prompty: przy zakupie sprawdźcie, kto je kontroluje i czy umowa wymaga powiadomienia, zanim dostawca je zmieni. Przy budowie są wasze, łącznie z przejściem na nowy model, gdy stary zostaje wycofany.
• Integracja: sprawdźcie, czy konektory do waszych systemów utrzymuje dostawca, czy wy. Tak czy inaczej ktoś musi dbać o ich działanie, gdy te systemy się zmieniają.
• Zestaw testowy: w obu przypadkach wasz. Przy zakupie to nim sprawdzacie, czy aktualizacja dostawcy nie pogorszyła wyników.
• Proces weryfikacji i obsługa błędów: w obu przypadkach wasze. Zanim się zobowiążecie, sprawdźcie, na ile produkt pozwala je kształtować.

Hipotetyczna decyzja przy przyjmowaniu szkód

Załóżmy, że ubezpieczyciel przyjmuje zgłoszenia szkód e-mailem i przez portal. Przy każdym trzeba sklasyfikować dokumenty, wyciągnąć kluczowe pola, sprawdzić kompletność względem polisy i założyć sprawę w systemie szkód, który ma API. Przyjmijmy, że testowany produkt do przetwarzania dokumentów dobrze wyciąga pola, ale jego kolejka weryfikacji leży poza systemem szkód i nie widzi warunków polisy. Likwidatorzy pracowaliby w dwóch narzędziach, a kompletność nadal sprawdzaliby ręcznie.

Rozsądny podział to kupić ekstrakcję, która jest generyczna, i zbudować warstwę procesu: sprawdzanie kompletności względem danych polisy, kierowanie spraw i weryfikację w systemie szkód, w którym likwidatorzy i tak pracują. Ubezpieczyciel utrzymuje wtedy warstwę procesu i zestaw testowy, a dostawca ekstrakcję. Czy to lepsze od każdej z czystych opcji, zależy od wolumenów i cen, które ubezpieczyciel musi zmierzyć, a nie założyć.

Jak każdy wybór może zawieść

Kupiony produkt, który nie pasuje do procesu, zwykle zawodzi po cichu przez obejścia: pracownicy kopiują wyniki między narzędziami, prowadzą boczne arkusze i nikt nie widzi, dlaczego sprawa poszła źle. Własna budowa zawodzi przez nieplanowane utrzymanie albo przez warstwy frameworków, które ukrywają prompty i odpowiedzi, przed czym ostrzega artykuł Anthropic o agentach z 2024 roku. Oba warianty zawodzą, gdy zespół projektowy odchodzi i nikt nie odpowiada za system.

Porównanie w ograniczonym czasie przed podpisaniem umowy

W uzgodnionym z góry okresie przepuśćcie te same odłożone przypadki przez wersję próbną dostawcy i przez prosty prototyp zbudowany na hostowanym modelu i waszym własnym API. Porównajcie jakość, koszt weryfikacji, koszt obsłużonej sprawy i listę tego, co musielibyście utrzymywać. Jeśli produkt wygrywa we wszystkich czterech punktach, kupcie go i zachowajcie zestaw testowy. Nasza praca w obszarze AI engineering obejmuje stronę budowy, z warstwą procesu działającą w waszym środowisku.

Planowanie odejścia od dostawcy AIKto odpowiada za system AI po pilotażu