Echipa de agenți AI și fluxul de cercetare

Agenți Stratmill specializați transmit fiecare strategie printr-o succesiune fixă de etape, cu verificări între ele.

Echipa de agenți

Research Lead redactează ipoteze. Strategy Developer le transformă în strategii NautilusTrader prin cod. QA Agent verifică dacă acesta este corect. Strategy Analyst interpretează rezultatele backtesturilor și optimizărilor și decide ce urmează. Risk Officer auditează siguranța unei strategii înainte de promovare. Portfolio Manager decide promovarea și alocarea pentru întregul portofoliu.

În sprijinul echipei, motorul de backtest rulează fiecare backtest și fiecare optimizare cu comisioane reale, inginerul de date menține catalogul de date de piață complet, Library Refiner propune îmbunătățiri bazate pe surse citate din Knowledge Library atunci când o strategie este iterată, iar instrumentul de export portează strategiile pe alte platforme.

Etapele în ordine

O rulare trece prin etapele de codare, verificare, backtest, evaluarea backtestului, optimizare și analiză. Din etapa de analiză, poate reveni la codare pentru o nouă iterație, se poate întoarce la Research Lead pentru revizuirea ipotezei, poate fi abandonată sau poate continua către evaluarea riscului, promovare și tranzacționare simulată. Etapele ulterioare sunt procesate cu prioritate, astfel încât verificarea și backtestul să nu rămână blocate în spatele unei cozi de cod nou.

Etapele verificării

Codul este verificat înainte de a fi rulat pe întreaga istorie. O retrimitere identică cu iterația anterioară eșuează imediat. O verificare de consistență confirmă că strategia tranzacționează platforma și instrumentul declarate în ipoteză. Analiza statică verifică structura și metodele obligatorii și interzice accesul la fișiere, rețea și sistem, precum și orice metodă de citire a datelor din viitor.

Apoi, testele sintetice rulează strategia pe piețe generate (trend ascendent, trend descendent, piață laterală, creștere bruscă a volatilității, volum zero și salt de preț, precum și date suplimentare lipsă atunci când strategia le folosește), într-un mediu izolat. Un backtest scurt, într-un mediu izolat, pe bare reale recente trebuie să execute cel puțin o tranzacție. În final, QA Agent verifică logica în raport cu ipoteza: anticiparea datelor, direcția semnalului, dimensionarea poziției, regulile platformei și programările. QA nu evaluează performanța.

Când verificarea eșuează

În caz de eșec, rularea revine la dezvoltator împreună cu constatarea. După 3 încercări eșuate, rularea este abandonată. O regulă care nu se declanșează niciodată sau o cerință pe care dezvoltatorul nu o poate îndeplini este trimisă înapoi la Research Lead pentru revizuirea ipotezei. Eșecurile cauzate de platformă sunt reîncercate și nu sunt puse pe seama strategiei.

Cele două decizii ale analistului

După primul backtest, analistul decide dacă optimizează, iterează, revizuiește ipoteza sau abandonează, astfel încât orele de optimizare să fie investite doar în idei cu un semnal real. Un mecanism de verificare a viabilității validează decizia în raport cu cifrele: o strategie cu suficiente tranzacții și un randament mediu per tranzacție peste pragul comisioanelor platformei nu este abandonată dintr-un capriciu, iar una sub acest prag nu este trimisă la optimizare.

După optimizare, analistul decide dacă promovează, iterează, revizuiește sau abandonează, având la dispoziție dovezile din eșantionul out-of-sample și din eșantionul de validare finală. Fiecare decizie și justificarea ei sunt înregistrate pe pagina strategiei.

Praguri de comisioane în funcție de platformă

Analistul verifică pragul minim al costurilor Forex și dovezile înregistrate pentru spread, comision și finanțare în rulare. O ipoteză cu avantaj net insuficient este revizuită sau respinsă. Lipsa dovezilor privind costurile impune suspendarea operațională și nu trebuie înlocuită cu costuri zero.

Evaluarea responsabilului de risc

Înainte de promovare, responsabilul de risc auditează siguranța strategiei și trebuie să o aprobe explicit. Se aplică și limite impuse prin cod: levierul trebuie să se încadreze în plafonul profilului tău de risc, trebuie să existe un control al riscului definit (un stop care limitează riscul la o parte determinată din capitalul propriu per tranzacție sau o ieșire pe bază de semnal cu dimensiunea poziției limitată), să nu existe probleme critice, iar scorul de risc să fie acceptabil. Responsabilul de risc poate respinge și o derogare de la un criteriu, redactată de analist. Respingerea trimite execuția înapoi la dezvoltator.

Managerul de portofoliu și alocarea

Etapa managerului de portofoliu verifică din nou, în cod, fiecare criteriu și limită de risc, reține strategiile prea corelate cu cele deja implementate și decide dacă le promovează la tranzacționare simulată. Capitalul este alocat în funcție de volatilitatea inversă, cu o limită per strategie; strategiile noi pornesc cu ponderi egale, iar cele aflate în incubare primesc jumătate din pondere. Trecerea de la tranzacționare simulată la tranzacționare reală nu este niciodată automată.

Limitele iterațiilor și abandonarea

O strategie este abandonată când randamentul mediu per tranzacție este sub costurile de tranzacționare, când performanța în afara eșantionului este nesatisfăcătoare, când eșuează în mod repetat verificarea sau când analistul nu vede nicio cale către viabilitate. Motivul este înregistrat și transmis agentului de cercetare, astfel încât același impas să nu se repete.

Rulările platformei și rulările tale

Platforma își desfășoară propriile cercetări în mod continuu; spațiul tău de lucru rulează în paralel, cu capacitate rezervată și prioritate mai mare, astfel încât ideea ta să nu intre la coadă în urma activităților platformei. Îți poți întrerupe, relua sau opri propriile rulări oricând, din pagina strategiei.