Cherche des passages dans le corpus de recherche quantitative (corpus dont la taille n'a pas pu être lue).

Couvre la volatilité et les options, la microstructure et l'exécution, les facteurs et l'alpha, la construction de portefeuille et le ML appliqué à la finance (1971–2026). Retourne des extraits classés, précédés de la décision de routage. Chaque extrait porte une ligne « citer : » — auteurs, année, titre, page — et c'est la seule à recopier dans une réponse : l'année fait partie de l'information, le corpus mélangeant des travaux de 1987 et des preprints de 2026. La ligne « interne : » porte chunk_id et document_id, qui servent à get_passage et ne sont pas des citations — ils ne survivent pas à un re-découpage du corpus et ne disent rien à un lecteur.

Les pages affichées sont celles d'un lecteur, et une plage quand le passage en couvre plusieurs : le système ne dispose pas d'un pointeur de phrase, et annoncer une page exacte pour un passage à cheval serait une précision qu'il n'a pas.

Protocole d'usage, mesuré sur 155 questions (benchmark/eval_protocol.py) :

• Une période explicite (« sources published in 2022 or earlier », « papers before 2010 », « depuis 2020 ») est détectée dans la question et transformée en year_min/year_max, la clause retirée du texte : rien à faire, sauf quand la période est implicite (« récent », « d'avant la crise ») — alors la traduire soi-même en year_min/year_max (+0,10 nDCG@10).

• Question ouverte, conceptuelle : une seule requête en langue naturelle, en anglais, qui décrit le problème ; la reformuler pour l'index n'a pas aidé (chantier C).

• N'utiliser mode="hybrid" que pour une requête faite d'identifiants mémorisés (auteur, acronyme, numéro, année : « Fukasawa SVI B2 B3 ») ; sur toute autre question il perd (−0,11 nDCG@10 sur 130 questions, −0,19 sur les tableaux). Depuis le 5 septembre 2026 on sait pourquoi : ce chemin empile deux composants mesurés négatifs — la fusion (−0,088 pooled, 14 variantes essayées, zéro en GO) et le reranker bge-base sur pool dense (−0,076 pooled, mesuré sur ce corpus). Il reste utile pour le cas des identifiants exacts ; ailleurs, le choisir est une erreur documentée.

• Question multi-documents ou exploratoire : compléter par search_graph / expand_entity / connect_entities sur les entités nommées de la question, puis lire les passages des deux sources ; ne pas fusionner aveuglément (mesuré : la fusion automatique perd).

Args: query: la question, en anglais de préférence (le corpus est anglophone). limit: nombre de passages à retourner (défaut 5). document_id: restreindre à un seul document. mode: "auto" (défaut) = recherche sémantique seule (dense) — depuis le banc de 150 questions, aucune règle automatique ne fait mieux. "hybrid" ajoute BM25+fusion+rerank : à demander explicitement quand la question est faite d'identifiants exacts dont l'utilisateur se souvient (Fukasawa, SVI, ITRAXX 2007, arXiv 1206.0682), et seulement dans ce cas — sur une question en langue naturelle, et sur les tableaux, l'hybride fait moins bien que le dense. rerank: laisser vide pour suivre le mode (activé en hybrid, désactivé en dense). True/False force. Mesuré : bge-reranker-base aide sur un pool hybride et nuit sur un pool dense (−0,076 nDCG@10 pooled, −0,147 sur les questions simples). Ne pas forcer rerank=True en mode dense. year_min: ne garder que les documents publiés à partir de cette année (inclus). year_max: ne garder que les documents publiés jusqu'à cette année (inclus). Une borne d'année exclut les documents dont l'année est inconnue (un nombre non lu de documents). Laissées vides, une période explicite dans la question est détectée et appliquée (la ligne « période: » de la réponse le dit) ; une borne donnée prime toujours. author: ne garder que les documents d'un auteur (sous-chaîne du nom, insensible aux accents et à la casse : "lopez de prado", "Gatheral", "Jacquier"). reclassement: "selectif" reclasse les dix premiers candidats par Qwen3-Reranker-0.6B en protégeant le rang 1 dense. Laisser vide (défaut) dans l'immense majorité des appels.

    **Ce que ça coûte** : ~3,2 s par requête contre 59 ms sans — un facteur **54** —
    et 2,4 Go de mémoire résidente tant que le modèle est chargé, sur une machine de
    16 Go qui tourne déjà avec 2,4 Go de swap. Ce n'est pas un réglage anodin.

    **Ce que ça rapporte** (155 questions, corpus 5530cba145) : l'or entre dans les
    cinq passages servis pour 19 questions et en sort pour 5. Net +14, et les cinq
    pertes sont un sous-ensemble strict des sept du reclassement plein.

    **Ce que ces 19 et ces 5 valent en RÉPONSE — mesuré le 8 septembre 2026** sur les
    24 questions concernées, jugées dans les deux bras : sur les 5 « pertes », **une
    seule** perd vraiment sa réponse ; les trois autres mesurables avaient une
    couverture nulle **dans les deux bras** — elles n'avaient rien à perdre. Sur les
    19 « gains », **12** gagnent vraiment une réponse. Le rapport réel est **12 pour
    1**, non 19 pour 5, et l'échange net vaut **+11 réponses**.

    **Ce que ça change pour toi** : le risque de dégrader une réponse en l'activant est
    **cinq fois plus petit** que ce que le paragraphe précédent laisse croire. Ce qui
    reste vrai, et qui est désormais la seule raison de ne pas l'activer partout, c'est
    le coût — 3,2 s et 2,4 Go sur une machine de 16 Go. Active-le sans hésiter quand la
    qualité de la réponse compte plus que trois secondes ; ne l'active pas en rafale
    sur une exploration où tu enchaînes dix recherches.

    **Quand le mettre** : quand un humain demande explicitement une recherche plus
    soignée, ou après avoir constaté qu'une première recherche a rendu des passages
    hors sujet sur une question dont on a de bonnes raisons de croire que le corpus
    porte la réponse.

    **Quand ne pas le mettre — et c'est le point important** : ne l'active pas « au
    cas où », ni systématiquement, ni selon une règle que tu te donnerais toi-même
    (longueur de la question, présence de chiffres, famille supposée). Une règle
    d'activation inventée par l'appelant est une **politique de routage non mesurée**,
    et ce dépôt a mesuré six fois que ses politiques de routage perdent. Le gain
    ci-dessus n'est valable que sur un usage à la demande ; il ne dit rien de ce que
    vaudrait une heuristique automatique, qui n'a jamais été évaluée.

    Un échec de reclassement ne casse jamais la recherche : l'ordre dense est rendu.

Retourne le passage complet d'un chunk_id, avec ses voisins immédiats, pour citation.

Args: chunk_id: la clé interne rendue par search_documents ou search_graph. max_characters: fenêtre servie. Vide = 15 000, la fenêtre du contrat de sortie. Le défaut historique était 6 000 et tronquait 30,2 % des fenêtres du corpus (médiane 4 520 c., max 13 982) : un outil dont le nom promet le passage entier en rendait moins d'un tiers du temps. neighbours: nombre de voisins de chaque côté (défaut 1, 0 pour le seul chunk demandé). Les voisins ne sont pas filtrés comme les résultats de recherche — un voisin en-tête est un intitulé de section, donc du contexte — mais ils sont déclarés dans la ligne « voisins : ».

Liste bibliographique des documents du corpus, du plus récent au plus ancien, sans recherche vectorielle.

Args: author: sous-chaîne du nom d'un auteur (insensible aux accents et à la casse). year_min: année de publication minimale (inclus). year_max: année de publication maximale (inclus). text: sous-chaîne du titre. limit: nombre maximal de lignes (défaut 50).

Chronologie d'un sujet : le meilleur passage de chaque document, groupé par année de publication.

Utile pour voir comment une idée a évolué (rough volatility 2014 → 2026) ou pour distinguer les travaux fondateurs des preprints récents.

Args: topic: le sujet, formulé comme une question ou un intitulé. year_min: borne basse (inclus). year_max: borne haute (inclus). limit: nombre de documents (défaut 20).

Vérifie qu'une citation se trouve vraiment dans le document qu'elle nomme.

À utiliser avant d'affirmer qu'un document dit quelque chose, et surtout quand la citation vient d'ailleurs que d'un passage servi à l'instant : d'une note prise plus tôt, d'un résumé, d'une réponse antérieure. Une citation recopiée de travers, recollée à partir de deux endroits ou reformulée reste plausible à la lecture — c'est précisément ce que cet outil détecte, et rien d'autre ne le détecte.

La vérification est déterministe : aucune génération, aucun modèle de langue. La citation est normalisée (ligatures, <sup>/<sub>, tirets, guillemets, blancs, casse) puis cherchée dans le texte canonique du document, celui dont le sha256 est servi par la ligne « ancre : ».

Ce que rend l'outil :

• trouve — vrai seulement pour une correspondance exacte après normalisation. Une citation dont un seul mot diffère rend false. Mesuré : 50 extraits réels sur 50 retrouvés, 0 accepté sur 50 extraits altérés d'un mot.

• offsets — la position [début, fin] dans le texte canonique, opposable.

• plus_proche — quand c'est faux : le passage le plus ressemblant, sa ressemblance et le nombre de mots qui diffèrent. C'est ce qui dit où la citation a dérivé.

• source — texte canonique, ou texte servi pour les 5 914 tableaux dont le rendu Markdown n'est pas une sous-chaîne du document.

Args: document_id: la clé interne du document, servie par la ligne « interne : ». quote: le texte cité, tel qu'on s'apprête à l'affirmer. Une phrase ou deux suffisent ; au-delà d'un paragraphe, une reformulation invisible fera échouer la vérification pour une raison sans rapport avec l'honnêteté de la citation. chunk_id: facultatif, restreint la recherche du repli « texte servi » à ce passage.

Vérifie plusieurs citations d'un coup — même contrat que verify_citation.

Args: citations: liste d'objets {"document_id": …, "quote": …, "chunk_id": … (facultatif)}. Vérifier ensemble les citations d'une même réponse coûte à peine plus qu'une seule : le texte canonique d'un document n'est lu qu'une fois.

Décrit l'index : documents, passages, couverture des métadonnées (années, auteurs), backend et device, et l'état du graphe d'entités (nombre d'entités, relations, état du corpus sur lequel il a été bâti).

Cherche dans le graphe d'entités : les passages qui MENTIONNENT une entité dont le nom contient query.

Complémentaire de search_documents (sémantique) : ici la correspondance est nominale et exacte — « Gatheral » retourne les passages où Gatheral est cité, « SVI » ceux où SVI apparaît, même quand la question sémantique ne les ferait pas remonter. Les entités ont été extraites par GLiNER2 sur chaque passage (personnes, organisations, instruments, concepts de marché, mesures, méthodes, jeux de données). Même format de sortie que search_documents : source citable, pages, chunk_id (pour get_passage), plus les entités reconnues dans le passage. Croiser avec search_documents : le graphe ne connaît que les noms, pas le sens.

Args: query: nom d'entité ou fragment (« Gatheral », « rough volatility », « SVI », « S&P 500 »). Casse et accents ignorés ; « Lopez de Prado » trouve « López de Prado ». entity_type: restreindre à un type : person, organization, financial_instrument, market_concept, measure, method, dataset. relation: ne garder que les passages où l'entité est tête ou queue d'une relation de ce type : measures, predicts, causes, depends_on, correlates_with, applies_to, uses_method, compares_with, is_a, part_of. top_k: nombre de passages (défaut 10, au plus 2 par document).

Entités reliées à entity_name dans le graphe, par relation, avec les passages qui l'attestent.

Répond à « quelles méthodes dépendent de la rough volatility ? », « à quoi SVI est-il comparé ? ». Chaque voisin porte la relation et son sens (→ : l'entité est la tête, ← : la queue), le nombre de passages qui soutiennent le lien et jusqu'à trois chunk_id à lire avec get_passage. Les relations viennent de GLiNER2 (seuil 0,5) et sont clairsemées : un lien attesté par un seul passage est une piste, pas un fait ; lire le passage avant de l'affirmer. Sans relation, la réponse liste aussi les CO-MENTIONS : les entités citées dans les mêmes passages, pondérées par leur rareté — la vue la plus utile pour explorer un sujet (auteurs, modèles, mesures qui vont avec).

Args: entity_name: nom de l'entité (« rough volatility », « Heston model », « Gatheral »). L'entité exacte et ses variantes de nom (« rough volatility models ») sont réunies. relation: une seule relation (measures, predicts, causes, depends_on, correlates_with, applies_to, uses_method, compares_with, is_a, part_of) ; vide = toutes. entity_type: type de l'entité de départ, si le nom est ambigu (person, market_concept…). limit: nombre de voisins (défaut 20), classés par nombre de passages qui les attestent.

Passages et documents qui mentionnent LES DEUX entités (« SVI » et « rough volatility »).

Pour trouver où deux idées se rencontrent dans le corpus. Liste les documents par nombre de passages communs, puis les meilleurs passages avec chunk_id. Aucun passage commun est une information en soi : les deux entités ne sont jamais citées ensemble dans un même passage.

Args: entity_a: première entité (nom ou fragment, variantes réunies). entity_b: seconde entité. top_k: nombre de passages (défaut 10, au plus 2 par document).