Indizierung von Markdown-Blobs und Dateien in Azure KI-Suche

Hinweis

Azure KI-Suche ist über das Azure Portal, REST-APIs und Azure SDKs verfügbar. Es unterstützt auch Foundry IQ, die verwaltete Wissensschicht, die Unternehmensinhalte in wiederverwendbare, berechtigungsfähige Wissensbasen für Agenten im Microsoft Foundry-Portal transformiert.

Important

Diese Features und Funktionen unterstützen Verbindungen mit anderen Microsoft-Dienste und Drittanbieterdiensten. Die Nutzung dieser Dienste unterliegt den jeweiligen Bestimmungen und kann dazu führen, dass Daten außerhalb der Azure-Compliancegrenze verarbeitet oder gespeichert werden und dass Daten in die Azure-Compliancegrenze fließen.

Es liegt in Ihrer Verantwortung, zu verwalten, ob Ihre Daten außerhalb der Compliance- und geografischen Grenzen Ihrer Organisation und alle damit verbundenen Auswirkungen fließen und dass entsprechende Berechtigungen, Grenzen und Genehmigungen bereitgestellt werden.

Sie sind dafür verantwortlich, Anwendungen, die Sie im Kontext Ihrer spezifischen Anwendungsfälle erstellen, sorgfältig zu überprüfen und zu testen und alle geeigneten Entscheidungen und Anpassungen zu treffen. Dazu gehört die Implementierung ihrer eigenen verantwortungsvollen KI-Entschärfungen, wie Metaprompts, Inhaltsfilter oder andere Sicherheitssysteme, und sicherzustellen, dass Ihre Anwendungen angemessene Qualität, Zuverlässigkeit, Sicherheit und Vertrauenswürdigkeitsstandards erfüllen. Weitere Informationen finden Sie im Azure KI-Suche Transparenzhinweis.

In Azure KI-Suche unterstützen Indexer für Azure Blob Storage, Azure Files und Microsoft OneLake einen markdown Analysemodus für Markdown-Dateien. Markdowndateien können auf zwei Arten indiziert werden:

  • Eins-zu-viele-Parsing-Modus, der mehrere Suchdokumente pro Markdown-Datei erzeugt.
  • 1:1-Analysemodus, der ein Suchdokument pro Markdown-Datei erstellt.

Tipp

Nachdem Sie diesen Artikel überprüft haben, fahren Sie mit Tutorial fort: Durchsuchen von Markdown-Daten aus Azure Blob Storage.

Voraussetzungen

  • Eine unterstützte Datenquelle: Azure Blob Storage, Azure Dateispeicher, Microsoft OneLake.

    Stellen Sie für OneLake sicher, dass Sie alle Anforderungen des OneLake-Indexers erfüllen.

    Azure Storage für blob-Indexer und file-Indexer ist eine Standardleistungsinstanz (allgemeiner Zweck v2), die Hot- und Cool-Zugriffsebenen unterstützt.

Parameter für den Markdown-Analysemodus

Parameter für den Analysemodus werden in einer Indexerdefinition angegeben, wenn Sie einen Indexer erstellen oder aktualisieren.

POST https://[service name].search.windows.net/indexers?api-version=2026-04-01
Content-Type: application/json
api-key: [admin key]

{
  "name": "my-markdown-indexer",
  "dataSourceName": "my-blob-datasource",
  "targetIndexName": "my-target-index",
  "parameters": {
    "configuration": {
      "parsingMode": "markdown",
      "markdownParsingSubmode": "oneToMany",
      "markdownHeaderDepth": "h6"
    }
  },
}

Der BLOB-Indexer stellt einen submode Parameter bereit, um die Ausgabestruktur der Suchdokumente zu bestimmen. Der Markdown-Analysemodus bietet die folgenden Untermodusoptionen:

Parsersmodus Untermodus Dokument durchsuchen Beschreibung
markdown oneToMany Mehrere pro Blob (Standard) Unterteilt das Markdown in mehrere Suchdokumente, die jeweils einen Inhaltsabschnitt (Nichtheader) der Markdown-Datei darstellen. Sie können den Untermodus weglassen, es sei denn, Sie möchten eine 1:1-Analyse ausführen.
markdown oneToOne Eins pro Blob Analysiert das Markdown in ein Suchdokument, wobei Abschnitte bestimmten Kopfzeilen in der Markdown-Datei zugeordnet sind.

Für den oneToMany Untermodus sollten Sie den Abschnitt Indizieren eines Blobs, um viele Suchdokumente zu erzeugen durchsehen, um zu verstehen, wie der Blob-Indexer die Uneindeutigkeit des Dokumentschlüssels für mehrere aus demselben Blob erstellte Suchdokumente behandelt.

In späteren Abschnitten werden die einzelnen Untermodi ausführlicher beschrieben. Wenn Sie mit Indexerclients und Konzepten nicht vertraut sind, lesen Sie " Erstellen eines Suchindexers". Sie sollten auch mit den Details der grundlegenden Blobindexerkonfiguration vertraut sein, die hier nicht wiederholt wird.

Optionale Markdown-Analyseparameter

Bei Parametern wird zwischen Groß- und Kleinschreibung unterschieden.

Parametername Zulässige Werte Beschreibung
markdownHeaderDepth h1, h2, h3, h4, , h5, h6 (default) Dieser Parameter bestimmt die tiefste Kopfzeilenebene, die beim Analysieren berücksichtigt wird, was eine flexible Behandlung der Dokumentstruktur ermöglicht (z. B. bei markdownHeaderDepth Festlegung auf h1), erkennt der Parser nur Kopfzeilen der obersten Ebene, die mit "#" beginnen, und alle Kopfzeilen der unteren Ebene werden als Nur-Text behandelt. Standardmäßig wird auf h6 zurückgegriffen, wenn es nicht angegeben ist.

Diese Einstellung kann geändert werden, nachdem der Indexer erstellt wurde. Die Struktur der resultierenden Suchdokumente kann sich jedoch je nach Markdown-Inhalt ändern.

Unterstützte Markdown-Elemente

Durch die Markdownanalyse werden nur Inhalte basierend auf Kopfzeilen geteilt. Alle anderen Elemente, z. B. Listen, Codeblöcke und Tabellen, werden als Nur-Text behandelt und in ein Inhaltsfeld übergeben.

Beispiel für Markdown-Inhalte

Der folgende Markdown-Inhalt wird für die Beispiele auf dieser Seite verwendet:

# Section 1
Content for section 1.

## Subsection 1.1
Content for subsection 1.1.

# Section 2
Content for section 2.

Verwenden Sie den Eins-zu-Viele-Analysemodus

Der 1:n-Analysemodus parst Markdowndateien in mehrere Suchdokumente, wobei jedes Dokument einem bestimmten Inhaltsabschnitt der Markdowndatei entspricht, basierend auf den Headermetadaten an diesem Punkt im Dokument. Der Markdown wird basierend auf Kopfzeilen in Suchdokumente analysiert, die den folgenden Inhalt enthalten:

  • content: Eine Zeichenfolge, die den unformatierten Markdown enthält, der an einer bestimmten Stelle gefunden wurde, basierend auf den Headermetadaten an diesem Punkt im Dokument.

  • sections: Ein Objekt, das Unterfelder für die Headermetadaten bis zur gewünschten Kopfzeilenebene enthält. Wenn beispielsweise markdownHeaderDepth auf h3 gesetzt ist, enthält es die Zeichenfolgenfelder h1, h2 und h3. Diese Felder werden durch Spiegelung dieser Struktur im Index oder durch Feldzuordnungen im Format /sections/h1, /sections/h2usw. indiziert. In den folgenden Beispielen finden Sie die Index- und Indexerkonfigurationen für Kontextbeispiele. Die enthaltenen Unterfelder sind:

    • h1 - Eine Zeichenfolge, die den h1-Headerwert enthält. Leere Zeichenfolge, wenn sie an diesem Punkt im Dokument nicht festgelegt ist.
    • (Optional) h2- Eine Zeichenfolge, die den h2-Headerwert enthält. Leere Zeichenfolge, wenn sie an diesem Punkt im Dokument nicht festgelegt ist.
    • (Optional) h3- Eine Zeichenfolge, die den h3-Headerwert enthält. Leere Zeichenfolge, wenn sie an diesem Punkt im Dokument nicht festgelegt ist.
    • (Optional) h4- Eine Zeichenfolge, die den h4-Headerwert enthält. Leere Zeichenfolge, wenn sie an diesem Punkt im Dokument nicht festgelegt ist.
    • (Optional) h5- Eine Zeichenfolge, die den h5-Headerwert enthält. Leere Zeichenfolge, wenn sie an diesem Punkt im Dokument nicht festgelegt ist.
    • (Optional) h6- Eine Zeichenfolge, die den h6-Headerwert enthält. Leere Zeichenfolge, wenn sie an diesem Punkt im Dokument nicht festgelegt ist.

  • ordinal_position: Ein ganzzahliger Wert, der die Position des Abschnitts innerhalb der Dokumenthierarchie angibt. Dieses Feld wird verwendet, um die Abschnitte in ihrer ursprünglichen Reihenfolge so zu ordnen, wie sie im Dokument angezeigt werden. Beginnend mit einer Ordnungsposition von 1, erhöht sich die Position aufeinanderfolgend für jede Überschrift.

Indexschema für das Eins-zu-viele-Parsing

Eine Beispielindexkonfiguration könnte etwa wie folgt aussehen:

{
  "name": "my-markdown-index",
  "fields": [
  {
    "name": "id",
    "type": "Edm.String",
    "key": true
  },
  {
    "name": "content",
    "type": "Edm.String",
  },
  {
    "name": "ordinal_position",
    "type": "Edm.Int32"
  },
  {
    "name": "sections",
    "type": "Edm.ComplexType",
    "fields": [
    {
      "name": "h1",
      "type": "Edm.String"
    },
    {
      "name": "h2",
      "type": "Edm.String"
    }]
  }]
}

Indexerdefinition für die Eins-zu-Viele-Analyse

Wenn Feldnamen und Datentypen übereinstimmen, kann der Blob-Indexer die Zuordnung ohne eine explizite Feldzuordnung im Antrag ableiten. Eine Indexerkonfiguration, die der gegebenen Indexkonfiguration entspricht, könnte folgendermaßen aussehen:

POST https://[service name].search.windows.net/indexers?api-version=2026-04-01
Content-Type: application/json
api-key: [admin key]

{
  "name": "my-markdown-indexer",
  "dataSourceName": "my-blob-datasource",
  "targetIndexName": "my-target-index",
  "parameters": {
    "configuration": { "parsingMode": "markdown" }
  },
}

Hinweis

Dies submode muss hier nicht explizit festgelegt werden, da oneToMany die Standardeinstellung ist.

Indexer-Ausgabe für das eins-zu-viele-Parsen

Diese Markdown-Datei würde aufgrund der drei Inhaltsabschnitte drei Suchdokumente nach der Indizierung ergeben. Das Suchdokument, das sich aus dem ersten Inhaltsabschnitt des bereitgestellten Markdown-Dokuments ergibt, enthält die folgenden Werte für content, sections, , h1und h2:

{
  {
    "content": "Content for section 1.\r\n",
    "sections": {
      "h1": "Section 1",
      "h2": ""
    },
    "ordinal_position": 1
  },
  {
    "content": "Content for subsection 1.1.\r\n",
    "sections": {
      "h1": "Section 1",
      "h2": "Subsection 1.1"
    },
    "ordinal_position": 2
  },
  {
    "content": "Content for section 2.\r\n",
    "sections": {
      "h1": "Section 2",
      "h2": ""
    },
    "ordinal_position": 3
  }
}

1:n-Felder in einem Suchindex zuordnen

Feldzuordnungen ordnen ein Quellfeld einem Zielfeld in Situationen zu, in denen die Feldnamen und Typen nicht identisch sind. Feldzuordnungen können jedoch auch verwendet werden, um Teile eines Markdown-Dokuments abzugleichen und sie in Felder der obersten Ebene des Suchdokuments zu "heben".

Das folgende Beispiel veranschaulicht dieses Szenario. Weitere Informationen zu Feldzuordnungen im Allgemeinen finden Sie unter Feldzuordnungen.

Gehen Sie von einem Suchindex mit den folgenden Feldern aus: raw_content vom Typ Edm.String, h1_header vom Typ Edm.Stringund h2_header vom Typ Edm.String. Wenn Sie Ihr Markdown dem gewünschten Shape zuordnen möchten, verwenden Sie die folgenden Feldzuordnungen:

"fieldMappings" : [
    { "sourceFieldName" : "/content", "targetFieldName" : "raw_content" },
    { "sourceFieldName" : "/sections/h1", "targetFieldName" : "h1_header" },
    { "sourceFieldName" : "/sections/h2", "targetFieldName" : "h2_header" },
  ]

Das resultierende Suchdokument im Index würde wie folgt aussehen:

{
  {
    "raw_content": "Content for section 1.\r\n",
    "h1_header": "Section 1",
    "h2_header": "",
  },
  {
    "raw_content": "Content for section 1.1.\r\n",
    "h1_header": "Section 1",
    "h2_header": "Subsection 1.1",
  },
  {
    "raw_content": "Content for section 2.\r\n",
    "h1_header": "Section 2",
    "h2_header": "",
  }
}

Verwenden Sie den Eins-zu-eins-Analysemodus

Im 1:1-Analysemodus wird das gesamte Markdown-Dokument als einzelnes Suchdokument indiziert, wobei die Hierarchie und Struktur des ursprünglichen Inhalts beibehalten wird. Dieser Modus ist am nützlichsten, wenn die zu indizierten Dateien eine gemeinsame Struktur aufweisen, damit Sie diese gemeinsame Struktur im Index verwenden können, um die relevanten Felder durchsuchbar zu machen.

Stellen Sie innerhalb der Indexerdefinition das parsingMode auf "markdown" ein und verwenden Sie den optionalen markdownHeaderDepth-Parameter, um die maximale Tiefenebene für die Segmentierung festzulegen. Wenn nicht angegeben, wird h6 standardmäßig auf alle möglichen Headertiefen angewendet.

Der Markdown wird basierend auf Kopfzeilen in Suchdokumente analysiert, die den folgenden Inhalt enthalten:

  • document_content: Enthält den vollständigen Markdown-Text als einzelne Zeichenfolge. Dieses Feld dient als unformatierte Darstellung des Eingabedokuments.

  • sections: Ein Array von Objekten, das die hierarchische Darstellung der Abschnitte im Markdown-Dokument enthält. Jeder Abschnitt wird in diesem Array als Objekt dargestellt und erfasst die Struktur des Dokuments auf geschachtelte Weise, die den Kopfzeilen und dem jeweiligen Inhalt entspricht. Auf die Felder kann über Feldzuordnungen zugegriffen werden, indem auf den Pfad verwiesen wird, z. B /sections/content. . Die Objekte in diesem Array weisen die folgenden Eigenschaften auf:

    • header_level: Eine Zeichenfolge, die die Ebene der Kopfzeile (h1, h2, h3usw.) in der Markdown-Syntax angibt. Dieses Feld hilft beim Verständnis der Hierarchie und Strukturierung des Inhalts.

    • header_name: Eine Zeichenfolge, die den Text der Kopfzeile enthält, wie sie im Markdown-Dokument angezeigt wird. Dieses Feld stellt eine Beschriftung oder einen Titel für den Abschnitt bereit.

    • content: Eine Zeichenfolge mit Textinhalt, die unmittelbar auf die Kopfzeile folgt, bis zur nächsten Kopfzeile. Dieses Feld erfasst die detaillierten Informationen oder Beschreibungen, die der Kopfzeile zugeordnet sind. Wenn kein Inhalt direkt unter einer Kopfzeile vorhanden ist, handelt es sich bei dem Wert um eine leere Zeichenfolge.

    • ordinal_position: Ein ganzzahliger Wert, der die Position des Abschnitts innerhalb der Dokumenthierarchie angibt. Dieses Feld wird verwendet, um die Abschnitte in der ursprünglichen, im Dokument angezeigten Reihenfolge zu sortieren, beginnend mit einer Ordnungsposition von 1 und einer sequenziellen Erhöhung für jeden Inhaltsblock.

    • sections: Ein Array, das Objekte enthält, die unter dem aktuellen Abschnitt verschachtelte Unterabschnitte darstellen. Dieses Array folgt der gleichen Struktur wie das Array der obersten Ebene sections , was die Darstellung mehrerer Ebenen geschachtelter Inhalte ermöglicht. Jedes Unterabschnittsobjekt enthält die Eigenschaften header_level, header_name, content und ordinal_position, die eine rekursive Struktur ermöglichen, die die Hierarchie des Markdown-Inhalts darstellt.

Hier sehen Sie das Beispiel Markdown, das wir verwenden, um die indexschemas zu erläutern, die für jeden Analysemodus entworfen wurden.

# Section 1
Content for section 1.

## Subsection 1.1
Content for subsection 1.1.

# Section 2
Content for section 2.

Indexschema für die 1:1-Analyse

Wenn Sie keine Feldzuordnungen verwenden, sollte die Form des Indexes die Form des Markdown-Inhalts widerspiegeln. Angesichts der Struktur des Markdown-Beispiels mit den beiden Abschnitten und dem einzelnen Unterabschnitt sollte der Index ähnlich wie im folgenden Beispiel aussehen:

{
  "name": "my-markdown-index",
  "fields": [
  {
    "name": "id",
    "type": "Edm.String",
    "key": true
  },
  {
    "name": "document_content",
    "type": "Edm.String"
  },
  {
    "name": "sections",
    "type": "Collection(Edm.ComplexType)",
    "fields": [
    {
      "name": "header_level",
      "type": "Edm.String"
    },
    {
      "name": "header_name",
      "type": "Edm.String"
    },
    {
      "name": "content",
      "type": "Edm.String"
    },
    {
      "name": "ordinal_position",
      "type": "Edm.Int32"
    },
    {
      "name": "sections",
      "type": "Collection(Edm.ComplexType)",
      "fields": [
      {
        "name": "header_level",
        "type": "Edm.String"
      },
      {
        "name": "header_name",
        "type": "Edm.String"
      },
      {
        "name": "content",
        "type": "Edm.String"
      },
      {
        "name": "ordinal_position",
        "type": "Edm.Int32"
      }]
    }]
  }]
}

Indexerdefinition für die 1:1-Analyse

POST https://[service name].search.windows.net/indexers?api-version=2026-04-01
Content-Type: application/json
api-key: [admin key]

{
  "name": "my-markdown-indexer",
  "dataSourceName": "my-blob-datasource",
  "targetIndexName": "my-target-index",
  "parameters": {
    "configuration": {
      "parsingMode": "markdown",
      "markdownParsingSubmode": "oneToOne",
    }
  }
}

Indexerausgabe für die 1:1-Analyse

Da der Markdown, den wir indizieren möchten, nur bis zu einer Tiefe von h2 ("##") reicht, benötigen wir sections Felder, die bis zu einer Tiefe von 2 geschachtelt sind, um dies anzupassen. Diese Konfiguration würde zu den folgenden Daten im Index führen:

  "document_content": "# Section 1\r\nContent for section 1.\r\n## Subsection 1.1\r\nContent for subsection 1.1.\r\n# Section 2\r\nContent for section 2.\r\n",
  "sections": [
    {
      "header_level": "h1",
      "header_name": "Section 1",
      "content": "Content for section 1.",
      "ordinal_position": 1,
      "sections": [
        {
          "header_level": "h2",
          "header_name": "Subsection 1.1",
          "content": "Content for subsection 1.1.",
          "ordinal_position": 2,
        }]
    }],
    {
      "header_level": "h1",
      "header_name": "Section 2",
      "content": "Content for section 2.",
      "ordinal_position": 3,
      "sections": []
    }]
  }

Wie Sie sehen können, steigt die Ordnungsposition abhängig von der Position des Inhalts innerhalb des Dokuments an.

Wenn Kopfzeilenebenen im Inhalt übersprungen werden, spiegelt die Struktur des resultierenden Dokuments die Kopfzeilen wider, die im Markdown-Inhalt vorhanden sind, und enthält nicht unbedingt aufeinander folgende geschachtelte Abschnitte von h1 bis zu h6. Wenn das Dokument beispielsweise bei h2 beginnt, ist h2 das erste Element im Array der obersten Ebene.

Ordnen Sie Felder in einem Suchindex einander zu.

Um Felder mit benutzerdefinierten Namen aus dem Dokument zu extrahieren, können Sie Feldzuordnungen verwenden. Berücksichtigen Sie die folgende Indexkonfiguration, indem Sie das gleiche Markdown-Beispiel wie zuvor verwenden:

{
  "name": "my-markdown-index",
  "fields": [
    {
      "name": "document_content",
      "type": "Edm.String",
    },
    {
      "name": "document_title",
      "type": "Edm.String",
    },
    {
      "name": "opening_subsection_title",
      "type": "Edm.String"
    },
    {
      "name": "summary_content",
      "type": "Edm.String",
    }
  ]
}

Das Extrahieren bestimmter Felder aus dem analysierten Markdown wird ähnlich wie die Dokumentpfade in outputFieldMappings behandelt, außer der Pfad beginnt mit /sections anstelle von /document. Beispielsweise würde /sections/0/content dem Inhalt unter dem Element an Position 0 im Abschnittsarray zugeordnet.

Ein Beispiel für einen starken Anwendungsfall könnte etwa wie folgt aussehen: Alle Markdown-Dateien haben einen Dokumenttitel im ersten h1, einen Unterabschnittstitel im ersten h2und eine Zusammenfassung im Inhalt des endgültigen Absatzes unterhalb des endgültigen h1Absatzes. Sie können die folgenden Feldzuordnungen verwenden, um nur diesen Inhalt zu indizieren:

"fieldMappings" : [
  { "sourceFieldName" : "/content", "targetFieldName" : "raw_content" },
  { "sourceFieldName" : "/sections/0/header_name", "targetFieldName" : "document_title" },
  { "sourceFieldName" : "/sections/0/sections/header_name", "targetFieldName" : "opening_subsection_title" },
  { "sourceFieldName" : "/sections/1/content", "targetFieldName" : "summary_content" },
]

Hier extrahieren Sie nur die relevanten Teile aus diesem Dokument. Um diese Funktionalität am effektivsten zu verwenden, sollten Dokumente, die Sie indizieren möchten, dieselbe hierarchische Kopfzeilenstruktur aufweisen.

Das resultierende Suchdokument im Index würde wie folgt aussehen:

{
  "content": "Content for section 1.\r\n",
  "document_title": "Section 1",
  "opening_subsection_title": "Subsection 1.1",
  "summary_content": "Content for section 2."
}

Hinweis

In diesen Beispielen wird angegeben, wie diese Analysemodi vollständig mit oder ohne Feldzuordnungen verwendet werden, sie können jedoch in einem Szenario angewendet werden, wenn dies Ihren Anforderungen entspricht.

Verwalten veralteter Dokumente aus der erneuten Indizierung von Markdown

Bei Verwendung des One-to-Many-Parsing-Modus kann das erneute Indizieren einer geänderten Markdown-Datei zu veralteten oder duplizierten Dokumenten führen, wenn Abschnitte entfernt werden. Dieses Verhalten ist spezifisch für den 1:n-Modus und gilt nicht für die 1:1-Analyse.

Verhaltensübersicht

Eins-zu-Viele-Parsemodus

Im oneToMany Modus wird jeder Markdown-Abschnitt (basierend auf Kopfzeilen) als separates Suchdokument indiziert. Wenn die Datei erneut indiziert wird:

  • Keine automatische Löschung: Der Indexer überschreibt vorhandene Dokumente mit neuen Dokumenten, löscht jedoch keine Dokumente, die keinem Inhalt in der aktualisierten Datei mehr entsprechen.
  • Potenzial für Duplikate: Dieses Problem tritt speziell auf, wenn mehr Abschnitte gelöscht werden als zwischen Indizierungsläufen eingefügt werden. In solchen Fällen bleiben übriggebliebene Dokumente aus der vorherigen Version im Index, was zu veralteten Einträgen führt, die nicht mehr den aktuellen Zustand der Quelldatei widerspiegeln.

1:1-Analysemodus

Im oneToOne Modus wird die gesamte Markdown-Datei als einzelnes Suchdokument indiziert. Wenn die Datei erneut indiziert wird:

  • Überschreibverhalten: Das vorhandene Dokument wird vollständig durch die neue Version ersetzt.
  • Keine veralteten Abschnitte: Wenn die Datei erneut indiziert wird, wird das vorhandene Dokument durch die aktualisierte Version ersetzt und entfernte Inhalte nicht mehr enthalten. Die einzige Ausnahme ist, wenn sich der Dateipfad oder blob-URI ändert, was dazu führen kann, dass neben dem alten Dokument ein neues Dokument erstellt wird.

Problemumgehungsoptionen

Um sicherzustellen, dass der Index den aktuellen Status Ihrer Markdown-Dateien widerspiegelt, sollten Sie einen der folgenden Ansätze berücksichtigen:

Option 1: Vorläufiges Löschen mit Metadaten

Diese Methode verwendet ein vorläufiges Löschen, um Dokumente zu löschen, die einem bestimmten Blob zugeordnet sind. Weitere Informationen finden Sie unter Änderungs- und Löschdetektion mit Indexern für Azure Storage in Azure KI-Suche.

Schritte:

  1. Markieren Sie den Blob als gelöscht, indem Sie ein Metadatenfeld festlegen.
  2. Lassen Sie den Indexer ausführen. Es löscht alle Dokumente im Index, der diesem Blob zugeordnet ist.
  3. Entfernen Sie die Soft-Delete-Markierung und indizieren Sie die Datei erneut.

Option 2. Verwenden der Lösch-API

Löschen Sie vor dem erneuten Indizieren einer geänderten Markdown-Datei explizit die vorhandenen Dokumente, die dieser Datei zugeordnet sind, mithilfe der Lösch-API. Sie können eine der folgenden Aktionen ausführen:

  • Identifizieren Sie einzelne veraltete Dokumente manuell, indem Sie Duplikate im zu löschenden Index identifizieren. Dies kann für kleine, gut verstandene Änderungen machbar sein, kann aber zeitaufwändig sein.
  • (Empfohlen) Entfernen Sie alle Dokumente, die vor der erneuten Indizierung aus derselben übergeordneten Datei generiert wurden, und stellen Sie sicher, dass Inkonsistenzen vermieden werden.

Schritte:

  1. Identifizieren Sie die ID der Dokumente, die der Datei zugeordnet sind. Verwenden Sie eine Abfrage wie das folgende Beispiel, um die Dokumentschlüssel-IDs (z. B. id oder chunk_id) für alle Dokumente abzurufen, die an eine bestimmte Datei gebunden sind. Ersetzen Sie metadata_storage_path durch das entsprechende Feld in Ihrem Index, das dem Dateipfad oder der Blob-URI zugeordnet ist. Dieses Feld muss ein Schlüssel sein.

    GET https://[service name].search.windows.net/indexes/[index name]/docs?api-version=2026-04-01
Content-Type: application/json
api-key: [admin key]


  {
      "filter": "metadata_storage_path eq 'https://<storage-account>.blob.core.windows.net/<container-name>/<file-name>.md'",
      "select": "id"
  }

  2. Stellen Sie eine Löschanforderung für die Dokumente mit den identifizierten Schlüsseln aus.

    POST https://[service name].search.windows.net/indexes/[index name]/docs/index?api-version=2026-04-01
Content-Type: application/json
api-key: [admin key]

{
  "value": [
    {
      "@search.action": "delete",
      "id": "aHR0c...jI1"
    },
    {
      "@search.action": "delete",
      "id": "aHR0...MQ2"
    }
  ]
}

  3. Indizieren Sie die aktualisierte Datei erneut.

Nächste Schritte

  • Last updated on