search_documents
Find cited passages in quantitative finance research (1971–2026). Filter by year, author, or document to get ranked, verifiable excerpts.
Instructions
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.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | auto | |
| limit | No | ||
| query | Yes | ||
| author | No | ||
| rerank | No | ||
| year_max | No | ||
| year_min | No | ||
| document_id | No | ||
| reclassement | No |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |