Automatiseret prognosehandel: afgræns hver beslutning

Arbejdsgang for automatiseret prognosehandel

En observation er en oplysning, der er modtaget fra en kilde, med et tidspunkt og et omfang. Det kan være en opdatering af ordrebogen, et regeldokument eller en begivenhedsrapport. En anbefaling er en fortolkning af denne dokumentation, som foreslår en mulig handling. En godkendelse er en særskilt beslutning om, at den foreslåede handling passer inden for de aktuelle grænser og kontobetingelser. Et ordreforsøg er selve afsendelsen, og en udført handel er dokumentation for, at en vis mængde faktisk blev handlet.

Skriv disse trin som særskilte objekter eller poster i systemets registreringer. En anbefaling kan udløbe uden en ordre. Et godkendt forsøg kan forblive uudført. En delvis udførelse kan skabe eksponering, mens resten af anmodningen annulleres eller fortsat er aktiv. Kontoen kan derfor befinde sig i en tilstand, som et enkelt ja-eller-nej-flag for succes ikke kan beskrive.

Den ældre guide til automatisering af handel på prognosemarkeder udvikler denne adskillelse på driftsniveau. En praktisk arbejdsgang bør lade en kontrollant gå fra en erhvervet position tilbage til godkendelsen og den dokumentation, der understøttede den. Hvis dette spor brydes, kan systemet ikke fuldt ud forklare sin egen eksponering.

Dette spor gør også beslutninger om at afstå synlige. En beslutning om at observere uden at handle kan være det tilsigtede resultat, når reglen er uklar, omkostningen er for høj, eller kontoen allerede har eksponering. Automatisering bør ikke vurderes efter, hvor ofte den handler. Den bør vurderes efter, om hver handling ligger inden for det definerede ansvar, og om hver afvisning har en forståelig begrundelse.

Fastlæg kontraktens grænser før kontoens grænser

Arbejdsgangen skal have en præcis kontraktfortolkning, før den kan vurdere risiko. Registrer betingelsen, referencekilden, observationstidspunktet, sammenligningsoperatoren og relevante undtagelsesbestemmelser. Lignende overskrifter fastslår ikke, at udbetalingerne er ækvivalente. Et system, der handler den forkerte begivenhed inden for en omhyggeligt fastsat kontantgrænse, træffer stadig den forkerte beslutning.

En normaliseret kontraktregistrering bør bevare den fulde kildetekst og version. Automatisk udtræk kan hjælpe med at udfylde felter, men vigtige grænser skal kontrolleres. Ord som »over«, »mindst«, »før« og »under« kan ændre mængden af begivenheder. Et resumé, der udelader et af dem, kan være lettere at læse, men uegnet til handel.

Test fortolkningen med konkrete hypotetiske observationer. Brug værdier under, lig med og over en tærskel. Brug en begivenhed lige før og lige efter en frist. Medtag manglende dokumentation, hvis reglerne angiver en alternativ fremgangsmåde. De forventede resultater bør komme fra kontraktfortolkningen og ikke fra den samme kode, der testes.

Guiden til AI-prognosemarkeder er nyttig, når sprogmodeller hjælper med dette trin. En flydende fortolkning er ikke automatisk korrekt, og en models sikkerhed er ikke en kalibreret sandsynlighed. Arbejdsgangen kan bruge AI til at organisere dokumentation, mens den bevarer en særskilt kontrol af den betingelse, kontoen faktisk vil handle.

Risikogrænser for automatiseret prognosehandel

Risikogrænser bør angive, hvad der afgrænses: omkostning pr. ordre, eksponering pr. kontrakt, eksponering mod relaterede begivenheder, kontoens tabsramme og uafklarede forpligtelser, hvor de er relevante. Én maksimal mængde kan være misvisende, fordi 100 enheder til 0,10 og 100 til 0,90 binder forskellige kontantbeløb. Grænsen bør bruge en enhed, der svarer til den risiko, der kontrolleres.

Medtag aktive ordrer og afsendelser med ukendt resultat, når den mulige eksponering vurderes. En anmodning, der endnu ikke er udført, kan stadig blive det. En anmodning, hvis svar gik tabt, kan allerede være udført. Hvis begge behandles som nul, indtil der kommer en lokal succesbesked, kan arbejdsgangen godkende større eksponering end tilsigtet.

Grænser bør også have en ansvarlig og en ændringsproces. En forskningsmodel bør ikke udvide sin egen ramme, fordi den rapporterer større sikkerhed. Ændringer i det tilladte omfang kræver en særskilt beslutning, der kan gennemgås. Ellers bliver risikokontrollen blot endnu et udtryk for den samme modelusikkerhed, som den skulle inddæmme.

Den ældre guide til automatisering af begivenhedskontrakter forklarer, hvorfor kontostatus hører hjemme i beslutningen. En anbefaling kan være attraktiv isoleret set og stadig blive afvist, fordi porteføljen allerede afhænger af den samme begivenhed. Afvisningen er en gyldig funktion i arbejdsgangen, ikke dokumentation for, at prognosemotoren har svigtet.

Et gennemarbejdet eksempel på godkendelse

Overvej en fiktiv konto med en ramme på 120,00 for en gruppe relaterede begivenhedspositioner. Eksisterende erhvervede positioner har en samlet almindelig eksponering mod kontanttab på 55,00. Aktive, endnu uudførte anmodninger kan tilføje yderligere 20,00, hvis de udføres. Den resterende ramme for et nyt forslag er derfor 45,00, hvis disse er de relevante eksponeringer, der skal lægges sammen, og der ikke er andre forpligtelser.

En model anbefaler at købe 100 enheder af et almindeligt Yes-krav med udbetaling på én enhed til en anslået samlet omkostning på 48,00 inklusive hypotetiske gebyrer. Anbefalingen kan have en positiv modelleret forventet værdi, men den overskrider den resterende ramme på 45,00. Godkendelsestrinnet bør afvise den eller ændre dens størrelse efter en på forhånd fastlagt politik. Det bør ikke ignorere de aktive anmodninger for at få forslaget til at passe.

Antag, at politikken tillader et mindre køb, hvis kontrollerede fulde omkostning er 43,20. Gruppens samlede mulige eksponering bliver 55,00 plus 20,00 plus 43,20, altså 118,20, hvilket efterlader 1,80 under rammen. Dette beviser ikke, at handlen er ønskelig. Det beviser kun, at denne ene grænse overholdes efter den angivne beregning. Andre kontroller, herunder datakvalitet og prisgrænser, gælder stadig.

Hvis en eksisterende aktiv anmodning annulleres, bør rammen først frigives, når arbejdsgangen har fastslået det relevante resultat og afstemt eventuelle handler, der blev udført i mellemtiden. En anmodning om annullering og en bekræftet mangel på resterende eksponering er ikke den samme dokumentation. Denne forskel er afgørende, når den disponible margin er lille.

Giv anbefalinger et udløb

En anbefaling dannes ud fra et bestemt sæt oplysninger og en bestemt ordrebog. Hvis en af delene ændres væsentligt, beskriver anbefalingen muligvis ikke længere den aktuelle mulighed. Tilknyt et udløb eller et sæt betingelser, der gør den ugyldig, eksempelvis en ændret kontraktregel, en forældet kilde, en omkostning over den tilladte grænse eller en væsentlig kontoopdatering.

Udløb er ikke det samme som at slette registreringen. Bevar den historiske anbefaling til vurdering, mens dens mulighed for at godkende nye handlinger fjernes. Det lader en kontrollant undersøge, hvad systemet mente, uden at lade en gammel opfattelse forblive aktiv på ubestemt tid. En registrering kan være analytisk nyttig, efter at den er blevet ugyldig til drift.

Gentagne observationer kræver også en politik. Hvis den samme prognose fortsat ser attraktiv ud ved ti opdateringer i træk, retfærdiggør det så ti køb eller én målposition? En arbejdsgang bør definere måleksponeringen og sammenligne den med eksisterende og mulige beholdninger. Ellers kan gentagen vurdering mangedoble én tilsigtet handel til en utilsigtet ophobning.

Guiden til software til automatiseret handel på prognosemarkeder omsætter disse idéer til godkendelseskriterier. Et værktøj bør kunne vise, at det lader forældede beslutninger udløbe, forhindrer utilsigtet gentagen ophobning og genberegner godkendelsen ud fra den aktuelle kontostatus. En funktionsliste alene kan ikke fastslå denne adfærd.

Hold omkostningstærsklen adskilt fra modellens sikkerhed

Antag, at en fiktiv kontrakt koster 0,54 pr. enhed inklusive en hypotetisk fordeling af gebyrer. En model anslår en sandsynlighed på 59% for den almindelige udbetaling på én enhed. Den modellerede fordel er 0,05 pr. enhed under dette estimat. Hvis estimatet er dårligt kalibreret, eller den faktiske omkostning stiger, kan denne margin forsvinde. Tallet er en betinget beregning, ikke en sikkerhed knyttet til ordren.

Et system bør bevare estimatets metode og usikkerhed. Hvis et følsomhedsinterval går fra 52% til 63%, ligger den nederste del under omkostningstærsklen på 54%. Arbejdsgangen skal have en politik for denne usikkerhed: afstå, søg mere dokumentation eller brug en afgrænset størrelse under en udtrykkeligt accepteret risiko. Den bør ikke ubemærket vælge det mest gunstige punkt i intervallet.

Guiden til software til AI-prognosemarkeder undersøger oprindelse, kalibrering og tilladelser for værktøjer med modelhjælp. Dens relevans her er adskillelsen mellem en model, der siger, at den er sikker, og dokumentation for, at dens sandsynligheder har været pålidelige. En risikogodkendelse bør afhænge af det sidste, hvor strategien hævder at have en sandsynlighedsmæssig fordel.

Markedets egen pris er heller ikke en objektiv sandhed. Den er en handelsobservation formet af tilgængelige ordrer og betingelser. Det kan være oplysende at bruge den som sammenligningsgrundlag, men både den private prognose og den markedsomkostning, der kan handles til, skal fortolkes passende. Automatisering bør bevare forskellen mellem dem uden at foregive, at nogen af inputtene er ufejlbarlige.

Brug den rigtige betydning af ordretyperne

Udførelseslaget skal forstå den faktiske instruktion, det sender. En limitpris afgrænser den accepterede pris, men garanterer ikke en udførelse. En fill-and-kill-ordre kan udføre den tilgængelige mængde og annullere resten. En fill-or-kill-instruktion søger at udføre hele den angivne mængde eller intet for den pågældende ordre; den gør ikke særskilte ordrer på tværs af markeder eller handelssteder til en atomisk pakke.

Den aktuelle dokumentation for Polymarkets ordrelivscyklus skelner mellem disse ordreadfærdstyper og mellemliggende tilstande. Den bredere lære er at kontrollere handelsstedets aktuelle betydninger frem for at kopiere en antagelse fra en anden platform. En fælles intern grænseflade bør bevare de oplysninger, der er nødvendige for at ræsonnere om delvis og afventende udførelse.

Et ordresvar bør opdatere ordreregisteret, mens bekræftede udførte handler opdaterer positions- og kontantregistreringerne efter handelsstedets proces. Hvis svaret indeholder en mellemliggende tilstand, bør arbejdsgangen bevare den som mellemliggende. En bekvem betegnelse som »færdig« kan få efterfølgende beslutninger til at bygge på mængder eller midler, der endnu ikke er fastslået.

Den ældre guide til API til handel på prognosemarkeder forklarer grænsen mellem kontoadgang og strategilogik. Udførelseslaget bør kun acceptere afgrænsede instruktioner fra godkendelseslaget og returnere præcis dokumentation. Det bør ikke omfortolke en afvist ordre som tilladelse til at jage en ny pris eller øge mængden uden en ny beslutning.

Planlæg for et forsøgs ukendte udfald

En forbindelse kan svigte, efter at en anmodning er sendt, men før svaret er modtaget. Arbejdsgangen ved da, at der fandt et forsøg sted, men ikke hvad resultatet var. Dette er en særskilt tilstand. Hvis den behandles som en fejl, kan det føre til en dobbelt ordre; hvis den behandles som en succes, kan det skabe en fiktiv beholdning. Ingen af genvejene er begrundet i det manglende svar.

Bevar den oprindelige identitet, og undersøg gennem understøttede ordre-, handels- og kontoregistreringer. Lad den uafklarede mængde eller det uafklarede beløb tælle med i den relevante eksponeringsramme. Når tilstanden er fastslået, skal beslutningen genberegnes ud fra den faktiske konto frem for blindt at fortsætte den oprindelige plan. Betingelserne kan have ændret sig, mens genopretningen stod på.

En annullering kan skabe lignende usikkerhed, hvis en handel udføres næsten samtidig. Den endelige ordre kan være annulleret med en udført mængde, der ikke er nul. Arbejdsgangen skal bevare begge fakta. Annullering af en uudført rest omgør ikke en fuldført udførelse, og en resterende mængde på nul betyder ikke nødvendigvis, at den samlede udførte mængde er nul.

Dokumentation for genopretning bør gemmes varigt. Hvis processen genstarter igen under afstemningen, bør den ikke glemme, hvilket forsøg der var uafklaret, eller hvorfor handlen var sat på pause. En operatør har brug for en klar liste over udestående usikkerheder, ikke et rent kontrolpanel skabt ved at kassere besværlige tilstande under opstart.

Adskil stop for nye ordrer fra styring af eksponering

En stopfunktion kan forhindre nye godkendelser, men eksisterende positioner og aktive anmodninger kan bestå. Fastlæg, hvad hver stoptilstand gør. Én kan standse anbefalinger, en anden afsendelser og en tredje iværksætte annullering, hvor det er tilladt. Ingen bør beskrives som at gøre kontoen uden eksponering, medmindre de faktiske positioner og anmodninger er afstemt til denne tilstand.

Denne forskel er vigtig under et datasvigt. Det kan straks være passende at forhindre ny eksponering, mens annullering eller lukning af eksisterende positioner kræver yderligere kontoadgang og aktuel dokumentation for udførelsen. Et system bør ikke improvisere en ubegrænset likvidationspolitik, blot fordi prognosekilden er utilgængelig. Den tilladte reaktion hører hjemme i driftsplanen.

Test stopadfærden med en delvis udførelse og en aktiv rest. Operatøren bør kunne se den erhvervede beholdning, den forsøgte annullering og den endelige resterende tilstand. En grøn stopindikator er ikke nok, hvis den skjuler en position, der stadig kan tabe penge, eller en ordre, der stadig kan blive udført.

Fastlæg også kriterier for genoptagelse. En genoprettet proces, en genskabt dataforbindelse og en afstemt konto er forskellige milepæle. Arbejdsgangen bør først genoptage den berørte strategi, når den dokumentation, strategien kræver, igen er tilgængelig. En genstart af en tjeneste bør ikke automatisk genskabe enhver tilladelse, der fandtes før en afbrydelse.

Gennemgang af beslutninger ved automatiseret prognosehandel

En gennemgang bør rekonstruere en udvalgt beslutning uden at bygge på modellens senere forklaring. Begynd med gemt dokumentation: kontraktversionen, inputdataene, prognosen, omkostningsberegningen, risikoresultatet, den afsendte anmodning, de udførte handler og den endelige kontovirkning. En fortælling, der genereres, efter at udfaldet er kendt, kan være en nyttig kommentar, men den erstatter ikke den samtidige registrering.

Gennemgå beslutninger om at afstå og afviste godkendelser såvel som handler. De viser, om arbejdsgangen håndhævede de tilsigtede grænser. Hvis enhver attraktiv prognose på en eller anden måde omgår en grænse, udfører kontrollen ikke et meningsfuldt arbejde. Hvis systemet afviser mange beslutninger på grund af manglende data, er det dokumentation om driftsdækningen og bør rapporteres ærligt.

Vurder prognosen og processen hver for sig. En tabende begivenhed kan følge efter et velkalibreret sandsynlighedsestimat og korrekt udførelse. En vindende begivenhed kan følge efter en forkert regeltilknytning eller en uautoriseret dublering. Gennemgangen bør identificere disse forskelle, så operatøren ikke belønner usikker adfærd, blot fordi den tilfældigvis tjente penge.

Brug et lille sæt meningsfulde mål: beslutninger med fuldstændig dokumentation, uafklarede forsøg, udførelsesomkostning sammenholdt med estimatet, grænseoverskridelser og prognosekvalitet på passende afgjorte grupper. Et stort kontrolpanel med aktivitetstællinger kan sløre disse grundlæggende forhold. Flere behandlede beskeder eller afsendte ordrer fastslår ikke, at beslutningerne er bedre.

Test tilladelser med en forældet anbefaling

Et nyttigt godkendelsesscenarie begynder med en anbefaling, der var gyldig, da den blev oprettet. Før den når frem til udførelsen, skal du ændre kontoen ved at tilføje en bekræftet udført handel i en relateret kontrakt. Arbejdsgangen bør vurdere forslaget mod den nye kontostatus og ikke blot stole på den tidligere godkendelse. Dette tester, om godkendelsen er en aktuel beslutning eller et genanvendeligt adgangstegn løsrevet fra sine antagelser.

Kør et andet scenarie, hvor kontoen er uændret, men ordrebogen bevæger sig ud over den godkendte omkostning. Systemet bør enten afvise forsøget eller udarbejde et nyt forslag under den definerede politik. Det bør ikke omfortolke den oprindelige prisgrænse som en invitation til at forfølge markedet på ubestemt tid. Ændringen i omkostning er vigtig, selv om prognosesandsynligheden forbliver den samme.

I et tredje scenarie skal både konto og ordrebog være uændret, men kontraktfortolkningen ændres, efter at et andet observationsvindue er opdaget. Den tidligere anbefaling vedrører ikke længere den samme definerede begivenhed. Kravet om en ny prognose her tester en dybere grænse end en prisgrænse: beføjelsen til at handle var knyttet til et bestemt spørgsmål, og dette spørgsmål har ændret sig.

Disse scenarier skaber konkret dokumentation for, at arbejdsgangen respekterer sit eget omfang. De er mere oplysende end en demonstration, hvor hvert input forbliver gunstigt, og enhver ordre udføres straks. Formålet er at observere, om systemet genkender, når en tidligere rimelig handling ikke længere er godkendt.

Ændr arbejdsgangen uden at omskrive dens historie

Når en model, en regelfortolker eller en risikopolitik ændres, skal versionen og begrundelsen registreres. Historiske beslutninger bør forblive knyttet til deres oprindelige versioner. Det gør det muligt ved en senere gennemgang at sammenligne adfærden ærligt og forhindrer, at en revideret politik får æren for resultater, den ikke skabte.

Indfør ændringer inden for et afgrænset omfang, der kan vurderes. En ny model kan først udarbejde anbefalinger uden beføjelse til at handle. En ny udførelsesadapter kan testes for håndtering af tilstande, før den får bredere tilladelser. Formålet er ikke at maksimere formaliteter, men at isolere det, der ændrede sig, og indsamle dokumentation om dets adfærd.

Automatiseret prognosehandel bliver ansvarlig, når hver overgang har et klart krav og en varigt gemt registrering. Systemet kan da forklare, hvad det observerede, hvad det foreslog, hvorfor en handling var tilladt, og hvad kontoen faktisk modtog. Denne klarhed understøtter nyttig automatisering, samtidig med at den bevarer den usikkerhed, de grænser og det menneskelige ansvar, der fortsat er en del af handel.