Jak dane z sesji AI-asystenta (Copilot, Claude Code, Cursor) stają się — za jawną zgodą — sprowidencjonowanym agentem stylizowanym na konkretną osobę. Z analogią do znanego problemu z innej dziedziny i dziesięcioma tematami badawczymi do dalszej pracy.
docs/ANALYSIS.md — projektowe
uzasadnienia zostają w języku, w którym powstały. English summary: this page diagrams the
telemetry→persona-agent pipeline (CopilotScope.AgentForge) and draws an analogy
to collecting warehouse-worker operational data to train a robot, plus ten follow-up research
proposals. Source: docs/AGENT_PROVISIONING_WORKFLOW.md,
research/RESEARCH_PROPOSALS.md.
01 — Mechanizm
Trzy strefy odpowiedzialności: telemetria bez tożsamości, jawna bramka zgody poza systemem, i provisioning agenta, który nigdy nie modyfikuje wag modelu.
02 — Krok po kroku
conversation.id, nie przez osobę — ten krok działa identycznie, niezależnie od tego, czy ktokolwiek kiedykolwiek uruchomi provisioning agenta.PersonaCohort — ręcznie wypisany rekord konfiguracyjny z listą SessionIds, kto wyraził zgodę i kiedy. Bez wpisu nie ma danych dla danej persony; to nie „domyślnie wyłączone", to brak ścieżki kodu.PersonaProfileBuilder czyta wyłącznie sesje z cohortu przez istniejące API i składa profil: średni quality score, najczęstsze narzędzia, ograniczony zestaw exemplarów transkryptu."simulated": true zapisane na sztywno w DTO — agent nigdy nie ma prawa przedstawiać się jako dana osoba.DELETE czyści agenta z pamięci natychmiast (poziom operacyjny). Usunięcie PersonaCohort z konfiguracji i restart to poziom trwały — profilu nie da się odtworzyć w ogóle.03 — Ten sam kształt problemu, inna domena
Zbieranie telemetrii dewelopera, żeby sprowidencjonować agenta, i zbieranie danych operacyjnych pracownika magazynu, żeby wytrenować robota, to nie luźne podobieństwo — to ta sama struktura decyzji, tylko inna domena.
| Wymiar | Telemetria dewelopera → AgentForge | Dane pracownika magazynu → robot/cobot |
|---|---|---|
| Co się zbiera | Tury czatu, wywołania narzędzi, akceptacje edycji, TTFT, błędy | Ścieżki ruchu, czasy cykli pick/pack, punkty korekt |
| Tożsamość | Brak user.id — sesja to nie osoba | Odznaka/terminal WMS zwykle jest identyfikowalny — większe ryzyko wyjściowe |
| Bramka do modelu 1 osoby | PersonaCohort — ręczna, jawna, z polami zgody | Program pilotażowy z podpisaną zgodą i wskazanym stanowiskiem |
| Co robi model z danymi | Grounding w kontekście — nic nie wchodzi w wagi | Zwykle imitation learning — trajektorie wchodzą w wagi polityki ruchu |
| Odwracalność wycofania | Wysoka — usunięcie cohortu = zero śladu | Niska, jeśli dane już weszły do treningu — wymaga retrainu |
| Ryzyko Goodharta | Optymalizacja pod metrykę akceptacji zamiast pod jakość | Efekt Hawthorne'a — pracownik zmienia ruch pod obserwacją |
DELETE.
04 — Dla przyszłych inżynierów
Jedna praca na algorytm pomiaru jakości sesji z docs/ANALYSIS.md §8.
Sześć ma już implementację — tam praca to kalibracja i walidacja. Cztery nie mają — tam to
projekt i prototyp. Pełna wersja z metodologią i kryteriami sukcesu:
research/RESEARCH_PROPOSALS.md.
Model-sędzia ocenia transkrypt wg rubryki — bogaty sygnał, ale kosztowny i podatny na bias.
Model uczy się rubryk SAT/DSAT z etykietowanych sesji zamiast statycznej rubryki.
Faithfulness / relevance / context precision — sensowne tylko dla sesji z retrievalem.
Four-gram overlap + no-revert, wagi 0.4/0.6 — działa, ale niewalidowane niezależnie.
Zaakceptowane linie na interakcję, ważone odrzuceniami — celowo prosty proxy produktywności.
Segmentacja sesji na tury, kary za błędy LLM/narzędzi i pętle naprawcze.
TTFT mapowane na użyteczność krzywą log-linear, progi z ogólnych badań HCI.
Koszt per model z konfigurowalnego cennika, oszczędności prompt-cache.
Leksykon EN/PL + Jaccard przeformułowań — świadomie zaszumiona, dlatego report-only.
Najbliższe „czy praca została wykonana" — wymaga sygnałów spoza telemetrii Copilota.