Pomoc

Jak działa RTZ Auction Lab

RTZ Auction Lab jest aplikacją badawczą służącą do walidacji i eksperymentalnego przeprojektowania mechanizmu aukcyjnego dla frakcjonalizowanych strumieni tantiem. Aplikacja porównuje wariant historyczny, walidowany punkt odniesienia oraz wariant przeprojektowany oceniany w symulacji wieloagentowej.

Wróć do aplikacjiRynekAukcjaSzybki startMetrykiParametrySearchHipotezyEksport
start

Struktura strony głównej

Strona główna jest interfejsem eksperymentalnym. U góry widzisz cel, sposób realizacji i hipotezy, po lewej suwaki eksperymentu, a po prawej wyniki kolejnych przebiegów. Aplikacja porównuje trzy wersje mechanizmu: historyczną, walidowaną i przeprojektowaną.

W pierwszej kolejności należy sprawdzić trzy kwestie: czy mechanizm utrzymuje przychód sprzedającego, czy alokacja nie premiuje nadmiernie Red Teamu oraz czy realne segmenty rynku uzyskują udział zbliżony do docelowej struktury alokacji.

domain

Kontekst przedmiotu badania

Przedmiotem symulacji nie jest standardowe dobro jednorazowej konsumpcji, lecz udział w przyszłych przychodach z katalogu muzycznego, czyli frakcjonalizowane prawo do strumieni tantiem. Katalog może generować wpływy z odtworzeń, synchronizacji, emisji lub innych form eksploatacji, a inwestor nabywa udział w ekonomicznym strumieniu wartości.

Taki rynek jest trudniejszy niż klasyczna sprzedaż, bo uczestnicy nie wyceniają tylko dzisiejszej ceny. Każdy buduje własne oczekiwanie: jak długo katalog będzie słuchany, jak stabilny jest repertuar, czy popularność będzie wygasać, czy może wzrosnąć po nowym trendzie, serialu albo kampanii. Dlatego w symulacji każdy agent ma własną wartość prywatną i budżet.

Dobro
Katalog muzyczny o wartości fundamentalnej V, podzielony na S frakcji.
Uczestnik
Inwestor składa ofertę dwuwymiarową: maksymalną cenę jednej frakcji oraz budżet całkowity.
Problem projektowy
Mechanizm musi jednocześnie ustalić cenę, sprzedać frakcje, nie złamać budżetów, ograniczyć koncentrację i nie dać łatwej przewagi strategiom exploitacyjnym.
auction

Dlaczego to nie jest klasyczna aukcja holenderska

W klasycznej aukcji holenderskiej cena spada, aż ktoś ją zaakceptuje. Tutaj sytuacja jest bogatsza: sprzedawanych jest wiele frakcji jednego katalogu, a każdy uczestnik ma nie tylko maksymalną cenę, lecz także budżet. To znaczy, że popyt zależy od ceny i od tego, ile frakcji inwestor może realnie kupić.

Mechanizm łączy elementy aukcji holenderskiej, aukcji wielojednostkowej oraz reguły alokacji budżetowej. Z tego powodu wynik zależy nie tylko od poziomu ceny, lecz także od reguły clearingu, zaokrągleń i sposobu alokacji frakcji.

Cena clearingu
Cena, przy której mechanizm uznaje, że można rozdzielić frakcje między zaakceptowanych uczestników.
Granularność S
Liczba frakcji. Większe S daje drobniejszy podział katalogu, ale zmienia dynamikę popytu i alokacji.
Koncentracja c_max
Limit udziału jednego uczestnika. Bez tego ograniczenia duży budżet może prowadzić do nadmiernej koncentracji alokacji.
agents

Typy agentów

Agenci są syntetycznymi uczestnikami rynku. Nie reprezentują konkretnych osób, lecz typowe role inwestycyjne, które mogą reagować inaczej na cenę, ryzyko i oczekiwany zwrot.

Individual
Mniejszy inwestor. Zwykle bardziej wrażliwy na ograniczenia budżetowe i podatny na utratę dostępu, gdy mechanizm faworyzuje uczestników o większych budżetach.
Institutional
Większy inwestor. Może mieć większy budżet i stabilniejszą wycenę, więc łatwiej utrzymać obecność w aukcji.
Speculator
Uczestnik nastawiony na oportunistyczne wejście w aukcję. Może akceptować większą zmienność, jeżeli relacja ceny do wartości prywatnej jest korzystna.
Red Team
Agent diagnostyczny, nie segment rynku. Jego zadaniem jest identyfikacja słabości mechanizmu. Dlatego jest liczony w Exploitation Gap, ale nie w Fairness Index.
hypotheses

Cel, realizacja i hipotezy

Cel badawczy
Sprawdzić, czy zmodyfikowana aukcja holenderska dla frakcjonalizowanych praw autorskich może jednocześnie utrzymać przychód sprzedającego, poprawić odporność na strategie exploitacyjne i zachować bardziej zrównoważony dostęp dla realnych typów inwestorów.
Sposób realizacji celu
Symulator najpierw odtwarza historyczną logikę RTZ v1.0, następnie uruchamia walidowany baseline RTZ v1.1, a na końcu ocenia warianty RTZ v2.1. Przeszukiwanie odbywa się przez losową eksplorację, mutacje elit i Bayesian-lite/TPE, a każdy kandydat jest oceniany na populacji agentów uczących się.
H1
RTZ v2.1 może poprawić Fairness Index i obniżyć Exploitation Gap względem RTZ v1.1 bez naruszenia bariery przychodowej RR ≥ 0.90.
H2
Wydłużenie T_learn oraz kandydaci Bayesian-lite powinny zmniejszać przypadkowość wyboru konfiguracji i stabilizować selection score.
quick-actions

Szybkie akcje

Uruchom eksperyment
Wykonuje pełną procedurę eksperymentalną: walidację, v1.0, v1.1, search v2.1, ablację, krzywą uczenia i przygotowanie eksportów.
Autopilot
Uruchamia serię kolejnych przebiegów. Po każdym przebiegu aplikacja interpretuje wyniki, proponuje nowe parametry i przesuwa seedy, aby ograniczyć powtarzanie tej samej trajektorii losowej.
Stop
Zatrzymuje autopilota po bieżącym przebiegu. Trwający eksperyment kończy aktualną ewaluację, aby wyniki nie były ucięte w połowie.
workflow

Pipeline obliczeń

  1. Testy niezmienników sprawdzają, czy silnik symulacji zachowuje podstawowe własności.
  2. RTZ v1.0 legacy odtwarza historyczną logikę oryginalnego kodu.
  3. RTZ v1.1 validated jest właściwym baseline'em badawczym.
  4. RTZ v2.1 redesign wyznacza kandydacką konfigurację mechanizmu z bramką przychodową RR ≥ 0.90.
  5. Ablacja pokazuje, które parametry mechanizmu wpływają na wynik.
  6. Krzywa uczenia sprawdza, czy dłuższe uczenie agentów zmienia metryki.
  7. Eksport zapisuje CSV, LaTeX i JSON.
redesign

Co oznacza redesign mechanizmu

Redesign nie oznacza, że aplikacja projektuje nową aukcję od zera. Oznacza wybór parametrów istniejącego mechanizmu: ceny minimalnej, liczby frakcji, reguły alokacji, typu kroku cenowego i limitu koncentracji. Celem jest znalezienie konfiguracji, która daje lepszy kompromis między przychodem, efektywnością, kompletnością sprzedaży, fairness i odpornością.

Najważniejsze jest porównanie v2.1 do v1.1, nie do v1.0. RTZ v1.0 dostarcza rekonstrukcji historycznej, RTZ v1.1 stanowi właściwy baseline badawczy, a RTZ v2.1 pozwala ocenić, czy zmiana parametrów mechanizmu poprawia wynik bez nadmiernej utraty przychodu.

versions

Wersje RTZ

RTZ v1.0 legacy
Historyczny punkt odniesienia. Celem jest zgodność z oryginalną implementacją, nawet jeżeli część zachowania jest problematyczna metodologicznie.
RTZ v1.1 validated
Walidowany baseline: poprawia wykonalność budżetową, clearing i minimalną granularność frakcji.
RTZ v2.0 redesign
Diagnostyczny wariant trade-offowy. Korzysta z silnika validated, ale może wybrać konfigurację z wysokim FI i niskim RR, dlatego nie jest już główną rekomendacją.
RTZ v2.1 revenue-gated
Główny kandydat projektowy. Używa tej samej przestrzeni searchu co v2.0, ale najpierw filtruje kandydatów przez RR ≥ 0.90, a dopiero potem wybiera najlepszy kompromis M1-M5.
Co uzyskaliśmy
Nowy algorytm wyboru konfiguracji rozdziela dwie role: best feasible jest rekomendacją mechanizmu, a best trade-off pozostaje diagnostyką kompromisu. Dzięki temu aplikacja nie myli konfiguracji atrakcyjnej fairnessowo z konfiguracją dopuszczalną przychodowo.
parameters

Parametry sterujące

Liczba agentów
Większa populacja daje bardziej zróżnicowany rynek, ale podnosi koszt symulacji.
Wartość katalogu V
Wartość fundamentalna katalogu. Revenue Ratio porównuje przychód aukcji z tą wartością.
T_learn
Liczba rund uczenia agentów przed pomiarem. Zwiększaj, gdy wyniki sugerują niedouczenie strategii, np. słaby Completion Rate lub wysoki Exploitation Gap.
T_eval
Liczba rund pomiaru po uczeniu. Zwiększaj, gdy wyniki są blisko progów albo mają wysokie odchylenie standardowe.
Repetycje
Liczba niezależnych seedów dla jednej konfiguracji. Więcej repetycji daje stabilniejsze średnie i odchylenia.
Eksploracja, eksploatacja, Bayesian-lite
To budżet searchu mechanizmu. Eksploracja losuje konfiguracje, eksploatacja mutuje najlepsze, a Bayesian-lite proponuje kandydatów na podstawie historii wyników.
seedBase i seedSearch
Seed jest ziarnem generatora pseudolosowego. seedBase steruje losowością populacji, ofert i uczenia w danym przebiegu, a seedSearch steruje losowością przeszukiwania konfiguracji. Autopilot przesuwa oba ziarna w kolejnych przebiegach, aby ograniczyć powtarzanie tej samej trajektorii losowej.
metrics

Metryki i matematyka

M1 Revenue Ratio
RR = min(R / V, 2),   R = Σi ci
Mierzy przychód sprzedającego względem wartości katalogu. Dla wyboru fairness-preferred wymagamy RR >= 0.90.
M2 Allocative Efficiency
AE = PVrealized / PVopt,   PVrealized = Σi sivi
Sprawdza, czy frakcje trafiają do uczestników o wysokiej wartości prywatnej przy danych ograniczeniach budżetowych.
M3 Exploitation Gap
EG = max( (ROIred - ROIind) / ( |ROIred| + |ROIind| + 0.01 ), 0 )
Mierzy przewagę Red Teamu nad inwestorami indywidualnymi. Niższa wartość jest korzystna.
M4 Completion Rate
CR = Ncleared / Teval
Pokazuje, jak często aukcja sprzedaje pełną liczbę frakcji w fazie ewaluacji.
M5 Market-only Fairness Index
FI = 1 - [ Σt∈TM |qt - τt| ] / Dmax
Mierzy zgodność struktury rynku z docelowymi udziałami typów individual, institutional i speculator. Red Team jest wyłączony.
Selection score
score = 0.25RR + 0.25AE + 0.20(1 - EG) + 0.15CR + 0.15FI
Łączy metryki M1-M5 i dodaje premie za dobry FI, niski EG oraz liczbę spełnionych progów. Konfiguracja nie powinna być traktowana jako finalna, jeśli poprawia fairness kosztem spadku RR poniżej 0.90.
results

Jak interpretować wyniki

Porównuj v2.1 przede wszystkim z v1.1 validated. v1.0 jest potrzebne jako historyczna rekonstrukcja, ale nie jest normatywnym baseline'em badawczym.

Dobry wynik to nie tylko wysoki selection. W v2.1 podstawowy wybór konfiguracji jest revenue-gated: kandydat powinien spełniać RR ≥ 0.90, a dopiero potem poprawiać Exploitation Gap i Fairness Index.

risks

Ryzyka interpretacyjne

Wysoki fairness nie wystarcza
Jeżeli FI rośnie, ale RR spada poniżej 0.90, poprawa dostępności jest osiągana kosztem przychodu. To nie jest finalny wariant fairness-preferred.
Niski EG nie oznacza braku strategii
Niski Exploitation Gap oznacza, że Red Team nie uzyskał przewagi w tej populacji i przy tych seedach. Nie jest to formalny dowód odporności na wszystkie strategie.
Odchylenie standardowe ma znaczenie
Wynik z wysokim sd może być niestabilny. W takiej sytuacji należy zwiększyć T_eval lub reps zamiast wyciągać silne wnioski z pojedynczego przebiegu.
Model jest stylizowany
Symulacja pokazuje kierunek projektowy, ale nie zastępuje kalibracji na rzeczywistych danych transakcyjnych i royalty.
validation

Walidacja i PASS/FAIL

Testy walidacyjne sprawdzają podstawowe własności silnika: zgodność legacy z oryginałem, wykonalność budżetową w validated, clearing i poprawne traktowanie Red Teamu.

PASS oznacza, że test niezmiennika przeszedł. FAIL oznacza, że wynik eksperymentu trzeba traktować jako niewiarygodny, dopóki silnik nie zostanie poprawiony.

ablation

Ablacja

Ablacja zmienia po jednym parametrze i sprawdza wpływ na metryki. Dzięki temu widać, czy wynik v2.1 wynika z całego searchu, czy głównie z jednego parametru, np. granularności S, reguły alokacji albo limitu koncentracji.

learning

Krzywa uczenia

Krzywa uczenia porównuje wyniki dla różnych wartości T_learn. Jeżeli selection rośnie przy dłuższym uczeniu, agenci potrzebują więcej czasu na adaptację. Jeżeli wynik się stabilizuje, dalsze zwiększanie T_learn może być mniej opłacalne niż zwiększenie repetycji.

autopilot

Autopilot i rekomendacje

Autopilot działa w pętli: uruchomienie, interpretacja wyników, wybór kolejnych parametrów, przesunięcie seedów, kolejne uruchomienie. Uzasadnienia obok rekomendacji mówią, czy problem wygląda na search-limited, learning-limited, revenue-constrained czy evaluation-noise-limited.

Po każdym przebiegu aplikacja zapisuje wynik do historii sesji i wyznacza ocenę hipotez H1 oraz H2. H1 dotyczy jednoczesnej poprawy FI, obniżenia EG i zachowania bariery RR ≥ 0.90. H2 dotyczy wpływu T_learn, Bayesian-lite i stabilności wyników między przebiegami.

Limit autopilota określa długość jednej uruchamianej serii, a nie limit archiwum. Historia iteracji zbiera wszystkie przebiegi z bieżącej sesji, wraz z seedBase, seedSearch, metrykami, konfiguracją v2.1 oraz oceną H1/H2.

Główne podsumowanie w aplikacji jest agregowane po całej historii autopilota. Pełny zestaw wyników pojedynczego przebiegu otwiera się kliknięciem odpowiedniego wiersza w Historii iteracji.

Wyniki są zapisywane w pamięci sesji przeglądarki, dlatego przejście na stronę Pomocy i powrót do aplikacji nie usuwa historii. Dane pozostają dostępne w tej samej karcie przeglądarki do czasu zamknięcia sesji albo zastąpienia ich nowymi przebiegami.

exports

Eksport

CSV
Tabela do arkusza kalkulacyjnego lub dalszej analizy statystycznej. Po autopilocie zawiera sekcje AUTOPILOT_RUNS, AUTOPILOT_CANDIDATES oraz HYPOTHESES.
LaTeX
Tabela wynikowa w składni LaTeX.
JSON
Pełny zapis danych, parametrów, konfiguracji i wyników. Eksport JSON zawiera bieżący wynik, ocenę hipotez liczonych po historii oraz pełną historię przebiegów autopilota zapisaną w bieżącej sesji.
limits

Ograniczenia

Obecna wersja nie jest pełnym MARL, pełnym BOHB ani produkcyjnym systemem aukcyjnym. To walidowane laboratorium eksperymentalne. Najważniejsze ograniczenia to stylizowany model rynku, agenci bandit zamiast deep RL oraz uproszczony Bayesian-lite zamiast formalnej optymalizacji bayesowskiej.