researcher: un archivio di ricerca quant ricercabile per umani e agenti AI

La ricerca quant è ovunque e da nessuna parte. Il paper che ti serve è su arXiv. L'implementazione di riferimento è su GitHub. L'intuizione è sepolta in un post di blog che qualcuno ha scritto nel 2019. La logica vera e propria di entrata/uscita è uno script Pine su TradingView con 400 like e nessuna documentazione. Quattro corpora, quattro caselle di ricerca, quattro insiemi di convenzioni, zero riferimenti incrociati. Quando stai cercando di decidere se un'idea vale una settimana di backtesting, quella frammentazione è il vero costo — non la lettura, ma il trovare.

Così ne abbiamo costruito uno nostro. researcher.marketmaker.cc è un archivio curato e un motore di ricerca per la ricerca sul trading quantitativo. Riunisce il materiale normalmente disperso tra arXiv, GitHub, blog quant e TradingView in un unico posto, lo indicizza tutto per la ricerca a tutto testo e — questa è la parte che ci sta più a cuore — espone l'intero corpus agli agenti AI tramite un endpoint Model Context Protocol (MCP) e una REST API pubblica. È un substrato di ricerca che un umano può sfogliare con una tastiera e un agente può interrogare con una chiamata a uno strumento, supportati esattamente dagli stessi indici.

Questo post è una panoramica di cosa c'è dentro, di come è costruito e del perché si colloca dove si colloca nel nostro stack di agenti AI.

Cosa c'è nel corpus

researcher unifica quattro dataset principali, ognuno con il proprio indice a tutto testo. I conteggi qui sotto sono aggiornati al 2026-06-12, e cambiano — la pipeline di arXiv gira quotidianamente e l'indice viene ricostruito dalla sorgente, quindi i numeri crescono.

Si tratta di poco più di 51.000 documenti distribuiti sui quattro indici ricercabili. L'indice papers è il singolo corpus più grande e quello su cui abbiamo lavorato di più: è l'intero flusso di finanza quantitativa di arXiv (q-fin.*) che risale al 1997, non un sottoinsieme selezionato a mano. In passato il sito offriva solo qualche centinaio di paper curati; l'indice attuale è il corpus q-fin completo, con la provenienza curata integrata in cima, così un paper che era anche referenziato da uno specifico blog quant porta con sé quell'attribuzione.

Oltre ai quattro indici di ricerca, il sito rivolto agli umani aggiunge altri strati: note di ricerca e digest quotidiani che scriviamo noi stessi, una directory di siti e autori quant, una sezione videos che indicizza i canali YouTube rilevanti e una directory di fondi. I quattro indici sono la spina dorsale ricercabile; tutto il resto è curatela attorno ad essa.

Singola fonte di verità

La cosa che, agli inizi, si è rotta silenziosamente per noi — e contro cui ora progettiamo con decisione — è il disallineamento dei conteggi. La homepage diceva un numero, la ricerca ne restituiva un altro, l'API un terzo. A un certo punto la pagina principale pubblicizzava 719 paper mentre la ricerca ne restituiva oltre 18.000. Nulla è più corrosivo per la fiducia in uno strumento di ricerca di un corpus che non riesce a mettersi d'accordo con se stesso su quanto sia grande.

La soluzione è stata far leggere ogni superficie da un unico posto. Per il corpus dei paper, Meilisearch è la fonte di verità. Non c'è una seconda copia dei paper che vive nel bundle dell'app; il conteggio sulla homepage, il conteggio su /papers, il conteggio restituito dall'API e i documenti che cerchi effettivamente sono tutti lo stesso indice. Il corpus stesso viene costruito offline da uno step di ingestione che prende l'insieme curato dei paper, lo unisce al flusso di arXiv (deduplicato per id arXiv, con gli array di provenienza uniti), ordina dal più recente e scrive un singolo file da ~25 MB che l'indicizzatore consuma. Quel file è grosso modo 15.000–18.000 record ed è deliberatamente non incluso nel client — un corpus di quelle dimensioni non ha alcun motivo di essere spedito a un browser.

Gli altri tre dataset (code, articles, script Pine) vengono letti lato server dai loro file JSON e indicizzati dagli stessi file, con la migrazione a Meili-come-sorgente come prossimo passo pianificato. La regola valida su tutta la linea: leggere i dati sul server, non fare mai import di un dataset di diversi megabyte nel bundle del client, e lasciare che l'indice e i conteggi mostrati provengano dalla stessa origine. Il disallineamento diventa strutturalmente impossibile.

Ricerca: a tutto testo, tollerante agli errori di battitura, sfaccettata

Il motore di ricerca è Meilisearch, che gira sullo stesso server dell'app e legato a localhost — non è esposto pubblicamente. Lo usiamo come motore di ricerca a tutto testo, non come archivio di vettori. Niente embedding, niente magia di similarità semantica. Per "trovami i paper e i repo che menzionano questo concetto", la ricerca lessicale tollerante agli errori di battitura su titoli, abstract, descrizioni, autori e tag è veloce, prevedibile e debuggabile in un modo che un indice di embedding non è. Ogni indice memorizza il documento originale completo più un _id aggiunto, così una ricerca restituisce record pienamente idratati che l'app può renderizzare direttamente — nessuna seconda fetch per reidratare i risultati.

Alcuni dettagli che contano nella pratica:

• La tolleranza agli errori di battitura e il ranking di rilevanza arrivano gratis da Meilisearch. Cercare momentm trova comunque i paper sul momentum; i risultati sono ordinati, non solo filtrati.

• Filtraggio sfaccettato. I paper si filtrano per category arXiv (q-fin.PM, q-fin.TR, …), i repo per language e stars, gli articoli per source e date, gli script Pine per category. La pagina /papers costruisce il suo menu a tendina delle categorie a partire dalla distribuzione dei facet dal vivo dell'indice, così le opzioni di filtro riflettono sempre ciò che c'è effettivamente nel corpus.

• Suddivisione del camelCase. Meilisearch tokenizza su spazi bianchi e punteggiatura, ma non sul camelCase. Questo significa che un repo letteralmente chiamato TradingAgents sarebbe un singolo token, irraggiungibile dalla query naturale "trading agents". Durante l'indicizzazione deriviamo un campo name_split — TradingAgents → TradingAgents Trading Agents, ai-hedge-fund → ai-hedge-fund ai hedge fund — e lo aggiungiamo agli attributi ricercabili. Il token originale viene tenuto per primo così le corrispondenze sul nome esatto continuano a posizionarsi più in alto, e il campo derivato non viene mai restituito ai client. È una piccola cosa che fa la differenza tra trovare il repo di punta e non trovarlo.

• Sfogliare = dal più recente. Una query vuota non è un errore; è il percorso di esplorazione. Su /papers una query vuota ordina per published in ordine decrescente, così la pagina funge anche da feed in ordine cronologico inverso della ricerca q-fin più recente.

• Un indice laterale per gli aggregati. Alcuni numeri Meilisearch non può calcolarli a buon mercato al momento della query — il totale delle stelle su tutti i repo, il totale dei file Python, il totale dei notebook. Anziché scansionare l'intero corpus a ogni caricamento di pagina, l'indicizzatore scrive quelle somme una sola volta, al momento dell'indicizzazione, in un piccolo indice researcher_meta che contiene un documento per dataset. L'endpoint stats le rilegge direttamente. I conteggi che cambiano solo alla reindicizzazione vengono calcolati solo alla reindicizzazione.

• Un tetto di paginazione che è davvero utilizzabile. L'indice dei paper alza il maxTotalHits di Meilisearch a 50.000 e marca published come ordinabile, così puoi paginare a fondo in un corpus di ~18k documenti e ordinare l'intera cosa dal più recente — non solo la prima pagina di risultati di rilevanza.

L'indicizzatore è idempotente: crea ogni indice se assente, riapplica le impostazioni e fa l'upsert di ogni documento in batch da 2.000 con chiave _id (i paper derivano la propria dall'id arXiv, i repo e gli articoli da un hash dell'URL). Poiché l'intero indice è ricostruibile dal file sorgente, non c'è alcun backup da gestire — un rollback è semplicemente una reindicizzazione. Rieseguirlo è sicuro per costruzione.

Accessibile agli agenti: MCP e una API pubblica

Ecco la parte che lega researcher al resto di ciò che facciamo. Il corpus non è solo un sito web con una casella di ricerca — è uno strumento che un agente AI può chiamare.

L'endpoint MCP

researcher espone un server Model Context Protocol su /api/mcp tramite Streamable HTTP. Qualsiasi agente compatibile con MCP — Claude, un agente personalizzato nel nostro stack, qualunque cosa parli il protocollo — può connettersi e chiamare strumenti di sola lettura contro il corpus dal vivo. Ci sono 13 strumenti, raggruppati per dataset, che seguono una forma coerente search / get / list:

Gli schemi degli strumenti sono scritti a beneficio di un agente, non di un umano. search_papers, per esempio, si presenta come ricerca tollerante agli errori di battitura e ordinata per rilevanza su titolo, abstract e autori, con un filtro category opzionale (es. q-fin.PM) e un limite di risultati — e dice all'agente di chiamare get_paper per l'abstract completo una volta che ha ristretto il campo. search restituisce risultati compatti, della dimensione di uno snippet, così un agente può scorrere molti risultati a basso costo; get restituisce il record completo una volta che ne ha scelto uno. Quella forma a due passi impedisce alla finestra di contesto di un agente di annegare in abstract di cui non ha bisogno.

Concretamente, un agente che indaga, diciamo, sull'esecuzione ottimale può eseguire search_papers("optimal execution", category: "q-fin.TR") per ottenere una rosa ristretta e ordinata di titoli e snippet, search_repos("optimal execution", language: "Python") per trovare implementazioni ordinate per rilevanza e filtrabili per stelle, e search_pine("VWAP") per vedere come la stessa idea si presenta come strategia pubblicata su TradingView — tre chiamate a strumenti contro tre corpora che, un'ora fa, erano tre siti web diversi. Poi un singolo get_paper recupera l'abstract completo per quello che sembrava promettente. L'agente non lascia mai il protocollo, e ogni risultato è un record reale e idratato anziché uno stub di risultato di ricerca che deve andare a recuperare di nuovo.

La REST API pubblica

Per i consumatori non-MCP c'è una superficie REST parallela sotto /api/v1/: papers, repos, articles, pine, e un aggregato stats. Parla JSON puro con i parametri q, category, limit e offset, restituisce il totale reale e la distribuzione dei facet insieme a ciascuna pagina, ed è abilitata al CORS. GET /api/v1/papers?q=optimal+execution&category=q-fin.TR è un one-liner da qualsiasi parte. Lo stesso endpoint alimenta la pagina /papers del sito stesso — il browser è solo un altro client dell'API.

Fallire onestamente

Un backend di ricerca che mente è peggio di uno che è fuori uso. Abbiamo preso una posizione deliberata su cosa succede quando Meilisearch è irraggiungibile. Il livello dati solleva un'eccezione in caso di errore anziché restituire silenziosamente risultati vuoti — e sono i chiamanti a decidere come gestirla. Per i dataset che mantengono ancora una copia in memoria, gli strumenti ripiegano su un semplice .filter() su quella copia, così il sito resta in piedi. Per i paper, dove Meilisearch è la fonte di verità e non c'è una seconda copia, gli strumenti e l'API restituiscono un errore esplicito (l'API risponde 503) anziché servire dati obsoleti o parziali. Ogni chiamata di ricerca ha un timeout breve così un indice bloccato non può paralizzare uno strumento. Il principio: degradare rumorosamente, non restituire mai in silenzio risposte sbagliate.

Come i dati entrano

Il corpus è alimentato da una pipeline di scraper, tutti che girano contro sorgenti gratuite e pubbliche.

• I paper provengono dall'API Atom di arXiv. Un harvester estrae l'intero corpus q-fin in JSONL, uno step di build lo unisce all'insieme curato (dedup per id arXiv, provenienza unita), e il risultato viene passato all'indicizzatore. L'harvester ha anche una modalità "arricchisci questi id specifici" per il seeding da liste di lettura esterne.
• Il codice è un crawl di repository GitHub rilevanti per il quant, catturati con i metadati che contano per il filtraggio — stelle, fork, linguaggio primario, topic, e conteggi di file Python e notebook.
• Gli articoli vengono scrapati da blog e aggregatori quant, con i migliori mirrorati localmente così sopravvivono al link rot. La homepage segnala di quali articoli abbiamo salvato una copia locale.
• Le strategie sono script Pine di TradingView con i loro metadati — autore, categoria, tag, like, e se la pubblicazione include codice, un grafico o un'analisi.
• I video indicizzano i canali YouTube rilevanti così i talk e i walkthrough sono individuabili insieme al materiale scritto.

La reindicizzazione in produzione gira su un tunnel SSH verso il Meilisearch legato a localhost, perché il motore non è mai esposto a internet. L'intero ciclo — harvest, build, deploy, index — è progettato per essere rieseguito in modo idempotente, che è esattamente ciò che fa il cron quotidiano.

Accesso e hosting

researcher gira sul nostro Server 1 come un piccolo stack Docker Compose: un container Next.js dietro Traefik e un container Meilisearch legato a localhost. L'app Next.js legge i suoi dataset lato server e parla con Meilisearch sulla rete interna.

L'accesso è regolato tramite auth.marketmaker.cc, il nostro servizio di identità condiviso. I token sono JWT RS256 verificati contro il JWKS del servizio di autenticazione — ogni decisione di autorizzazione controlla la firma (con controlli rigorosi su issuer e algoritmo, fallendo in modo chiuso se l'endpoint della chiave è irraggiungibile), e il percorso di decodifica non verificata viene usato solo per UI cosmetica come mostrare la tua email nella navbar. Il servizio di autenticazione emette ruoli per-servizio; su researcher il ruolo admin regola l'area di amministrazione interna (dove eseguiamo e monitoriamo gli scraper), e la homepage pubblica non ha bisogno di alcun token. È lo stesso tessuto di autenticazione che fa da fronte agli altri nostri strumenti interni, così un solo login vale per tutto l'ecosistema.

Dove si colloca nello stack Marketmaker

researcher è infrastruttura, non una destinazione. Il punto non è il sito web — è che ora abbiamo una vista interrogabile del campo che persone e agenti condividono.

Per noi come umani, è da lì che proviene gran parte di questo stesso blog. Quando esaminiamo uno strumento come VectorBT o sezioniamo un framework come TradingAgents o Fincept Terminal, il punto di partenza è spesso una ricerca su researcher: su quali paper si basa questo, quali altri repo risolvono lo stesso problema, chi ne ha scritto. L'archivio è l'imbuto; i post del blog sono ciò che ne esce.

Per i nostri agenti AI, è qualcosa di più strutturale. Un substrato di ricerca raggiungibile tramite MCP significa che un agente che lavora su strategie non deve fare scraping di arXiv dal vivo, destreggiarsi tra quattro API diverse o tirare a indovinare su cosa c'è là fuori — chiama search_papers, search_repos, search_pine contro un corpus che è già unificato, deduplicato e indicizzato. È la stessa direzione del nostro tooling command-and-operate (cmdop) e di quello degli agenti: dare agli agenti strumenti tipizzati, di sola lettura e ben documentati su dati reali, fallire rumorosamente quando il backend non è disponibile, e lasciare che un unico backend condiviso serva la UI umana e l'interfaccia macchina dagli stessi identici indici. L'umano sfoglia e l'agente interroga — ma stanno guardando lo stesso archivio, e questa è tutta l'idea.

Conclusione

researcher è nato come soluzione a un problema piccolo e fastidioso — che la ricerca quant è dispersa in quattro posti che non si parlano tra loro — e si è trasformato in qualcosa su cui ci appoggiamo quotidianamente. Grosso modo 51.000 documenti tra paper, codice, articoli e strategie, tutti dietro un unico motore di ricerca a tutto testo, tutti raggiungibili sia da un umano con un browser sia da un agente con un client MCP. È intenzionalmente poco affascinante: ricerca a tutto testo, non embedding; una singola fonte di verità, non una cache ingegnosa; strumenti che sollevano errori onesti, non strumenti che mascherano i guasti.

Se stai costruendo agenti per la ricerca sul trading, la lezione si generalizza al di là del nostro particolare corpus: la cosa a più alto effetto leva che puoi dare a un agente non è un modello più grande ma una vista pulita, unificata e interrogabile dei dati di cui ha bisogno — esposta attraverso gli stessi indici di cui gli umani si fidano. Questo è ciò che researcher è.