Zanim ktoś zbuduje Wam aplikację AI, ustalcie, czyja będzie

O przekazaniu zwykle rozmawia się w ostatnim miesiącu projektu, gdy jest już za późno, żeby zmienić cokolwiek istotnego. Kod leży wtedy tam, gdzie umieścił go dostawca, wdrożenie działa na infrastrukturze skonfigurowanej przez kogoś innego, prompty są w narzędziu, którego Wasz zespół nigdy nie otworzył, a jedyni ludzie rozumiejący, dlaczego system zachowuje się tak, a nie inaczej, właśnie przechodzą do innego klienta.

Nie ma w tym złej woli. Tak po prostu wychodzi, gdy własność traktuje się jako wydarzenie na końcu, a nie warunek od początku.

Dlaczego w aplikacjach AI jest gorzej

Zwykła aplikacja ma kod i dane. Aplikacja AI ma do tego prompty, konfigurację wyszukiwania, przypadki ewaluacyjne, wybory modeli, ustawienia kosztowe i nagromadzoną wiedzę o tym, które niewygodne przypadki ją psuły i dlaczego. Wiele z tego żyje poza kodem i wiele nigdy nie zostaje spisane, jeśli nikt o to nie poprosi.

Ma też zależność, której zwykłe oprogramowanie rzadko ma: dostawcę modelu, którego produkty zmieniają się, są wycofywane i przeceniane w rytmie, na który nie macie wpływu. System podpięty bezpośrednio pod model jednego dostawcy ma ukrytą zależność — a jak bardzo ukrytą, okazuje się, gdy ten model się zmieni.

Co uzgodnić przed startem prac

Kod jest w Waszych repozytoriach od pierwszego commita. Nie trafia tam dopiero na końcu. Jeśli dostawca chce przez jakiś czas pracować we własnym repozytorium, to powód, żeby zapytać dlaczego.

Wdrożenie działa na Waszej infrastrukturze, z Waszymi sekretami. Klucze API, poświadczenia i środowiska należą do Was. Dostawca trzymający klucze do produkcji to dostawca, od którego nie da się odejść.

Model siedzi za interfejsem. Żeby zmiana dostawcy albo modelu była zmianą konfiguracji i ewaluacji, a nie przepisywaniem aplikacji.

Prompty, ustawienia wyszukiwania i przypadki ewaluacyjne są wersjonowane razem z kodem. Są częścią produktu. Jeśli żyją w panelu dostawcy, odchodzą razem z nim.

Wasi inżynierowie pracują obok od początku. Nie czytają podsumowania na końcu. Wiedza, która ma znaczenie w systemie AI, dotyczy głównie tego, dlaczego: dlaczego ten przypadek jest w zestawie ewaluacyjnym, dlaczego ten krok używa tamtego modelu. Przechodzi przez wspólną pracę, a nie przez samą dokumentację.

Zaangażowanie dostawcy maleje według spisanego harmonogramu. Z warunkami przekazania — co, w jakim formacie i do kiedy — uzgodnionymi, póki macie siłę negocjacyjną.

Infografika

Ustalcie to przed pierwszym commitem

• Wasze repozytoriaKod tam od pierwszego dnia, a nie przeniesiony na końcu.
• Wasza infrastruktura i sekretyPoświadczenia, klucze i środowiska w Waszych rękach.
• Model za interfejsemZmiana dostawcy to konfiguracja i ewaluacja, a nie przepisywanie.
• Prompty wersjonowane z kodemPrompty, ustawienia wyszukiwania i przypadki ewaluacyjne są częścią produktu.
• Wasi inżynierowie obokWasi ludzie pracują w projekcie, a nie czytają podsumowań.
• Spisany harmonogram przekazaniaCo, w jakim formacie i do kiedy — póki macie siłę negocjacyjną.

Pytania, które ujawniają zależność

„Gdybyście jutro zniknęli, czego nie moglibyśmy zrobić?” Dobry dostawca odpowie precyzyjnie, a uczciwa odpowiedź skraca się w miarę trwania projektu.

„Czego wymagałaby zmiana modelu?” Jeśli odpowiedź obejmuje przepisanie aplikacji, zależność jest strukturalna.

„Gdzie jest zestaw ewaluacyjny i kto może go uruchomić?” To najbardziej wartościowy artefakt w kodzie AI. Jeśli uruchomić go może tylko dostawca, tylko dostawca może bezpiecznie zmieniać system.

„Kto ma dziś dostęp do produkcji?” Z imienia i nazwiska. Każda osoba spoza Waszej organizacji powinna mieć powód i datę końcową.

Ile to kosztuje Was

Własność nie jest za darmo, a udawanie, że jest, kończy się przekazaniem, którego nikt nie jest w stanie odebrać. Potrzebujecie inżynierów z czasem przydzielonym do projektu — a nie pożyczonych z innej pracy na godziny, które akurat zostały — i kogoś po Waszej stronie, kto będzie odpowiadał za system, gdy dostawca się wycofa. Ta osoba powinna być znana z imienia i nazwiska, zanim podpiszecie umowę. Jeśli brakuje jednego lub drugiego, lepiej wiedzieć to przed startem i zaplanować, niż odkryć przy przekazaniu.

Jak wygląda dobry wynik

W dniu, w którym dostawca odchodzi, nic się nie zmienia. Wasz zespół wdraża, monitoruje i modyfikuje system, tak jak robi to od tygodni. Zestaw ewaluacyjny uruchamia się w Waszym CI. Model dałoby się wymienić w przyszłym kwartale bez osobnego projektu. Dostawca może wrócić przy kolejnym projekcie, ale nie dlatego, że bez niego nic nie działa.

Przy inżynierii aplikacji AI-native kod jest w Waszych repozytoriach od pierwszego commita, wdrożenie na Waszej infrastrukturze, sekrety są Wasze, model siedzi za interfejsem, a warunki przekazania uzgadniamy przed rozpoczęciem prac. Nasze zaangażowanie maleje według spisanego harmonogramu, bo tak ma być.