Od pracy eksperta do testowalnego procesu AI.
Większość projektów AI skupia się na tym, co model potrafi. My skupiamy się na tym, jak podchodzi do pracy.
Obserwować. Wydobywać. Budować. Testować.
Obserwujemy pracę
Zaczynamy od realnego zadania, procesu lub decyzji. Mogą to być wywiady, przykłady, historyczne przypadki, istniejące procedury, omówienia pracy z ekspertami lub syntetyczne przypadki testowe.
Wydobywamy wiedzę proceduralną
Identyfikujemy wzorce rozumowania stojące za pracą, uporządkowane wokół jej punktów decyzyjnych. Dla każdego z nich ustalamy:
- co robią tam doświadczeni ludzie zamiast oczywistego domyślnego ruchu,
- jakie zadają pytania i jakim dowodom ufają,
- progi i ustawienia, których faktycznie używają,
- które wyjątki zmieniają ścieżkę,
- oraz kiedy się zatrzymać lub kiedy niepewność powinna uruchomić eskalację.
Tam, gdzie kończą się dowody, pytamy ludzi, którzy wiedzą, zamiast zgadywać.
Budujemy proces rozumowania
Zamieniamy te wzorce w metodę i umieszczamy ją w procesie: z jakich dowodów może korzystać każda faza, co musi wytworzyć, kto ją akceptuje i kiedy przekazuje sprawę człowiekowi.
Następnie metodę wdrażamy pod model, na którym będzie działać. Ta sama metoda może być jednym wywołaniem modelu dla jednego modelu, a dla innego — kilkoma wyspecjalizowanymi etapami, agentami lub narzędziami.
Architektura podąża za zadaniem i modelem — nie za bieżącą modą na AI.
Testujemy na realnej pracy
Porównujemy system z:
- modelami bazowymi,
- istniejącymi procesami,
- decyzjami ekspertów,
- znanymi przypadkami,
- scenariuszami porażki,
- oraz istotnymi kryteriami wydajności.
Testujemy cały proces na przypadkach, na których nie był projektowany. Gdy zawodzi, znajdujemy punkt decyzyjny i sygnał, który przeoczył, zmieniamy jedną rzecz i testujemy ponownie — dzięki temu każdą poprawę można powiązać z konkretną zmianą.
Pytanie nie brzmi, czy system brzmi jak ekspert. Pytanie brzmi, czy zachowuje się użytecznie w realistycznych warunkach.
Prompt z rolą sprawi, że AI zabrzmi jak ekspert. To nie znaczy, że będzie się zachowywać jak ekspert.
Łatwo poprosić model, by „działał jak starszy konsultant”, „myślał jak inżynier jakości” albo „był sceptycznym recenzentem”. To może zmienić styl, a czasem poprawić wyniki.
Ale przy ważnej pracy bardziej użyteczne są inne pytania:
- Jakie procedury rozumowania powinien stosować system?
- Które z nich model bazowy wykonuje już niezawodnie?
- Które trzeba wywołać jawnie?
- W jakiej kolejności?
- Pod jakimi warunkami?
- Które procedury poprawiają wyniki?
- Które tylko zmieniają sformułowania?
- Gdzie system powinien się zatrzymać i przekazać decyzję człowiekowi?
Tu Impersonato różni się od generycznych promptów z rolą czy orkiestracji agentów.
Czego nauczyliśmy się o tym, co naprawdę zmienia zachowanie
- Reguły w konkretnych momentach, a nie osobowości. Instrukcje dotyczące ostrożności, wytrwałości czy momentu zatrzymania zmieniają to, co system robi, gdy są powiązane z konkretną sytuacją. Zapisane jako charakter, motyw czy ton, zmieniają głównie sformułowania.
- Metoda jako całość, a nie lista wskazówek. Procedura może przestać działać, gdy zgubią się jej ustawienia, reguły wyjścia lub znaczenie tego, co jeden krok przekazuje następnemu — nawet jeśli każdy z pozostałych kroków osobno wygląda poprawnie.
- Postępowanie, a nie wiedza. Procedury zmieniają to, co system robi w punktach decyzyjnych. Nie dają modelowi wiedzy, której mu brakuje. Tam, gdzie to jest granicą, mówimy o tym wprost.
Nie zakładamy, że inna rola daje lepsze myślenie. Sprawdzamy, co zmienia pracę.
Najpierw udowodnić rozumowanie.
Potem je wdrożyć.
Zacznijcie od sprintu badawczo-walidacyjnego
Zanim zbudujemy duży system, ustalamy, czy proponowana architektura rozumowania rzeczywiście poprawia pracę. Sprint może obejmować:
- zdefiniowanie zadania,
- zachowanie modelu bazowego,
- wywiady z ekspertami,
- wydobycie procedur rozumowania,
- prototyp procesu,
- syntetyczne lub realne przypadki testowe,
- ewaluację porównawczą,
- analizę porażek,
- rekomendację dotyczącą wdrożenia.
Efekt: przetestowany prototyp i dowody na to, czy podejście warto wdrażać.
Potem integracja tam, gdzie ma sens
Jeśli podejście się sprawdzi, proces można wdrożyć przez:
- API,
- dedykowaną aplikację,
- istniejące systemy korporacyjne,
- chmurę prywatną,
- VPC,
- lub wdrożenie on-premise.
Technologia jest na końcu.
Gdy rozumowanie zostanie udowodnione, działa na kontrolowanym środowisku uruchomieniowym: z kontraktem procesu dla każdej fazy, metodami skompilowanymi pod konkretny model, na którym działają, dowodami z przypadków wraz z ich pochodzeniem i uprawnieniami oraz bramkami przeglądu tam, gdzie decyzja należy do człowieka. Zmienia się tylko przez nowe wersje i ponowne testy, nigdy po cichu.
Macie pracę, w której jakość rozumowania ma znaczenie?
Porozmawiajmy o sprincie badawczo-walidacyjnym.