Benchmark chwali model, rozmowa pozwala mu się zgubić

Jennifer Neville z Microsoft Research zwraca uwagę, że typowe benchmarki AI sprowadzają pracę do jednego idealnie opisanego polecenia. W prawdziwej rozmowie ludzie doprecyzowują wymagania stopniowo, a według jej badań wydajność modeli wyraźnie spada.

Microsoft testuje modele w rozmowach, które zmieniają się po drodze

Neville kieruje w Microsoft Research zespołem AI Interaction and Learning. W podcaście opisuje jego cel: sprawdzać granice działania AI w realistycznym środowisku pracy, badać doświadczenia użytkowników i na podstawie wykrytych luk ulepszać algorytmy oraz modele. Ma na koncie ponad 130 publikacji i przeszło 10 000 cytowań, więc rozmowa opiera się na wieloletnich badaniach nad danymi strukturalnymi i interakcjami, a nie na wrażeniach z chatbota.

Zespół bada interakcje multiturn, współpracę i długie zadania. W jednym z projektów naukowcy wzięli publiczne benchmarki single-turn, rozłożyli kompletne polecenie na kilka tur i wykorzystali symulowanych użytkowników, którzy stopniowo dodawali warunki oraz wyjaśnienia. Neville mówi, że współczesne modele radziły sobie w takim układzie wyraźnie gorzej niż po otrzymaniu jednego pełnego polecenia.

Tak właśnie zachowują się ludzie. Użytkownik często nie zna pełnej specyfikacji na początku i odkrywa ją podczas pracy. Benchmark z gotowym promptem mierzy zdolność rozwiązania starannie przygotowanego problemu, natomiast produkt musi przetrwać także proces powstawania samego zadania.

Evals powinny odtwarzać pracę, a nie wygodę laboratorium

Wniosek dla zespołów produktowych jest praktyczny. Wynik statycznego benchmarku mówi zbyt mało o agencie, który ma zachować intencję przez wiele kroków, przyjmować poprawki i współpracować nad dokumentem. Evaluation powinna odtwarzać prawdziwy tok pracy, wraz z niepełnymi instrukcjami, zmianami celu i długim kontekstem.

Neville wskazuje też przewagę laboratorium przemysłowego. Microsoft może razem z zespołami produktowymi analizować na dużą skalę wzorce sukcesów i porażek w logach konsumenckich. Na tej podstawie powstają testy skierowane w rzeczywiste problemy użytkowników. To cenniejsze niż kolejny zestaw pytań, których odpowiedzi mogły już znaleźć się w danych treningowych.

Konsekwencje dotyczą również UX. Dopóki modele gubią się w długiej rozmowie, interfejs powinien podsumowywać zatwierdzone wymagania, pokazywać zmiany planu i proponować czysty restart z pełnym opisem zadania. Neville podaje to jako praktyczną radę na dziś: gdy chat zaplącze się po wielu turach, warto zacząć od nowa z wiedzą zdobytą po drodze.

Symulowany użytkownik nadal nie jest prawdziwym współpracownikiem

Rozłożenie benchmarku single-turn na wiele tur pozwala wyizolować ważną zmienną, ale pozostaje symulacją. Prawdziwi ludzie zmieniają zdanie, pomijają informacje, używają firmowych skrótów i oceniają wynik po skutkach w pracy. Test może ujawnić utratę kontekstu, lecz sam nie dowodzi, że model dobrze współpracuje.

Analiza logów użytkowników rodzi też pytania o prywatność, reprezentatywność i definicję sukcesu. Telemetria produktu potrafi wskazać częstą awarię. Bez badań jakościowych może jednak nie wyjaśnić, dlaczego użytkownik przerwał pracę, ręcznie poprawił wynik albo już nie wrócił.

Produktowe evals muszą mierzyć całą drogę do wyniku

Postęp będzie widać w benchmarkach obejmujących kilka rund doprecyzowań, pracę z dokumentami, powrót po błędzie i końcową korzyść dla człowieka. Liczy się także przejrzystość: opublikowany protokół, porównywalne modele i wyniki rozbite według typu zadania zamiast jednego zbiorczego wskaźnika.

Zespół wdrażający AI potrzebuje więc obok benchmarku dostawcy własnego eval opartego na śladach prawdziwej pracy oraz regularnego przeglądu zaskakujących porażek. W produkcji model nie spotyka schludnego testu. Spotyka człowieka, który dopiero w trakcie rozmowy odkrywa, czego potrzebuje.

Werdykt Lilith

Benchmark wręcza modelowi gotowy scenariusz. Produkcja przysyła współpracownika, który w czwartej turze zmienia zdanie, i właśnie wtedy wychodzą prawdziwe możliwości modelu.