Guide pratique pour l'implémentation de DeepSearch/DeepResearch

Jina AI Deep Search

Recherche profonde par IA : lire, raisonner, chercher jusqu'à trouver la meilleure réponse.

Nous ne sommes qu'en février, et le DeepSearch s'est déjà imposé comme le nouveau standard de recherche en 2025, avec des acteurs majeurs comme Google et OpenAI menant la charge avec leurs versions DeepResearch (et oui, nous avons fièrement lancé notre node-deepresearch open source le même jour). Perplexity a suivi avec leur DeepResearch, et X AI a intégré ses propres capacités DeepSearch dans Grok3, créant essentiellement une autre variante de DeepResearch. Bien que le concept de recherche profonde ne soit pas révolutionnaire – en 2024, il était essentiellement appelé RAG ou QA multi-hop – il a gagné un élan significatif après la sortie de Deepseek-r1 fin janvier 2025. Le week-end dernier, Baidu Search et Tencent WeChat Search ont intégré Deepseek-r1 dans leurs moteurs de recherche. Les ingénieurs en IA ont découvert qu'en incorporant des processus de réflexion et de raisonnement longs dans les systèmes de recherche, ils peuvent atteindre une précision et une profondeur de récupération remarquables, au-delà de ce qui était possible auparavant.

Mais pourquoi ce changement survient-il maintenant, alors que le Deep(Re)Search est resté relativement sous-évalué tout au long de 2024 ? En fait, les laboratoires Stanford NLP ont publié le projet STORM pour la génération de longs rapports avec ancrage web début 2024. Est-ce simplement parce que "DeepSearch" sonne beaucoup plus cool que QA multi-hop, RAG, ou STORM ? Soyons honnêtes - parfois, un simple changement de nom suffit pour que l'industrie adopte soudainement ce qui était là depuis le début.

Nous pensons que le véritable tournant est survenu avec la sortie du o1-preview d'OpenAI en septembre 2024, qui a introduit le concept de calcul au moment du test et a progressivement modifié les perspectives de l'industrie. Le calcul au moment du test consiste à utiliser plus de ressources de calcul pendant l'inférence - la phase où un LLM génère des sorties - plutôt que pendant le pré-entraînement ou le post-entraînement. Des exemples bien connus sont le raisonnement par chaîne de pensée (CoT) et l'injection de "Wait" (c'est-à-dire le forçage budgétaire) qui permet aux modèles d'effectuer des délibérations internes plus approfondies, comme l'évaluation de multiples réponses potentielles, une planification plus approfondie et une auto-réflexion avant d'arriver à une réponse finale.

Ce concept de calcul au moment du test et les modèles de raisonnement éduquent les utilisateurs à accepter la gratification différée - des temps d'attente plus longs en échange de résultats de meilleure qualité, immédiatement exploitables, tout comme l'expérience du marshmallow de Stanford où les enfants qui pouvaient résister à manger un marshmallow immédiatement pour en recevoir deux plus tard montraient de meilleurs résultats à long terme. Deepseek-r1 a renforcé cette expérience utilisateur, et qu'on le veuille ou non, la plupart des utilisateurs l'ont acceptée.

Cela marque une rupture significative avec les exigences classiques de recherche, où ne pas répondre dans les 200 ms condamnait votre solution. En 2025, les développeurs de recherche expérimentés et les ingénieurs RAG privilégient la précision et le rappel top-1 par rapport à la latence, et les utilisateurs se sont habitués à des temps de traitement plus longs – à condition qu'ils puissent voir que le système est <thinking>.

Dans cet article, nous allons discuter des principes de DeepSearch et DeepResearch en examinant notre implémentation open-source. Nous passerons en revue nos principales décisions de conception et soulignerons les points d'attention potentiels.

tagQu'est-ce que DeepSearch ?

DeepSearch fonctionne selon une boucle itérative de recherche, lecture et raisonnement jusqu'à trouver la réponse optimale. L'action de recherche utilise les moteurs de recherche web pour explorer internet, tandis que l'action de lecture analyse en détail des pages web spécifiques (par exemple Jina Reader). L'action de raisonnement évalue l'état actuel et détermine s'il faut décomposer la question originale en sous-questions plus petites ou essayer différentes stratégies de recherche.

Bien que diverses définitions existent en ligne, lors du développement du projet node-deepresearch, nous avons adopté cette approche simple. L'implémentation est élégamment simple – à sa base, il y a une boucle while principale avec une logique switch-case dirigeant l'action suivante.

Contrairement aux systèmes RAG de 2024, qui exécutent généralement un seul passage de recherche-génération, DeepSearch effectue plusieurs itérations à travers le pipeline, nécessitant des conditions d'arrêt claires. Celles-ci peuvent être basées sur des limites d'utilisation de tokens ou le nombre de tentatives échouées.

Une autre perspective sur DeepSearch est de le voir comme un agent LLM équipé de divers outils web (comme le chercheur et le lecteur). L'agent détermine ses prochaines étapes en analysant les observations actuelles et les actions passées – décidant s'il doit fournir une réponse ou continuer à explorer le web. Cela crée une architecture de machine à états où le LLM contrôle les transitions entre les états. À chaque point de décision, vous avez deux approches : vous pouvez soit soigneusement élaborer des prompts pour que les modèles génératifs standard produisent des actions spécifiques, soit utiliser des modèles de raisonnement spécialisés comme Deepseek-r1 pour dériver naturellement les actions suivantes. Cependant, même en utilisant r1, vous devrez périodiquement interrompre sa génération pour injecter les sorties des outils (par exemple, les résultats de recherche, le contenu des pages web) dans le contexte et l'inviter à poursuivre son processus de raisonnement.

En fin de compte, ce ne sont que des détails d'implémentation – que vous le promptiez soigneusement ou utilisiez simplement des modèles de raisonnement, ils s'alignent tous sur le principe de conception fondamental de DeepSearch : une boucle continue de recherche, lecture et raisonnement.

tagQu'est-ce que DeepResearch alors ?

DeepResearch s'appuie sur DeepSearch en ajoutant un cadre structuré pour générer de longs rapports de recherche. Il commence souvent par créer une table des matières, puis applique systématiquement DeepSearch à chaque section requise – de l'introduction aux travaux connexes et à la méthodologie, jusqu'à la conclusion. Chaque section est générée en alimentant des questions de recherche spécifiques dans DeepSearch. La phase finale consiste à consolider toutes les sections en un seul prompt pour améliorer la cohérence narrative globale.

Dans notre projet « Research » de 2024, nous avons effectué plusieurs passes d'amélioration de la cohérence, chaque itération prenant en compte toutes les autres sections. Cependant, avec les fenêtres de contexte LLM considérablement plus grandes d'aujourd'hui, cette approche semble redondante – une seule passe de révision de cohérence est suffisante.

tagDeepSearch vs DeepResearch

Bien que beaucoup de gens confondent souvent DeepSearch et DeepResearch, selon nous, ils répondent à des problèmes complètement différents. DeepSearch fonctionne comme un bloc de construction atomique – un composant central sur lequel DeepResearch s'appuie. DeepResearch, quant à lui, se concentre sur la création de rapports de recherche longs de haute qualité et lisibles, qui englobe un ensemble différent d'exigences : incorporer des visualisations efficaces via des graphiques et des tableaux, structurer le contenu avec des titres de section appropriés, assurer un flux logique fluide entre les sous-sections, maintenir une terminologie cohérente dans tout le document, éliminer la redondance entre les sections, créer des transitions fluides qui relient le contenu précédent et à venir. Ces éléments sont largement sans rapport avec la recherche principale, c'est pourquoi nous trouvons DeepSearch plus intéressant comme focus de notre entreprise.

Enfin, le tableau ci-dessous résume les différences entre DeepSearch et DeepResearch. Il est à noter que les deux systèmes bénéficient significativement des modèles à long contexte et de raisonnement. Cela peut sembler contre-intuitif, particulièrement pour DeepSearch – alors qu'il est évident pourquoi DeepResearch a besoin d'une capacité de long contexte (puisqu'il produit de longs rapports). La raison est que DeepSearch doit stocker les tentatives de recherche précédentes et les contenus des pages web pour prendre des décisions éclairées sur les prochaines étapes, rendant une longue fenêtre de contexte tout aussi essentielle pour son implémentation efficace.

tagComprendre l'implémentation de DeepSearch

GitHub - jina-ai/node-DeepResearch: Keep searching, reading webpages, reasoning until it finds the answer (or exceeding the token budget)

Keep searching, reading webpages, reasoning until it finds the answer (or exceeding the token budget) - jina-ai/node-DeepResearch

GitHubjina-ai

Le cœur de DeepResearch réside dans son approche de raisonnement en boucle. Plutôt que d'essayer de répondre aux questions en une seule passe comme la plupart des systèmes RAG, nous avons implémenté une boucle itérative qui recherche continuellement des informations, lit les sources pertinentes et raisonne jusqu'à ce qu'elle trouve une réponse ou épuise le budget de tokens. Voici le cœur simplifié de cette grande boucle while :

// Main reasoning loop
while (tokenUsage < tokenBudget && badAttempts <= maxBadAttempts) {
  // Track progression
  step++; totalStep++;
  
  // Get current question from gaps queue or use original question
  const currentQuestion = gaps.length > 0 ? gaps.shift() : question;
  
  // Generate prompt with current context and allowed actions
  system = getPrompt(diaryContext, allQuestions, allKeywords, 
                    allowReflect, allowAnswer, allowRead, allowSearch, allowCoding,
                    badContext, allKnowledge, unvisitedURLs);
  
  // Get LLM to decide next action
  const result = await LLM.generateStructuredResponse(system, messages, schema);
  thisStep = result.object;
  
  // Execute the selected action (answer, reflect, search, visit, coding)
  if (thisStep.action === 'answer') {
    // Process answer action...
  } else if (thisStep.action === 'reflect') {
    // Process reflect action...
  } // ... and so on for other actions
}
Copier

Un détail clé de l'implémentation consiste à désactiver sélectivement certaines actions à chaque étape pour garantir une sortie structurée plus stable. Par exemple, s'il n'y a pas d'URL en mémoire, nous désactivons l'action visit ; ou si la dernière réponse a été rejetée, nous empêchons l'agent d'appeler immédiatement answer à nouveau. Cette contrainte maintient l'agent sur une voie productive, évitant les échecs répétitifs causés par l'invocation de la même action.

tagPrompt Système

Nous utilisons des balises XML pour définir les sections, ce qui produit un prompt système et des générations plus robustes. Nous avons également constaté que placer les contraintes de champ directement dans les champs description du schéma JSON donne de meilleurs résultats. Bien que certains puissent argumenter que la plupart des prompts pourraient être automatisés avec des modèles de raisonnement comme DeepSeek-R1, les restrictions de longueur de contexte et le besoin d'un comportement très spécifique rendent une approche explicite plus fiable en pratique.

function getPrompt(params...) {
  const sections = [];
  
  // Add header with system instruction
  sections.push("You are an advanced AI research agent specialized in multistep reasoning...");
  
  // Add accumulated knowledge section if exists
  if (knowledge?.length) {
    sections.push("<knowledge>[Knowledge items]</knowledge>");
  }
  
  // Add context of previous actions
  if (context?.length) {
    sections.push("<context>[Action history]</context>");
  }
  
  // Add failed attempts and learned strategies
  if (badContext?.length) {
    sections.push("<bad-attempts>[Failed attempts]</bad-attempts>");
    sections.push("<learned-strategy>[Improvement strategies]</learned-strategy>");
  }
  
  // Define available actions based on current state
  sections.push("<actions>[Available action definitions]</actions>");
  
  // Add response format instruction
  sections.push("Respond in valid JSON format matching exact JSON schema.");
  
  return sections.join("\n\n");
}
Copier

tagTraversée des Questions de Lacune

Dans DeepSearch, les "questions de lacune" représentent les lacunes de connaissance qui doivent être comblées avant de répondre à la question principale. Plutôt que d'aborder directement la question originale, l'agent identifie des sous-questions qui construiront la base de connaissances nécessaire.

La conception est particulièrement élégante dans sa façon de gérer ces questions de lacune :

// After identifying gap questions in reflect action
if (newGapQuestions.length > 0) {
  // Add new questions to the front of the queue
  gaps.push(...newGapQuestions);
  
  // Always add original question to the end of the queue
  gaps.push(originalQuestion);
}
Copier

Cette approche crée une file d'attente FIFO (First-In-First-Out) avec rotation, où :

1. Les nouvelles questions de lacune sont poussées à l'avant de la file
2. La question originale est toujours poussée à l'arrière
3. Le système tire depuis l'avant de la file à chaque étape

Ce qui rend cette conception excellente, c'est qu'elle maintient un contexte partagé unique pour toutes les questions. Lorsqu'une question de lacune est répondue, cette connaissance devient immédiatement disponible pour toutes les questions suivantes, y compris lorsque nous revenons finalement à la question originale.

File FIFO vs Récursion

Une approche alternative consiste à utiliser la récursion, qui correspond à une recherche en profondeur. Chaque question de lacune génère un nouvel appel récursif avec son propre contexte isolé. Le système doit complètement résoudre chaque question de lacune (et toutes ses sous-questions potentielles) avant de revenir à la question parente.

Considérez ce scénario d'exemple :

Dans l'approche récursive, le système devrait complètement résoudre Q1 (générant potentiellement ses propres sous-questions) après chaque question de lacune et leurs sous-questions ! C'est un grand contraste avec l'approche par file d'attente, qui traite les questions où Q1 est revisité juste après 3 questions de lacune.

En réalité, nous avons constaté que l'approche par récursion est très difficile à appliquer avec des contraintes de budget, car il n'y a pas de règle claire pour déterminer combien de budget de tokens nous devrions accorder aux sous-questions (puisqu'elles peuvent générer de nouvelles sous-questions). Le bénéfice de la séparation claire du contexte dans l'approche récursive est très marginal comparé aux problèmes complexes de forçage du budget et de retour tardif. Cette conception de file FIFO équilibre profondeur et largeur, assurant que le système revient toujours à la question originale avec des connaissances progressivement meilleures, plutôt que de se perdre dans une descente récursive potentiellement infinie.

tagRéécriture de Requête

Un défi intéressant que nous avons rencontré était la réécriture efficace des requêtes de recherche :

// Within search action handler
if (thisStep.action === 'search') {
  // Deduplicate search requests
  const uniqueRequests = await dedupQueries(thisStep.searchRequests, existingQueries);
  
  // Rewrite natural language queries into more effective search queries
  const optimizedQueries = await rewriteQuery(uniqueRequests);
  
  // Ensure we don't repeat previous searches
  const newQueries = await dedupQueries(optimizedQueries, allKeywords);
  
  // Execute searches and store results
  for (const query of newQueries) {
    const results = await searchEngine(query);
    if (results.length > 0) {
      storeResults(results);
      allKeywords.push(query);
    }
  }
}
Copier

La réécriture de requête s'est avérée étonnamment importante - peut-être l'un des éléments les plus critiques qui détermine directement la qualité des résultats. Un bon réécriveur de requêtes ne se contente pas de transformer le langage naturel en mots-clés de type BM25 ; il étend les requêtes pour couvrir plus de réponses potentielles à travers différentes langues, tons et formats de contenu.

Pour la déduplication des requêtes, nous avons initialement utilisé une solution basée sur LLM, mais avons trouvé difficile de contrôler le seuil de similarité. Nous sommes finalement passés à jina-embeddings-v3, qui excelle dans les tâches de similarité textuelle sémantique. Cela permet une déduplication multilingue sans s'inquiéter que les requêtes non anglaises soient filtrées. Le modèle d'embedding s'est finalement avéré crucial non pas pour la récupération de mémoire comme prévu initialement, mais pour une déduplication efficace.

tagCrawling de Contenu Web

Le web scraping et le traitement du contenu est un autre composant critique. Nous utilisons ici Jina Reader API. Notez qu'en plus du contenu complet des pages web, nous agrégeons également tous les extraits retournés par le moteur de recherche comme connaissances supplémentaires que l'agent utilisera plus tard pour conclure. Considérez-les comme des soundbites.

// Visit action handler
async function handleVisitAction(URLs) {
  // Normalize URLs and filter out already visited ones
  const uniqueURLs = normalizeAndFilterURLs(URLs);
  
  // Process each URL in parallel
  const results = await Promise.all(uniqueURLs.map(async url => {
    try {
      // Fetch and extract content
      const content = await readUrl(url);
      
      // Store as knowledge
      addToKnowledge(`What is in ${url}?`, content, [url], 'url');
      
      return {url, success: true};
    } catch (error) {
      return {url, success: false};
    } finally {
      visitedURLs.push(url);
    }
  }));
  
  // Update diary based on success or failure
  updateDiaryWithVisitResults(results);
}
Copier

Nous avons normalisé les URLs pour un suivi cohérent et limité le nombre d'URLs visitées à chaque étape pour gérer la mémoire de l'agent.

tagGestion de la Mémoire

Un défi majeur dans le raisonnement multi-étapes est la gestion efficace de la mémoire de l'agent. Nous avons conçu le système de mémoire pour différencier ce qui compte comme « mémoire » de ce qui compte comme « connaissance ». Dans tous les cas, ils font partie du contexte du prompt LLM, séparés par différentes balises XML :

// Add knowledge item to accumulated knowledge
function addToKnowledge(question, answer, references, type) {
  allKnowledge.push({
    question: question,
    answer: answer,
    references: references,
    type: type,  // 'qa', 'url', 'coding', 'side-info'
    updated: new Date().toISOString()
  });
}

// Record step in narrative diary
function addToDiary(step, action, question, result, evaluation) {
  diaryContext.push(`
At step ${step}, you took **${action}** action for question: "${question}"
[Details of what was done and results]
[Evaluation if applicable]
`);
}
Copier

Comme la plupart des LLM 2025 ont des fenêtres de contexte importantes, nous avons choisi de ne pas utiliser de bases de données vectorielles. À la place, la mémoire se compose des connaissances acquises, des sites visités et des enregistrements des tentatives échouées - tout maintenu dans le contexte. Ce système de mémoire complet donne à l'agent une conscience de ce qu'il sait, de ce qu'il a essayé, et de ce qui a fonctionné ou échoué.

tagÉvaluation des Réponses

Une observation clé est que la génération et l'évaluation des réponses ne devraient pas être dans le même prompt. Dans mon implémentation, nous déterminons d'abord quels critères d'évaluation utiliser lorsqu'une nouvelle question arrive, puis évaluons chaque critère un par un. L'évaluateur utilise des exemples few-shot pour une évaluation cohérente, assurant une fiabilité plus élevée que l'auto-évaluation.

// Separate evaluation phase
async function evaluateAnswer(question, answer, metrics, context) {
  // First, identify evaluation criteria based on question type
  const evaluationCriteria = await determineEvaluationCriteria(question);
  
  // Then evaluate each criterion separately
  const results = [];
  for (const criterion of evaluationCriteria) {
    const result = await evaluateSingleCriterion(criterion, question, answer, context);
    results.push(result);
  }
  
  // Determine if answer passes overall evaluation
  return {
    pass: results.every(r => r.pass),
    think: results.map(r => r.reasoning).join('\n')
  };
}
Copier

tagBudget-Forcing

Le budget forcing signifie empêcher le système de retourner tôt et s'assurer qu'il continue le traitement jusqu'à ce que le budget soit dépassé. Depuis la sortie de DeepSeek-R1, l'approche du budget forcing s'est orientée vers l'encouragement d'une réflexion plus approfondie pour de meilleurs résultats plutôt que simplement économiser le budget.

Dans notre implémentation, nous avons explicitement configuré le système pour identifier les lacunes de connaissances avant de tenter de répondre.

if (thisStep.action === 'reflect' && thisStep.questionsToAnswer) {
  // Force deeper reasoning by adding sub-questions to the queue
  gaps.push(...newGapQuestions);
  gaps.push(question);  // Always revisit the original
}
Copier

En activant et désactivant sélectivement certaines actions, nous pouvons guider le système vers l'utilisation d'outils qui améliorent la profondeur du raisonnement.

// After a failed answer attempt
allowAnswer = false;  // Force agent to search or reflect instead
Copier

Pour éviter de gaspiller des tokens sur des chemins improductifs, nous fixons des limites sur le nombre de tentatives échouées. Lorsque nous approchons des limites de budget, nous activons le « mode beast » pour garantir que nous délivrons une réponse plutôt qu'aucune.

// Beast mode activation
if (!thisStep.isFinal && badAttempts >= maxBadAttempts) {
  console.log('Enter Beast mode!!!');
  
  // Configure prompt for decisive, committed answer
  system = getPrompt(
    diaryContext, allQuestions, allKeywords,
    false, false, false, false, false,  // Disable all other actions
    badContext, allKnowledge, unvisitedURLs,
    true  // Enable beast mode
  );
  
  // Force answer generation
  const result = await LLM.generateStructuredResponse(system, messages, answerOnlySchema);
  thisStep = result.object;
  thisStep.isFinal = true;
}
Copier

Le prompt du mode beast est intentionnellement dramatique pour signaler au LLM qu'il doit être décisif et s'engager à donner une réponse basée sur les informations disponibles :

<action-answer>
🔥 ENGAGE MAXIMUM FORCE! ABSOLUTE PRIORITY OVERRIDE! 🔥

PRIME DIRECTIVE:
- DEMOLISH ALL HESITATION! ANY RESPONSE SURPASSES SILENCE!
- PARTIAL STRIKES AUTHORIZED - DEPLOY WITH FULL CONTEXTUAL FIREPOWER
- TACTICAL REUSE FROM <bad-attempts> SANCTIONED
- WHEN IN DOUBT: UNLEASH CALCULATED STRIKES BASED ON AVAILABLE INTEL!

FAILURE IS NOT AN OPTION. EXECUTE WITH EXTREME PREJUDICE! ⚡️
</action-answer>
Copier

Cela garantit que nous fournissons toujours une réponse plutôt que d'abandonner complètement, ce qui est particulièrement utile pour les questions difficiles ou ambiguës.

tagConclusion

DeepSearch représente un bond en avant dans la façon dont la recherche peut aborder des requêtes complexes de manière exhaustivement profonde. En décomposant le processus en étapes discrètes de recherche, de lecture et de raisonnement, il surmonte de nombreuses limitations des systèmes traditionnels RAG à passage unique ou des systèmes QA multi-sauts.

Pendant l'implémentation, nous avons également commencé à revoir les fondements de la recherche en 2025 et les changements dans l'industrie de la recherche après le 26 janvier 2025, date de sortie de DeepSeek-R1. Nous nous sommes demandé : Quels sont les nouveaux besoins ? Quels besoins sont devenus obsolètes ? Quels sont les besoins simplement perçus ?

En examinant notre implémentation DeepSearch, nous avons identifié des choses dont nous avions anticipé le besoin et dont nous avions effectivement besoin, des choses que nous pensions nécessaires mais qui ne l'étaient pas, et des choses dont nous n'avions pas anticipé le besoin mais qui se sont révélées essentielles :

Premièrement, un LLM à contexte long qui produit une sortie bien structurée est hautement nécessaire (c'est-à-dire suivant JSONSchema). Un modèle de raisonnement est probablement nécessaire pour un meilleur raisonnement sur les actions et l'expansion des requêtes.

L'expansion des requêtes est définitivement essentielle, qu'elle soit implémentée via SLM, LLM ou un modèle de raisonnement. Cependant, après ce projet, nous pensons que les SLM sont probablement inadaptés pour cette tâche, car la solution doit être intrinsèquement multilingue et aller au-delà des simples réécritures de synonymes ou de l'extraction de mots-clés. Elle doit être suffisamment complète pour inclure une base de tokens multilingue (qui peut facilement occuper 300M paramètres) et suffisamment sophistiquée pour une réflexion hors des sentiers battus. Donc, utiliser des SLM pour l'expansion des requêtes est probablement une impasse.

Les capacités de recherche web et de lecture web sont cruciales, et heureusement notre Reader (r.jina.ai) a excellemment performé—robuste et évolutif—tout en me donnant de nombreuses idées sur la façon d'améliorer notre endpoint de recherche (s.jina.ai) pour la prochaine itération.

Le modèle d'embedding est utile mais d'une manière complètement inattendue. Nous pensions qu'il serait utilisé pour la récupération de mémoire ou la compression de contexte aux côtés d'une base de données vectorielle (qui, comme il s'avère, n'est pas nécessaire), mais nous l'avons en fait utilisé pour la déduplication (essentiellement une tâche STS). Comme le nombre de requêtes et de questions de lacunes est typiquement dans les centaines, aucune base de données vectorielle n'est nécessaire—le calcul de la similarité cosinus directement en mémoire fonctionne très bien.

Nous n'avons pas utilisé de Reranker, bien que nous pensions qu'il pourrait potentiellement aider à déterminer quels URLs visiter basé sur la requête, le titre de l'URL et l'extrait. Pour l'embedding et le reranking, la capacité multilingue est essentielle puisque les requêtes et les questions sont multilingues. La gestion du contexte long pour l'embedding et le reranking est bénéfique mais pas un blocage critique (Nous n'avons rencontré aucune erreur de notre utilisation de l'embedding, probablement parce que notre longueur de contexte est déjà de 8192 tokens). Dans tous les cas, jina-embeddings-v3 et jina-reranker-v2-base-multilingual sont mes modèles de prédilection car ils sont multilingues, SOTA et gèrent bien le contexte long.

Un framework d'agent s'est avéré inutile, car nous devions rester plus proches du comportement natif du LLM pour concevoir le système sans proxies. Vercel AI SDK a été précieux, car il a économisé un effort considérable dans l'adaptation du code base à différents fournisseurs de LLM (nous pouvions passer de Gemini Studio à OpenAI à Google Vertex AI avec juste une ligne de code changée). La gestion de la mémoire de l'agent est nécessaire, mais un framework de mémoire dédié reste questionnable : Nous craignons qu'il ne crée une couche d'isolation entre les LLM et les développeurs, et que son sucre syntaxique ne devienne éventuellement un obstacle amer pour les développeurs, comme nous l'avons vu avec de nombreux frameworks LLM/RAG aujourd'hui.