Optimale Textsegmentauswahl und URL-Umordnung in DeepSearch/DeepResearch

Wenn Sie Jina's letzten langen, klassischen Artikel "The" bereits gelesen habenEntwurf und Implementierung von DeepSearch/DeepResearch", dann lohnt es sich, ein wenig tiefer in die Details einzusteigen, die die Qualität Ihrer Antwort erheblich verbessern können. Dieses Mal werden wir uns auf zwei Details konzentrieren:

1. Extrahieren optimaler Textsegmente aus langen Web-SeitenWie man Late-Chunking-Algorithmen verwendet, um die relevantesten Informationsschnipsel aus langen Webinhalten auszuwählen.
2. Neuordnung der gesammelten URLsWie kann man Reranker verwenden, damit der LLM-Agent intelligent auswählen kann, welche URL unter Hunderten von URLs gecrawlt werden soll?

Einige von Ihnen erinnern sich vielleicht an unsere Schlussfolgerung im letzten Beitrag: "In DeepSearch eignet sich das Embeddings-Modell nur für die Abfrage-Deduplizierung für Aufgaben wie STS (Semantic Textual Similarity), und Reranker war nicht einmal in unserer ursprünglichen DeepSearch-Programmimplementierung enthalten."

Im Nachhinein betrachtet haben beide Arten von Erinnerungsmodellen immer noch ihren Wert, nur nicht in der Art und Weise, wie wir normalerweise an sie denken. Wir haben uns bei der Suche immer an das "80-20"-Prinzip gehalten und versuchen nicht, Modelle fest zu verdrahten, um für den emotionalen Wert zu sorgen oder unsere Marktpräsenz als Anbieter von Embeddings und Rerankern zu beweisen. Wir sind sehr 80-20, sehr pragmatisch.Pragmatisch bis zu dem Punkt, an dem wir uns nur um die wichtigsten Bedürfnisse des Suchsystems kümmern.

So entdeckten wir nach wochenlangem Ausprobieren und Iterieren einige unkonventionelle, aber sehr effektive Anwendungen von Embeddings und Rerankern im DeepSearch/DeepResearch-System. Durch den Einsatz dieser Methoden konnten wir die Qualität von Jina DeepSearch deutlich verbessern (Sie sind herzlich eingeladen, sie zu testen). Wir möchten diese Erfahrungen auch mit unseren Kollegen teilen, die auf diesem Gebiet zusammenarbeiten.

Auswahl optimaler Textsegmente aus einem langen Text

Das Problem ist folgendes: Mit Jina Leser Nachdem wir den Inhalt der Webseite gelesen haben, müssen wir ihn in den Kontext des Agenten als ein Stück Wissen einfügen, über das er nachdenken kann. Den gesamten Inhalt auf einen Schlag in den Kontext des LLM zu packen, wäre zwar die am wenigsten umständliche Art, dies zu tun, da der Token Aufgrund der Kosten und der Geschwindigkeit der Erstellung ist dies sicherlich nicht die beste Option. In der Praxis müssen wir die Teile des Inhalts identifizieren, die für das Problem am relevantesten sind, und nur diese Teile als Wissen zum Kontext des Agenten hinzufügen.

💡 Hier geht es um Fälle, in denen der Inhalt auch nach dem Bereinigen mit Jina Reader noch zu lang ist, um Markdown zu bereinigen. Zum Beispiel bei langen Seiten wie GitHub Issues, Reddit-Beiträgen, Forumsdiskussionen und Blogbeiträgen.

LLM-basierte Screening-Methoden haben die gleichen Kosten- und Latenzprobleme, so dass wir herausfinden müssen, ob es Lösungen mit kleinen Modellen gibt:Wir brauchen kleinere, billigere Modelle, die dennoch mehrere Sprachen unterstützen.Dies ist ein entscheidender Faktor, da es keine Garantie dafür gibt, dass Fragen oder Unterlagen immer auf Chinesisch vorliegen.

Auf der einen Seite haben wir die Frage (die ursprüngliche Anfrage oder die Frage nach "schlechten Informationen") und auf der anderen Seite haben wir eine Menge Markdown-Inhalte, von denen viele irrelevant sind. Wir müssen die relevantesten Teile für die Frage heraussuchen. Das ist so ähnlich wie RAG Das Chunking-Problem, das die Community seit 2023 zu lösen versucht, indem sie das Retriever-Modell verwendet, um nur relevante Chunks abzurufen und sie in ein Kontextfenster für die Zusammenfassung zu stellen.

In unserer Situation gibt es jedoch zwei wesentliche Unterschiede:

1. Eine endliche Anzahl von Textblöcken in einer endlichen Anzahl von Dokumenten.

Wenn man davon ausgeht, dass jeder Block etwa 500 Token enthält, hat ein typisches langes Webdokument etwa 200.000 bis 1.000.000 Token (99. Perzentil). Wir verwenden Jina Reader, um 4-5 URLs auf einmal zu crawlen, was einige hundert Textblöcke erzeugt. Das bedeutet Hunderte von Vektoren und Hunderte von Kosinus-Ähnlichkeiten. Dies lässt sich mit JavaScript leicht im Speicher verarbeiten, und eine Vektordatenbank ist nicht erforderlich.

2. Wir brauchen zusammenhängende Textblöcke, um eine effektive Zusammenfassung des Wissens zu erstellen.

Wir können Zusammenfassungen wie [1-2, 6-7, 9, 14, 17, ...] nicht akzeptieren. Zusammenfassungen, die aus verstreuten Sätzen wie diesem bestehen. Eine sinnvollere Zusammenfassung des Wissens wäre etwas wie [3-15, 17-24, ...]. was die Kohärenz des Textes besser erhalten würde. Dies würde es dem LLM erleichtern, aus Wissensquellen zu kopieren und zu zitieren, und würde auch die Anzahl der "Illusionen" reduzieren.

Der Rest sind die gleichen Vorbehalte, über die sich Entwickler beschweren: Jeder Textblock darf nicht zu lang sein, weil das Vektormodell nicht mit einem zu langen Kontext umgehen kann; Chunking führt zum Verlust von Kontext und macht die Vektoren in jedem Textblock unabhängig und identisch verteilt; und wie zum Teufel findet man die optimalen Grenzen, die sowohl die Lesbarkeit als auch die Semantik erhalten? Wenn Sie wissen, wovon wir sprechen, dann haben Sie wahrscheinlich auch mit diesen Problemen in Ihren RAG-Implementierungen zu kämpfen.

Aber lange Rede, kurzer Sinn - verwenden Sie jina-embeddings-v3 (in Form eines Nominalausdrucks) Spätes ChunkingSie löst alle drei Probleme perfekt. Die "späte Aufteilung" bewahrt die Kontextinformationen der einzelnen Blöcke, ist unempfindlich gegenüber Grenzen und jina-embeddings-v3 selbst auf dem neuesten Stand der Technik bei asymmetrischen mehrsprachigen Retrievalaufgaben. Interessierte Leser können Jina's Blogpost oder Paper verfolgen, um Details über die gesamte Implementierung zu erfahren.

🔗 https://arxiv.org/pdf/2409.04701

Flussdiagramm der Fragmentauswahl anhand von späten Bewertungen

Diese Abbildung veranschaulicht den Zusammenfassungsauswahlalgorithmus, der wie eine eindimensionale Faltung (Conv1D) funktioniert. Das Verfahren unterteilt ein langes Dokument zunächst in Abschnitte fester Länge und verwendet dann eine für die späte Partitionierung aktivierte jina-embeddings-v3 diese Textblöcke vektorisieren. Nach der Berechnung der Ähnlichkeitswerte zwischen jedem Block und der Frage wird ein gleitendes Fenster über diese Ähnlichkeitswerte bewegt, um das Fenster mit dem höchsten Durchschnitt zu finden.

Hier der schematische Code: Verwendung von Late Partitioning und Average Pooling, ähnlich der "1D-Faltung", um die für das Problem wichtigsten Passagen herauszufiltern.

function cherryPick(question, longContext, options) {
  if (longContext.length < options.snippetLength * options.numSnippets)
    return longContext;

  const chunks = splitIntoChunks(longContext, options.chunkSize);

  const chunkEmbeddings = getEmbeddings(chunks, "retrieval.passage");
  const questionEmbedding = getEmbeddings([question], "retrieval.query")[0];

  const similarities = chunkEmbeddings.map(embed =>
    cosineSimilarity(questionEmbedding, embed));

  const chunksPerSnippet = Math.ceil(options.snippetLength / options.chunkSize);
  const snippets = [];
  const similaritiesCopy = [...similarities];

  for (let i = 0; i < options.numSnippets; i++) {
    let bestStartIndex = 0;
    let bestScore = -Infinity;

    for (let j = 0; j <= similarities.length - chunksPerSnippet; j++) {
      const windowScores = similaritiesCopy.slice(j, j + chunksPerSnippet);
      const windowScore = average(windowScores);

      if (windowScore > bestScore) {
        bestScore = windowScore;
        bestStartIndex = j;
      }
    }

    const startIndex = bestStartIndex * options.chunkSize;
    const endIndex = Math.min(startIndex + options.snippetLength, longContext.length);
    snippets.push(longContext.substring(startIndex, endIndex));

    for (let k = bestStartIndex; k < bestStartIndex + chunksPerSnippet; k++)
      similaritiesCopy[k] = -Infinity;
  }

  return snippets.join("\n\n");
}

Wenn Sie die Jina Embeddings API aufrufen, denken Sie daran, die task Auf Abruf eingestellt, öffnen Sie die late_chunking(math.) Gattungtruncate Richten Sie es auch wie folgt ein:

await axios.post(
  'https://api.jina.ai/v1/embeddings',
  {
    model: "jina-embeddings-v3",
    task: "retrieval.passage",
    late_chunking: true,
    input: chunks,
    truncate: true
  },
  { headers });

Wenn das Problem vektorisiert werden soll, denken Sie daran, dass Sie task (etw.) gegen (etwas anderes) tauschen retrieval.queryDann schalten Sie es aus. late_chunking.

Der vollständige Implementierungscode ist auf GitHub zu finden:https://github.com/jina-ai/node-DeepResearch/blob/main/src/tools/jina-latechunk.ts

URL-Sortierung für nächste Lesungen

Das Problem ist folgendes: In jedem langen DeepSearch-Prozess können Sie einen Haufen URLs von der Suchmaschinen-Ergebnisseite (SERP) sammeln, und jedes Mal, wenn Sie eine Webseite öffnen, können Sie eine Menge neuer Links auf dem Weg herausfinden, selbst nach der De-Emphasis sind es immer noch leicht ein paar hundert URLs. Die LLMs mit all diesen URLs vollzustopfen, wird nicht funktionieren, es ist eine Verschwendung wertvoller kontextueller Länge, und schlimmer noch, wir haben festgestellt, dass die LLMs im Grunde nur blind auswählen. Wir mussten also einen Weg finden, den LLM zu leiten, damit er die URLs auswählt, die am ehesten die Antwort enthalten.

curl https://r.jina.ai/https://example.com \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -H "X-Retain-Images: none" \
  -H "X-Md-Link-Style: discarded" \
  -H "X-Timeout: 20" \
  -H "X-With-Links-Summary: all"

Dies ist der beste Weg, um Jina Reader für das Crawlen einer Seite in DeepSearch zu konfigurieren. Es werden alle Links auf der Seite herausgesucht, in das Links-Feld eingefügt und aus dem Inhaltsfeld gelöscht.

Man kann sich das wie einen "In-Context-PageRank" vorstellen, mit dem Unterschied, dass wir Hunderte von URLs in einer einzigen Sitzung bewerten.

Wir berücksichtigen mehrere Faktoren: Zeitpunkt der letzten Aktualisierung, Häufigkeit des Auftretens des Domänennamens, Struktur des Seitenpfads und vor allem die semantische Relevanz für die Frage, um einen zusammengesetzten Score zu berechnen. Wir können jedoch nur Informationen verwenden, die verfügbar sind, bevor wir überhaupt auf die URL klicken.

1. die FrequenzsignaleWenn eine URL mehrmals in verschiedenen Quellen erscheint, wird sie stärker gewichtet. Wenn ein Domänenname häufig in den Suchergebnissen auftaucht, erhalten URLs von dieser Domäne zusätzliche Punkte. Dies liegt daran, dass populäre Domains im Allgemeinen mehr maßgebliche Inhalte enthalten.

2. die Struktur der RouteWir analysieren die Pfadstruktur der URLs, um festzustellen, welche Inhalte in Gruppen zusammengefasst sind. Wenn mehrere URLs alle zur gleichen Pfadhierarchie gehören, erhalten sie eine höhere Punktzahl; je tiefer der Pfad jedoch ist, desto geringer wird der Punktebonus.

3. semantische Relevanz: Wir verwenden jina-reranker-v2-base-multilingual die semantische Relevanz der Frage und die Textinformationen (z. B. Titel und Zusammenfassung) jeder URL zu bewerten, was ein typisches Umordnungsproblem darstellt. Die Textinformationen für jede URL stammen von mehreren Stellen:

• Search Engine Results Page (SERP) API Gibt Titel und Zusammenfassung zurück (https://s.jina.ai/ Diese Schnittstelle mit "X-Respond-With": "no-content" gibt nur den Titel und die Zusammenfassung zurück, nicht den spezifischen Inhalt).

• Verankerungstext für URLs auf der Seite (die Verwendung der Schnittstelle https://r.jina.ai und die Einstellung "X-With-Links-Summary": "all" liefert zusammenfassende Informationen oder Verankerungstext für alle Links auf der Seite).

4. zuletzt aktualisiertEinige der DeepSearch-Abfragen haben hohe Anforderungen an die Aktualität, so dass im Allgemeinen der Wert umso höher ist, je neuer die URL ist. Ohne die umfangreichen Indexierungsmöglichkeiten von Google ist es jedoch schwierig, den Zeitpunkt der letzten Aktualisierung einer Webseite genau zu bestimmen. Wir verwenden eine Kombination aus den folgenden Signalen, um einen Zeitstempel mit einem Vertrauenswert zu erhalten, damit wir bei Bedarf vorrangig die neuesten Inhalte anzeigen können:

• Filterfunktionen, die von der SERP-API bereitgestellt werden (z. B. der tbs-Parameter von s.jina.ai, der eine Filterung nach Zeit ermöglicht).

• Analyse der HTTP-Header-Informationen (z. B. Last-Modified- und ETag-Felder).

• Extraktion von Metadaten (z. B. Meta-Tags und Schema.org-Zeitstempel).

• Content Pattern Recognition (erkennt in HTML sichtbare Daten).

• Metriken für bestimmte CMS-Plattformen (z.B. WordPress, Drupal, Ghost, etc.)

5. eingeschränkte InhalteEinige soziale Medienplattformen haben Inhalte, deren Zugang eingeschränkt oder kostenpflichtig ist. Es gibt keine Möglichkeit, legal auf diese Inhalte zuzugreifen, ohne sich anzumelden. Daher führen wir aktiv eine schwarze Liste dieser problematischen URLs und Domains, wodurch ihre Rankings gesenkt werden und die Verschwendung von Computerressourcen für diese unzugänglichen Inhalte vermieden wird.

6. die Vielfalt der DomänennamenManchmal stammen die Top-URLs alle aus derselben Domäne, was dazu führen kann, dass DeepSearch in ein "lokales Optimum" fällt, was die Qualität der Endergebnisse beeinträchtigt. Wie bereits erwähnt, stammen die Top-URLs alle von StackOverflow. Um die Vielfalt der Ergebnisse zu erhöhen, können wir eine "Explore-and-Exploit"-Strategie anwenden: Wählen Sie die Top-K-URLs aus jeder Domain aus.

Die vollständige Code-Implementierung der URL-Sortierung finden Sie auf unserem Github: https://github.com/jina-ai/node-DeepResearch/blob/main/src/utils/url-tools.ts#L192

<action-visit>
- Crawl and read full content from URLs, you can get the fulltext, last updated datetime etc of any URL.
- Must check URLs mentioned in <question> if any
- Choose and visit relevant URLs below for more knowledge. higher weight suggests more relevant:
<url-list>
  + weight: 0.20 "https://huggingface.co/docs/datasets/en/loading": "Load - Hugging FaceThis saves time because instead of waiting for the Dataset builder download to time out, Datasets will look directly in the cache. Set the environment ...Some datasets may have more than one version based on Git tags, branches, or commits. Use the revision parameter to specify the dataset version you want to load ..."
  + weight: 0.20 "https://huggingface.co/docs/datasets/en/index": "Datasets - Hugging Face🤗 Datasets is a library for easily accessing and sharing datasets for Audio, Computer Vision, and Natural Language Processing (NLP) tasks. Load a dataset in a ..."
  + weight: 0.17 "https://github.com/huggingface/datasets/issues/7175": "[FSTimeoutError] load_dataset · Issue #7175 · huggingface/datasetsWhen using load_dataset to load HuggingFaceM4/VQAv2, I am getting FSTimeoutError. Error TimeoutError: The above exception was the direct cause of the following ..."
  + weight: 0.15 "https://github.com/huggingface/datasets/issues/6465": "`load_dataset` uses out-of-date cache instead of re-downloading a ...When a dataset is updated on the hub, using load_dataset will load the locally cached dataset instead of re-downloading the updated dataset."
  + weight: 0.12 "https://stackoverflow.com/questions/76923802/hugging-face-http-request-on-data-from-parquet-format-when-the-only-way-to-get-i": "Hugging face HTTP request on data from parquet format when the ...I've had to get the data from their data viewer using the parquet option. But when I try to run it, there is some sort of HTTP error. I've tried downloading ..."
</url-list>
</action-visit>

Zusammenfassungen

Seit der Veröffentlichung von Jina's DeepSearch am 2. Februar 2025 wurden zwei technische Details entdeckt, die die Qualität drastisch verbessern können.Interessanterweise nutzen beide Details mehrsprachige Embedding- und Rerankermodelle in einer Art "In-Context-Fenster".Das ist nichts im Vergleich zu den umfangreichen vorberechneten Indizes, die diese Modelle in der Regel erfordern.

Dies könnte ein Hinweis darauf sein, dass sich die Zukunft der Suchtechnologie in eine polarisierte Richtung bewegen wird. Wir können Kahnemans Theorie der dualen Prozesse heranziehen, um diesen Trend zu verstehen:

• Denken Sie schnell. Schnelles Denken (grep, BM25, SQL): schneller, regelbasierter Mustervergleich mit minimalem Rechenaufwand.

• langsam denken Langsam-Denken (LLM): umfassende Schlussfolgerungen mit tiefem kontextuellem Verständnis, aber rechenintensiv.

• mittelBand Mittendrin denken (Embedding, Reranker et al. Recall Model): Verfügt über ein gewisses semantisches Verständnis, besser als einfacher Mustervergleich, aber weit weniger Inferenz als LLM.

Eine Möglichkeit ist:Zweistufige Sucharchitekturen werden immer beliebterDie leichtgewichtige, effiziente SQL/BM25 kümmert sich um die Eingabe des Abrufs und leitet die Ergebnisse dann direkt an den LLM für den Abruf der Ausgabe weiter. Der Restwert des Middle-Tier-Modells wird dann auf Aufgaben innerhalb eines bestimmten Kontextfensters verlagert: z. B. Filtern, Entdoppeln, Sortieren usw. In diesen Szenarien wäre es ineffizient, das komplette Reasoning stattdessen mit LLM durchzuführen.

Aber egal.Auswahl der wichtigsten Clips im Gesang antworten URL-Sortierung Nach wie vor ist es der grundlegende Aspekt, der die Qualität eines DeepSearch/DeepResearch-Systems direkt beeinflusst. Wir hoffen, dass unsere Erkenntnisse Ihnen helfen werden, Ihr eigenes System zu verbessern.

Die Erweiterung der Abfrage ist ein weiterer wichtiger Faktor bei der Bestimmung der Qualität.Gemüse.Wir evaluieren derzeit eine Vielzahl von Ansätzen, die von einfachen, auf Aufforderungen basierenden Umschreibungen über kleine Modelle bis hin zu inferenzbasierten Ansätzen reichen. Seien Sie gespannt auf unsere weiteren Forschungsergebnisse in dieser Richtung!