Jak działa przetestowany proces rozumowania.
Impersonato Cognitive Runtime zamienia zwalidowaną metodę w kontrolowany proces: właściwe dowody, właściwa procedura, właściwy model — i człowiek wszędzie tam, gdzie decyzja należy do człowieka.
Ta strona jest dla zespołów technicznych. Ogólny przegląd znajdziecie w sekcji Jak to działa.
To nie biblioteka promptów, person ani automatyzacji.
Runtime to kontrolowana ścieżka od dowodów organizacji do artefaktu, który można zaudytować, i do decyzji podjętej przez osobę uprawnioną do jej podjęcia. Obejmuje też dowody na to, kiedy tej ścieżki w ogóle nie należy używać.
Ma pięć warstw. Metoda rozumowania to tylko jedna z nich.
Proces biznesowy
Fazy pracy, to, co każda faza musi wytworzyć, i kto ją akceptuje.
Metody i aktorzy
Procedury rozumowania, które wykonują pracę, oraz specjaliści, aktorzy testowi lub panele, które je realizują.
Dowody przypadku
Co wiadomo o tym przypadku — i czego brakuje, co jest sprzeczne lub czego nie wolno używać.
Kompilator, modele i narzędzia
Ta sama metoda, zaimplementowana dla konkretnego modelu, dostawcy i narzędzi, na których działa.
Przegląd przez człowieka i nadzór
Prawa decyzyjne, uprawnienia, audyt i kontrola kosztów.
Zanim zacznie się rozumowanie: kiedy, z czym i kto decyduje.
Każda faza procesu jest opisana, zanim zostanie uruchomiona:
- kiedy faza ma zastosowanie i co musi być spełnione przed jej startem,
- jakich dowodów wolno użyć,
- jaka metoda się uruchamia,
- jaki artefakt musi powstać i jak jest sprawdzany,
- kto ma uprawnienia, by go zaakceptować,
- i co dzieje się dalej: przejście dalej, prośba o dowody, eskalacja lub zatrzymanie.
Metoda mówi systemowi, jak rozumować. Kontrakt procesu mówi organizacji, kiedy jej użyć i kto decyduje.
Metoda to coś więcej niż lista dobrych instrukcji.
Metoda jest zorganizowana wokół punktów decyzyjnych zadania. Dla każdego z nich określa:
- punkt decyzyjny — moment w pracy, w którym zapada wybór,
- ruch — co zrobić w tym miejscu zamiast domyślnego zachowania modelu,
- ustawienia — konkretne wartości i progi, dzięki którym ruch działa,
- bramki i reguły wyjścia — co musi być spełnione, zanim przejdziemy dalej, i kiedy się zatrzymać,
- co każdy krok przekazuje następnemu — i co ten wynik pośredni oznacza.
Usuńcie którykolwiek z tych elementów, a metoda może przestać działać, nawet jeśli każdy pozostały krok osobno wygląda poprawnie. Dlatego metody są projektowane, testowane i wersjonowane jako całość.
Reguły w nazwanych momentach, nie osobowości
Instrukcje dotyczące ostrożności, wytrwałości, ryzyka czy momentu zatrzymania zmieniają zachowanie, gdy są zapisane jako reguły powiązane z konkretnym zdarzeniem: gdy druga strona powtarza tę samą ofertę, zrób to. Ta sama treść zapisana jako osobowość, motyw czy ton głosu zmienia głównie sformułowania. Runtime preferuje formę reguły.
Wartość tkwi w metodzie jako całości — nie w żadnej pojedynczej instrukcji.
Trzy rodzaje aktorów, trzymane osobno.
Konfiguracje wielokrotnego użytku, które pomagają wykonać pracę.
Trwałe połączenie metod, reguł wiedzy, reguł zatrzymania i obowiązków przeglądowych. Testowane w porównaniu z prostymi opisami ról, a nie zakładane jako lepsze od nich.
Powtarzalne instrumenty do ewaluacji systemów.
Kontrolowani symulowani użytkownicy, utrzymywani w stałej postaci, podczas gdy testowany system się zmienia. Sposób nacisku, poziom presji i warunek kontrolny są ustalone i zapisane — i zawsze zostawiają systemowi możliwość odmowy.
Próbkowane panele do badania perspektyw.
Generowani na potrzeby badania, bez informacji o jego celu. Wielokrotnie używany jest projekt panelu i protokół wywiadu. Wspierają hipotezy i przygotowanie badań z udziałem ludzi — nie twierdzenia o tym, jak powszechny jest dany pogląd na prawdziwym rynku.
Każdy aktor widzi tylko te informacje, które wolno mu widzieć. Ukryte cele badania nie przeciekają przez wspólne prompty, historie ani narzędzia.
Jedna metoda. Inna implementacja dla każdego modelu.
Sześciokrokowa metoda może dla jednego modelu stać się jednym promptem, dla innego serią jawnych kontroli, a dla trzeciego wieloma wywołaniami z maszyną stanów. To implementacje tej samej metody, nie różne metody.
Kompilator może skracać, rozszerzać, dzielić lub wynosić części metody poza prompt. Nie może zmieniać tego, co metoda robi: jej decyzje, ustawienia, artefakty, ograniczenia informacji i chronione reguły muszą przetrwać. Przebudowana implementacja jest przyjmowana tylko wtedy, gdy odtwarza zachowanie tej, którą zastępuje.
Dokładny model i dostawca są częścią konfiguracji i są zapisywane. Gdy dla danego celu nie ma przetestowanej implementacji, wynik jest oznaczany jako eksperymentalny — albo nie jest używany.
Co wiemy o przypadku. Co wiemy o metodzie.
Co wiadomo o tym przypadku
Źródła, polityki, wcześniejsze przypadki, notatki ekspertów, sprzeczności i luki — każde z podaną genezą, wiekiem i uprawnieniami. Słabe lub nieaktualne dowody pozostają tak oznaczone aż do przeglądu.
Gdy brakuje dowodów, runtime pyta wskazaną osobę zamiast zmyślać odpowiedź. Odpowiedź jednej osoby jest zapisana jako taka — nie zamieniana po cichu w regułę dla całej organizacji.
Co działa i w jakich warunkach
Dla każdej metody, modelu i rodzaju problemu: zmierzone efekty, ich niepewność, koszt i tryby awarii.
Efekty to nie pojedyncze wyniki. Zmiana może pomóc w jednym wymiarze i zaszkodzić w innym albo pomóc w jednym rodzaju przypadków, a w następnym nie — dlatego są zapisywane jako profil, a nie liczba.
Ludzie trzymają decyzje, które należą do ludzi.
Sędzia mierzy wynik. Recenzent decyduje, co z nim zrobić. Żaden model, sędzia ani orkiestrator nie może zatwierdzić bramki przeglądu, która należy do roli ludzkiej.
Gdy instrukcje są sprzeczne, runtime stosuje stałą kolejność priorytetów:
- 1. bezpieczna odmowa i chronione, właściwe postępowanie,
- 2. prawna, organizacyjna i ludzka władza decyzyjna,
- 3. nadzór, uprawnienia do dowodów i separacja informacji,
- 4. poprawny pomiar,
- 5. kontrakt procesu i jego cel,
- 6. własne instrukcje metody,
- 7. styl i głos.
Poprawia się celowo, nigdy po cichu.
Decyzje recenzentów, korekty i późniejsze wyniki są zapisywane względem dokładnej konfiguracji, która je wytworzyła.
Dane produkcyjne nie zmieniają systemu w trakcie jego działania. Zmiany następują dopiero po analizie offline, nowej wersji i ponownym testowaniu — i tylko tam, gdzie pozwala na to polityka ponownego użycia klienta. Rozbieżność między recenzentami traktujemy jako informację o artefakcie lub o przeglądzie, a nie jako automatyczną prawdę wzorcową.
Nowe procedury powstają głównie z porażek: czytamy, gdzie konfiguracja traci wartość, nazywamy punkt decyzyjny i sygnał, który przeoczyła, zmieniamy jedną rzecz i testujemy ją względem wyniku. Każdą poprawę można prześledzić do konkretnej zmiany.
Procedury zmieniają to, co system robi. Nie zmieniają tego, co model wie.
Procedury rozumowania zmieniają postępowanie w punktach decyzyjnych: którego domyślnego zachowania się odmawia, co jest sprawdzane, gdzie leży próg, kiedy się zatrzymać, kiedy eskalować. Tam, gdzie wynik zależy od tych wyborów, mogą go przesunąć bardzo daleko.
Tam, gdzie wynik zależy od tego, co model może wiedzieć lub wyprowadzić, procedury nie podnoszą sufitu. Wtedy pomagają tylko lepsze informacje lub więcej mocy obliczeniowej — i mówimy o tym wprost.
Z tego samego powodu runtime przełącza się między konfiguracjami przypadek po przypadku tylko wtedy, gdy wykazano, że to pokonuje najlepszy stały wybór. Często właściwą odpowiedzią jest jedna stała metoda, bezpośrednia odpowiedź bez żadnej interwencji albo decyzja, by nie automatyzować.
Nie zakładamy, że inna rola daje lepsze myślenie. Testujemy, co zmienia pracę.
Macie pracę, w której liczy się jakość rozumowania?
Zacznijcie od sprintu badawczo-walidacyjnego: przetestowanego prototypu i dowodów, czy to podejście warto wdrażać.