Ein praktischer Leitfaden zur Implementierung von DeepSearch/DeepResearch

Jina AI Deep Search

KI-Tiefensuche: Lesen, Verstehen, Suchen bis die beste Antwort gefunden ist.

Es ist erst Februar, und DeepSearch hat sich bereits als neuer Suchstandard für 2025 etabliert, wobei große Player wie Google und OpenAI durch ihre DeepResearch-Veröffentlichungen die Führung übernehmen (und ja, wir haben stolz am selben Tag unser Open-Source node-deepresearch veröffentlicht). Perplexity folgte mit ihrem DeepResearch, und X AI integrierte ihre eigenen DeepSearch-Fähigkeiten in Grok3, was im Grunde eine weitere DeepResearch-Variante darstellt. Während das Konzept der Tiefensuche nicht revolutionär ist – 2024 wurde es im Wesentlichen als RAG oder Multi-Hop QA bezeichnet – gewann es nach der Veröffentlichung von Deepseek-r1 Ende Januar 2025 erheblich an Dynamik. Letztes Wochenende haben Baidu Search und Tencent WeChat Search Deepseek-r1 in ihre Suchmaschinen integriert. KI-Ingenieure haben entdeckt, dass sie durch die Integration von langen Denk- und Argumentationsprozessen in Suchsysteme eine bemerkenswerte Abrufgenauigkeit und -tiefe erreichen können, die über das bisher Mögliche hinausgeht.

Aber warum geschah dieser Wandel gerade jetzt, wo Deep(Re)Search das ganze Jahr 2024 über relativ unterschätzt blieb? Tatsächlich hatte Stanford NLP Labs das STORM-Projekt für die Generierung langer Berichte mit Web-Grundlage bereits Anfang 2024 veröffentlicht. Liegt es also nur daran, dass "DeepSearch" viel cooler klingt als Multi-Hop QA, RAG oder STORM? Seien wir ehrlich - manchmal braucht es nur ein Rebranding, damit die Branche plötzlich das annimmt, was schon die ganze Zeit da war.

Wir glauben, der eigentliche Wendepunkt kam mit OpenAIs o1-preview-Release im September 2024, der das Konzept des Test-Time Compute einführte und allmählich die Perspektiven der Branche veränderte. Test-Time Compute bezieht sich auf die Nutzung von mehr Rechenressourcen während der Inferenz – der Phase, in der ein LLM Outputs generiert – anstatt während des Pre-Trainings oder Post-Trainings. Bekannte Beispiele sind Chain-of-Thought (CoT) Reasoning und "Wait"-Injection (d.h. Budget Forcing), die es Modellen ermöglichen, umfangreichere interne Überlegungen anzustellen, wie die Bewertung mehrerer potenzieller Antworten, tiefere Planung und Selbstreflexion, bevor sie zu einer endgültigen Antwort kommen.

Dieses Test-Time Compute-Konzept und Reasoning-Modelle erziehen Nutzer dazu, aufgeschobene Befriedigung zu akzeptieren - längere Wartezeiten im Austausch für qualitativ hochwertigere, sofort umsetzbare Ergebnisse, ähnlich wie beim Stanford-Marshmallow-Experiment, bei dem Kinder, die der Versuchung widerstehen konnten, ein Marshmallow sofort zu essen, um später zwei zu bekommen, bessere langfristige Ergebnisse zeigten. Deepseek-r1 verstärkte diese Benutzererfahrung weiter, und ob man es mag oder nicht, die meisten Nutzer haben es akzeptiert.

Dies markiert eine bedeutende Abkehr von klassischen Suchanforderungen, wo eine Antwortzeit von mehr als 200ms das Aus für Ihre Lösung bedeutet hätte. Im Jahr 2025 priorisieren erfahrene Suchentwickler und RAG-Ingenieure Top-1-Präzision und Recall über Latenz, und Benutzer haben sich an längere Verarbeitungszeiten gewöhnt – vorausgesetzt, sie können sehen, dass das System <thinking> ist.

In diesem Artikel werden wir die Prinzipien von DeepSearch und DeepResearch anhand unserer Open-Source-Implementierung diskutieren. Wir werden unsere wichtigsten Designentscheidungen durchgehen und mögliche Fallstricke aufzeigen.

tagWas ist Deep Search?

DeepSearch durchläuft eine iterative Schleife aus Suchen, Lesen und Schlussfolgern, bis die optimale Antwort gefunden wird. Die Suchaktion nutzt Websuchmaschinen zur Erkundung des Internets, während die Leseaktion spezifische Webseiten im Detail analysiert (z.B. Jina Reader). Die Schlussfolgerungsaktion bewertet den aktuellen Stand und entscheidet, ob die ursprüngliche Frage in kleinere Teilfragen zerlegt werden soll oder verschiedene Suchstrategien ausprobiert werden sollen.

Während online verschiedene Definitionen existieren, hielten wir uns bei der Entwicklung des node-deepresearch Projekts an diesen unkomplizierten Ansatz. Die Implementierung ist elegant einfach – im Kern gibt es eine Hauptschleife mit Switch-Case-Logik, die die nächste Aktion steuert.

Anders als RAG-Systeme von 2024, die typischerweise einen einzigen Such-Generierungs-Durchlauf ausführen, führt DeepSearch mehrere Iterationen durch die Pipeline durch und benötigt klare Stoppbedingungen. Diese können auf Token-Nutzungslimits oder der Anzahl fehlgeschlagener Versuche basieren.

Eine andere Perspektive auf DeepSearch ist, es als einen LLM-Agenten mit verschiedenen Web-Tools (wie Searcher und Reader) zu betrachten. Der Agent bestimmt seine nächsten Schritte durch die Analyse aktueller Beobachtungen und vergangener Aktionen – er entscheidet, ob er eine Antwort liefern oder weiter im Web forschen soll. Dies erzeugt eine Zustandsmaschinen-Architektur, bei der das LLM die Übergänge zwischen den Zuständen steuert. An jedem Entscheidungspunkt haben Sie zwei Ansätze: Sie können entweder sorgfältig Prompts für Standard-Generative-Modelle erstellen, um spezifische Aktionen zu erzeugen, oder spezialisierte Reasoning-Modelle wie Deepseek-r1 nutzen, um die nächsten Aktionen natürlich abzuleiten. Allerdings müssen Sie auch bei der Verwendung von r1 periodisch die Generierung unterbrechen, um Tool-Outputs (z.B. Suchergebnisse, Webseiteninhalt) in den Kontext einzufügen und es aufzufordern, seinen Denkprozess fortzusetzen.

Letztendlich sind dies nur Implementierungsdetails – ob Sie es sorgfältig promten oder einfach Reasoning-Modelle verwenden, sie alle entsprechen dem Kerndesignprinzip von DeepSearch: eine kontinuierliche Schleife aus Suchen, Lesen und Schlussfolgern.

tagWas ist dann DeepResearch?

DeepResearch baut auf DeepSearch auf, indem es ein strukturiertes Framework für die Erstellung langer Forschungsberichte hinzufügt. Es beginnt oft mit der Erstellung eines Inhaltsverzeichnisses und wendet dann systematisch DeepSearch auf jeden erforderlichen Abschnitt an – von der Einleitung über verwandte Arbeiten und Methodik bis hin zur Schlussfolgerung. Jeder Abschnitt wird durch die Eingabe spezifischer Forschungsfragen in DeepSearch generiert. Die letzte Phase beinhaltet die Konsolidierung aller Abschnitte in einen einzigen Prompt, um die narrative Kohärenz insgesamt zu verbessern.

In unserem Projekt „Research" von 2024 führten wir mehrere Kohärenzverbesserungsdurchläufe durch, wobei jede Iteration alle anderen Abschnitte berücksichtigte. Mit den heute deutlich größeren LLM-Kontextfenstern scheint dieser Ansatz jedoch redundant – ein einzelner Kohärenzüberarbeitungsdurchlauf ist ausreichend.

tagDeepSearch vs DeepResearch

Während viele Menschen DeepSearch und DeepResearch oft miteinander vermischen, adressieren sie aus unserer Sicht vollkommen unterschiedliche Probleme. DeepSearch fungiert als atomarer Baustein – eine Kernkomponente, auf der DeepResearch aufbaut. DeepResearch hingegen konzentriert sich darauf, hochwertige, lesbare Langform-Forschungsberichte zu erstellen, was ein anderes Set von Anforderungen umfasst: Integration effektiver Visualisierungen durch Diagramme und Tabellen, Strukturierung von Inhalten mit passenden Überschriften, Sicherstellung eines flüssigen logischen Flusses zwischen Unterabschnitten, Beibehaltung einer konsistenten Terminologie im gesamten Dokument, Beseitigung von Redundanzen zwischen Abschnitten, Gestaltung flüssiger Übergänge, die vorherige und kommende Inhalte verbinden. Diese Elemente haben weitgehend nichts mit der Kernsuche zu tun, weshalb wir DeepSearch als unseren Unternehmensfokus interessanter finden.

Abschließend fasst die folgende Tabelle die Unterschiede zwischen DeepSearch und DeepResearch zusammen. Erwähnenswert ist, dass beide Systeme erheblich von Long-Context- und Reasoning-Modellen profitieren. Dies mag kontraintuitiv erscheinen, besonders für DeepSearch – während es offensichtlich ist, warum DeepResearch Long-Context-Fähigkeiten benötigt (da es lange Berichte produziert). Der Grund ist, dass DeepSearch vorherige Suchversuche und Webseiteninhalte speichern muss, um fundierte Entscheidungen über nächste Schritte zu treffen, wodurch ein langes Kontextfenster für seine effektive Implementierung gleichermaßen essentiell ist.

tagDeepSearch-Implementierung verstehen

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

Der Kern von DeepResearch liegt in seinem Loop-Reasoning-Ansatz. Anstatt zu versuchen, Fragen in einem einzigen Durchgang wie die meisten RAG-Systeme zu beantworten, haben wir eine iterative Schleife implementiert, die kontinuierlich nach Informationen sucht, relevante Quellen liest und Schlüsse zieht, bis sie eine Antwort findet oder das Token-Budget erschöpft ist. Hier ist der vereinfachte Kern dieser großen While-Schleife:

// 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
}
Kopieren

Ein wichtiges Implementierungsdetail ist das selektive Deaktivieren bestimmter Aktionen in jedem Schritt, um eine stabilere strukturierte Ausgabe zu gewährleisten. Wenn zum Beispiel keine URLs im Speicher vorhanden sind, deaktivieren wir die visit-Aktion, oder wenn die letzte Antwort abgelehnt wurde, verhindern wir, dass der Agent sofort wieder answer aufruft. Diese Einschränkung hält den Agenten auf einem produktiven Pfad und vermeidet wiederholte Fehler durch das Aufrufen derselben Aktion.

tagSystem Prompt

Wir verwenden XML-Tags zur Definition von Abschnitten, was zu robusteren System Prompts und Generierungen führt. Wir haben auch festgestellt, dass das Platzieren von Feldbeschränkungen direkt in JSON-Schema description-Feldern bessere Ergebnisse liefert. Während einige argumentieren könnten, dass die meisten Prompts mit Reasoning-Modellen wie DeepSeek-R1 automatisiert werden könnten, machen die Kontextlängenbeschränkungen und die Notwendigkeit für hochspezifisches Verhalten einen expliziten Ansatz in der Praxis zuverlässiger.

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");
}
Kopieren

tagDurchlaufen von Lückenfragen

In DeepSearch repräsentieren "Lückenfragen" Wissenslücken, die gefüllt werden müssen, bevor die Hauptfrage beantwortet werden kann. Anstatt die ursprüngliche Frage direkt anzugehen, identifiziert der Agent Unterfragen, die das notwendige Wissensfundament aufbauen werden.

Das Design ist besonders elegant in der Art und Weise, wie es diese Lückenfragen handhabt:

// 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);
}
Kopieren

Dieser Ansatz erzeugt eine FIFO (First-In-First-Out) Warteschlange mit Rotation, wobei:

1. Neue Lückenfragen werden vorne in die Warteschlange geschoben
2. Die ursprüngliche Frage wird immer ans Ende geschoben
3. Das System nimmt in jedem Schritt von vorne aus der Warteschlange

Was dieses Design großartig macht, ist, dass es einen einzelnen gemeinsamen Kontext über alle Fragen hinweg beibehält. Wenn eine Lückenfrage beantwortet wird, steht dieses Wissen sofort für alle nachfolgenden Fragen zur Verfügung, einschließlich wenn wir schließlich zur ursprünglichen Frage zurückkehren.

FIFO-Warteschlange vs. Rekursion

Ein alternativer Ansatz ist die Verwendung von Rekursion, die einer Tiefensuche entspricht. Jede Lückenfrage erzeugt einen neuen rekursiven Aufruf mit eigenem isolierten Kontext. Das System muss jede Lückenfrage (und alle ihre potenziellen Unterfragen) vollständig lösen, bevor es zur übergeordneten Frage zurückkehrt.

Betrachten Sie dieses Beispielszenario:

Im rekursiven Ansatz müsste das System Q1 nach jeder Lückenfrage und deren Unterfragen vollständig lösen (und möglicherweise eigene Unterfragen generieren)! Dies steht im starken Kontrast zum Warteschlangen-Ansatz, bei dem Q1 direkt nach 3 Lückenfragen wieder aufgegriffen wird.

In der Realität stellten wir fest, dass der Rekursionsansatz sehr schwer mit Budget-Begrenzungen zu vereinbaren ist, da es keine klare Faustregel gibt, wie viel Token-Budget wir für Unterfragen gewähren sollten (da sie neue Unterfragen erzeugen können). Der Nutzen aus der klaren Kontexttrennung im Rekursionsansatz ist sehr gering im Vergleich zu den komplizierten Budget-Erzwingungs- und späten Rückkehr-Problemen. Dieses FIFO-Warteschlangen-Design balanciert Tiefe und Breite und stellt sicher, dass das System immer mit progressiv besserem Wissen zur ursprünglichen Frage zurückkehrt, anstatt sich in einem potentiell unendlichen rekursiven Abstieg zu verlieren.

tagQuery-Umschreibung

Eine interessante Herausforderung, auf die wir stießen, war das effektive Umschreiben von Suchanfragen:

// 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);
    }
  }
}
Kopieren

Die Query-Umschreibung erwies sich als überraschend wichtig - vielleicht eines der kritischsten Elemente, das direkt die Ergebnisqualität bestimmt. Ein guter Query-Umschreiber transformiert nicht nur natürliche Sprache in BM25-ähnliche Keywords; er erweitert Anfragen, um mehr potenzielle Antworten über verschiedene Sprachen, Töne und Inhaltsformate hinweg abzudecken.

Für die Query-Deduplizierung verwendeten wir zunächst eine LLM-basierte Lösung, fanden es aber schwierig, den Ähnlichkeitsschwellenwert zu kontrollieren. Wir wechselten schließlich zu jina-embeddings-v3, das sich bei semantischen Textähnlichkeitsaufgaben auszeichnet. Dies ermöglicht sprachübergreifende Deduplizierung, ohne sich Sorgen machen zu müssen, dass nicht-englische Anfragen gefiltert würden. Das Embedding-Modell erwies sich letztendlich als entscheidend, nicht für den Memory-Retrieval wie ursprünglich erwartet, sondern für effiziente Deduplizierung.

tagCrawling von Web-Inhalten

Web Scraping und Content-Verarbeitung ist eine weitere wichtige Komponente. Hier verwenden wir die Jina Reader API. Beachten Sie, dass wir neben dem vollständigen Webseiteninhalt auch alle von der Suchmaschine zurückgegebenen Snippets als zusätzliches Wissen für den Agenten sammeln, um später Schlüsse daraus zu ziehen. Denken Sie an sie wie 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);
}
Kopieren

Wir haben URLs für ein konsistentes Tracking normalisiert und die Anzahl der besuchten URLs in jedem Schritt begrenzt, um den Agenten-Speicher zu verwalten.

tagSpeicherverwaltung

Eine zentrale Herausforderung beim mehrstufigen Reasoning ist die effektive Verwaltung des Agenten-Speichers. Wir haben das Speichersystem so konzipiert, dass es zwischen "Gedächtnis" und "Wissen" unterscheidet. In beiden Fällen sind sie Teil des LLM Prompt-Kontexts, getrennt durch verschiedene XML-Tags:

// 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]
`);
}
Kopieren

Da die meisten LLMs im Jahr 2025 über erhebliche Kontextfenster verfügen, haben wir uns gegen die Verwendung von Vektordatenbanken entschieden. Stattdessen besteht der Speicher aus erworbenem Wissen, besuchten Websites und Aufzeichnungen gescheiterter Versuche - alles im Kontext gehalten. Dieses umfassende Speichersystem gibt dem Agenten ein Bewusstsein dafür, was er weiß, was er versucht hat und was funktioniert hat oder gescheitert ist.

tagAntwortbewertung

Eine wichtige Erkenntnis ist, dass Antwortgenerierung und -bewertung nicht im selben Prompt erfolgen sollten. In meiner Implementierung bestimmen wir zunächst die Bewertungskriterien, wenn eine neue Frage eingeht, und bewerten dann jedes Kriterium einzeln. Der Evaluator verwendet Few-Shot-Beispiele für eine konsistente Bewertung, die zuverlässiger ist als eine Selbstbewertung.

// 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')
  };
}
Kopieren

tagBudget-Forcing

Budget Forcing bedeutet, das System daran zu hindern, vorzeitig zurückzukehren, und sicherzustellen, dass es die Verarbeitung fortsetzt, bis das Budget überschritten ist. Seit der Veröffentlichung von DeepSeek-R1 hat sich der Ansatz des Budget Forcing dahingehend verändert, dass tieferes Nachdenken für bessere Ergebnisse gefördert wird, anstatt einfach nur das Budget zu sparen.

In unserer Implementierung haben wir das System explizit so konfiguriert, dass es Wissenslücken identifiziert, bevor es versucht zu antworten.

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
}
Kopieren

Durch selektives Aktivieren und Deaktivieren bestimmter Aktionen können wir das System zur Verwendung von Tools lenken, die die Reasoning-Tiefe verbessern.

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

Um keine Token für unproduktive Pfade zu verschwenden, setzen wir Grenzen für die Anzahl fehlgeschlagener Versuche. Wenn wir uns den Budgetgrenzen nähern, aktivieren wir den "Beast Mode", um zu garantieren, dass wir eine Antwort liefern anstatt gar keine.

// 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;
}
Kopieren

Der Beast Mode Prompt ist absichtlich dramatisch formuliert, um dem LLM zu signalisieren, dass es entscheidungsfreudig sein und sich basierend auf den verfügbaren Informationen zu einer Antwort bekennen muss:

<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>
Kopieren

Dies stellt sicher, dass wir immer eine Antwort liefern, anstatt ganz aufzugeben, was besonders bei schwierigen oder mehrdeutigen Fragen nützlich ist.

tagFazit

DeepSearch ist ein Sprung in der Art und Weise, wie Suche komplexe Anfragen erschöpfend tief angehen kann. Durch die Aufgliederung des Prozesses in diskrete Schritte des Suchens, Lesens und Schlussfolgerns überwindet es viele Einschränkungen traditioneller Single-Pass RAG oder Multi-Hop QA Systeme.

Während der Implementierung begannen wir auch, die Suchgrundlagen im Jahr 2025 und die Veränderungen in der Suchindustrie nach dem 26. Januar 2025, als DeepSeek-R1 veröffentlicht wurde, zu überprüfen. Wir fragten uns: Was sind die neuen Bedürfnisse? Welche Bedürfnisse sind obsolet geworden? Was sind nur wahrgenommene Bedürfnisse?

Bei der Betrachtung unserer DeepSearch-Implementierung identifizierten wir Dinge, von denen wir dachten, dass wir sie brauchen würden und tatsächlich brauchten, Dinge, von denen wir dachten, sie wären notwendig, aber nicht waren, und Dinge, die wir nicht erwartet hatten zu brauchen, die sich aber als essentiell herausstellten:

Erstens ist ein LLM mit langem Kontext, das gut strukturierte Ausgaben produziert, sehr notwendig (d.h. nach JSONSchema). Ein Reasoning-Modell wird wahrscheinlich für besseres Action Reasoning und Query Expansion benötigt.

Query Expansion ist definitiv essentiell, egal ob über SLM, LLM oder ein Reasoning-Modell implementiert. Nach diesem Projekt glauben wir jedoch, dass SLMs für diese Aufgabe wahrscheinlich ungeeignet sind, da die Lösung von Natur aus mehrsprachig sein muss und über einfache Synonym-Umschreibungen oder Keyword-Extraktion hinausgehen muss. Sie muss umfassend genug sein, um eine mehrsprachige Token-Basis (kann leicht 300M Parameter belegen) einzuschließen und ausgeklügelt genug für Out-of-the-Box-Denken. Die Verwendung von SLMs für Query Expansion ist daher wahrscheinlich keine Option.

Websuche und Web-Reading-Fähigkeiten sind entscheidend, und glücklicherweise hat sich unser Reader (r.jina.ai) hervorragend bewährt - robust und skalierbar - während er mir viele Ideen gab, wie wir unseren Suchendpunkt (s.jina.ai) für die nächste Iteration verbessern können.

Das Embedding-Modell ist nützlich, aber auf eine völlig unerwartete Weise. Wir dachten, es würde für Memory Retrieval oder Kontextkompression zusammen mit einer Vektordatenbank verwendet werden (die sich als nicht notwendig herausstellte), aber tatsächlich haben wir es für Deduplizierung verwendet (im Wesentlichen eine STS-Aufgabe). Da die Anzahl der Queries und Gap-Fragen typischerweise in den Hunderten liegt, ist keine Vektordatenbank erforderlich - die Berechnung der Kosinus-Ähnlichkeit direkt im Speicher funktioniert einwandfrei.

Wir haben keinen Reranker verwendet, obwohl wir glauben, dass er möglicherweise dabei helfen könnte zu bestimmen, welche URLs basierend auf der Query, dem URL-Titel und dem Snippet besucht werden sollen. Sowohl für Embedding als auch für Reranking ist Mehrsprachigkeit essentiell, da Queries und Fragen mehrsprachig sind. Die Verarbeitung langer Kontexte für Embedding und Reranking ist vorteilhaft, aber kein kritischer Blocker (Wir sind auf keine Fehler bei unserer Embedding-Nutzung gestoßen, wahrscheinlich weil unsere Kontextlänge bereits 8192 Token beträgt). In jedem Fall sind jina-embeddings-v3 und jina-reranker-v2-base-multilingual meine bevorzugten Modelle, da sie mehrsprachig sind, SOTA sind und lange Kontexte gut verarbeiten.

Ein Agent-Framework erwies sich als unnötig, da wir näher am nativen LLM-Verhalten bleiben mussten, um das System ohne Proxies zu gestalten. Das Vercel AI SDK war wertvoll, da es erheblichen Aufwand bei der Anpassung des Codebases an verschiedene LLM-Provider sparte (wir konnten mit nur einer Codezeilen-Änderung von Gemini Studio zu OpenAI zu Google Vertex AI wechseln). Agent Memory Management ist notwendig, aber ein dediziertes Memory Framework bleibt fraglich: Wir befürchten, dass es eine Isolationsschicht zwischen LLMs und Entwicklern schaffen würde und dass seine syntaktische Vereinfachung schließlich zu einem bitteren Hindernis für Entwickler werden könnte, wie wir es bei vielen LLM/RAG-Frameworks heute sehen.