Kiedy obejście problemu z AI powinno zniknąć?

Trzy pytania do modelu stoją między ilustracyjnym asystentem integracyjnym a mapą pól. Pierwsze klasyfikuje żądanie. Drugie wybiera narzędzie. Trzecie przepisuje ten sam wybór w dłuższej formie. Sekwencję zbudowano, gdy model często mylił dwie operacje. Po aktualizacji modelu dodatkowe przekierowanie może dodawać opóźnienie, nie zapobiegając błędom.

Można to ustalić tylko przez przeprowadzenie tych samych zadań obiema drogami. Przyzwyczajenie nie jest dowodem wartości.

Prezentacja o produktach zmieniających się wraz z możliwościami modeli twierdzi, że produkt powinien poprawiać się razem z modelem. Opisuje też trudność usuwania znanych interfejsów. Wniosek nie brzmi „usuń każdą podporę”. Brzmi: sprawdź, czy podpora nadal zasługuje na miejsce.

Oddziel pomoc od uprawnienia

Stara pomoc może być promptem powtarzającym opisy narzędzi, routerem zawsze wybierającym tę samą operację lub sztywnym interfejsem do zadania, które model umie dziś lepiej wyjaśnić na żądanie. Jej rolą jest pomóc modelowi lub człowiekowi ukończyć pracę. Jeśli już nie pomaga, koszt utrzymania jest czystym narzutem.

Kontrola uprawnień jest inna. Rozstrzyga, czy działanie wolno wykonać. Model doskonale wybierający narzędzia nadal nie może sam przyznać sobie dostępu do danych innego sklepu. Model piszący bezbłędną aktualizację kontaktu nadal potrzebuje właściwego zatwierdzenia przed prawdziwym zapisem.

Wyjaśnienie MCP opisuje dostęp do narzędzi i jego koszt bezpieczeństwa. Zdolności modelu mogą zmienić sposób znajdowania narzędzia. Nie usuwają potrzeby ograniczania jego zakresu i walidowania wejścia.

To rozróżnienie chroni przed częstym błędem przy porządkowaniu produktu. Zespół widzi stary proces jako jedną warstwę i albo zachowuje całość, albo usuwa całość. Podziel go na pytania: co pomaga modelowi rozumować, co pomaga użytkownikowi zrozumieć, a co egzekwuje regułę poza modelem? Tylko pierwsze dwie części kwalifikują się do usunięcia dzięki nowym zdolnościom.

Uczciwe porównanie wymaga tych samych danych zadania i tych samych dozwolonych działań. Jeśli prostsza droga dostaje nowszy schemat lub szersze prawa, dobry wynik niewiele mówi o usuniętej warstwie. Dodaj błędy, dla których stworzono starą pomoc, i sprawdź, czy nowa droga wychwytuje je z tego samego powodu. Inaczej kilka zwykłych sukcesów może wymazać pamięć o potrzebie starej warstwy.

Porównuj całe zadania

Sam test porównawczy modelu nie wystarczy. Pytanie produktowe brzmi, czy ludzie kończą właściwe zadanie z mniejszą liczbą błędów, szybciej lub z jaśniejszymi dowodami.

Zbuduj mały zbiór scenariuszy: zwykłe mapowanie kontaktu, nieznane pole docelowe, konto z brakującymi uprawnieniami i prośbę o aktywację przed podglądem. Uruchom każdy z warstwą pomocniczą i bez niej. Sprawdź wywołania narzędzi, wyjaśnienia i decyzje o zatrzymaniu. Mierz opóźnienie i koszt obok poprawności.

Jeśli prosta droga jest równie dobra w zwykłych zadaniach, ale gorsza przy uprawnieniach, zachowaj zabezpieczenie. Jeśli pomoc nic nie zmienia i dodaje dwie sekundy, usuń ją. Jeśli ma znaczenie tylko przy jednej rzadkiej klasie żądań, ogranicz ją do tej klasy.

Uczciwy zarzut brzmi: „Ludzie nauczyli się starego interfejsu; usunięcie go tworzy nową pracę”. Tak. Znany element sterowania może pomagać człowiekowi nawet wtedy, gdy model już go nie potrzebuje. Obserwuj rzeczywiste ukończenie i zrozumienie zadania przez tych użytkowników. Stary interfejs może zostać z ludzkich powodów, ale trzeba te powody nazwać i sprawdzić.

Oddziel koszt obejścia od kosztu jego zmiany. Router może trochę opóźniać, lecz być tani w utrzymaniu; kruchy parser pisany ręcznie może wymagać pracy za każdym razem, gdy dostawca doda pole. Karta oceny może notować opóźnienie, błędy, nakład utrzymania i zrozumienie przez użytkowników. Wartości mają pochodzić z zadań produktu, nie z ogólnej tezy, że nowy model jest mądrzejszy.

Co stara pomoc nadal chroni?

1. Egzekwuje prawa lub zakres danych

   Zachowaj kontrolę

   Możliwości modelu nie nadają uprawnienia.

2. Pomaga tylko jednej klasie wyjątków

   Zawęź pomoc

   Stosuj ją tam, gdzie testy zadań pokazują wartość.

3. Nie zmienia żadnego sprawdzonego wyniku

   Usuń pomoc

   Zlikwiduj opóźnienie i utrzymanie bez wartości.

Usuń obejście świadomie

Bezpieczne usunięcie ma punkt odniesienia i drogę powrotu. Zapisz wyniki starej ścieżki dla tych samych scenariuszy, przełącz nową ścieżkę dla ograniczonej grupy i obserwuj błędy. Pozostaw stare zachowanie dostępne wystarczająco długo, aby zdiagnozować regresję. To zwykłe kontrole produktu, nie obietnica, że postęp modelu unieważnia każdą funkcję.

Przewodnik Tajo po reverse ETL wyznacza przydatną granicę: powtarzalne przenoszenie danych należy do stabilnego pipeline’u. Mocniejszy model może lepiej proponować lub wyjaśniać mapowanie. Nie czyni wywołania modelu dla każdego rekordu lepszym mechanizmem transportu.

Kosztem tej dyscypliny są okresowe ponowne testy. Zyskiem jest produkt, który nie nosi bez końca obejść wczorajszych modeli.

Postęp modelu powinien usuwać mozolną pracę, nie reguły.

Przy każdej pozostawionej warstwie zapisz krótki powód. „Ten krok powstrzymuje nieuprawnione zapisy” pozostaje prawdziwe, gdy model się poprawia. „Ten krok kompensuje mylenie dwóch narzędzi przez model” powinno uruchomić nowy test przy zmianie modelu. Taki mały spis zamienia przyszłe porządki w powtarzalną decyzję zamiast sporu o to, czy stary projekt jest znajomy.