Szósta rano, czyli jak agenci uczyli się pytaniami

Zaczęło się od pytania, czy model może nauczyć się tematu tak, jak robi to człowiek, pytaniami, zamiast od razu wykładać całość gładko i po kolei. Kiedy się czegoś uczę, pytam o jedno słowo, potem o przykład, potem „a co, jeśli”, gubię się i wracam, więc pomyślałem, że skoro pytania mają swoje typy, to może da się to puścić samo: uczeń, który nic nie wie, ekspert, który odpowiada, i kurator, który pilnuje, żeby z tego wyszła nauka, a nie rozmowa o wszystkim (jak to działa, opisałem w rozwiązaniach).

Najlepiej zapamiętam przebieg, w którym uczeń, osoba, która nigdy nie programowała, miał zrozumieć krótki program do domowego budżetu, dwie klasy, pętla, słownik. Po kilkudziesięciu pytaniach wiedział sporo o systemie dwójkowym i indeksowaniu krotek, których w programie w ogóle nie było, a nie wiedział, czym jest program, bo sam o to nie zapytał, a nikt nie zawrócił go z bocznej ścieżki :-) Pomogło dopiero dopisanie do celów podstaw, od których ktoś taki musi zacząć.

Zostają ze mną dwie rzeczy. Najwięcej w tej zabawie robi kurator, który wie, czego szukamy, i pilnuje, żeby rozmowa nie odjechała, ekspert właściwie tylko odpowiada. A część reguł lepiej trzymać w kodzie niż w prośbie do modelu, bo poproszony o umiar i tak go nie zachowa. Skończyłem koło szóstej rano i położyłem się nieprzytomny, ale zadowolony.

Później drill-upem, czyli od gotowego kodu w górę, rozebrałem w osobnym artykule uproszczony program z samym drill-downem. Uczeń dopytywał o każdą linijkę, także o to, ile razy graf przechodzi przez swoje węzły i kiedy się zatrzymuje, więc w artykule wylądował dokładny opis tej pętli. Recenzent, który dostaje tylko tekst i niczego nie uruchamia, policzył z tego opisu, że przy domyślnym budżecie graf potrzebuje 31 kroków, a LangGraph domyślnie przerywa po 25, czyli że przykład wyłożyłby się w ósmej turze. Ja to przeoczyłem, upraszczając program, a błąd wyszedł sam, z pytań i analizy, zanim ktokolwiek uruchomił kod.