Delen via

Een indexprojectie definiëren voor bovenliggende en onderliggende indexering

  • Artikel

Voor indexen met gesegmenteerde documenten geeft een indexprojectie aan hoe bovenliggende en onderliggende inhoud wordt toegewezen aan velden in een zoekindex voor een-op-veel-indexering. Via een indexprojectie kunt u inhoud verzenden naar:

  • Eén index, waarbij de bovenliggende velden voor elk segment worden herhaald, maar de korrel van de index zich op segmentniveau bevindt. De RAG-zelfstudie is een voorbeeld van deze benadering.

  • Twee of meer indexen, waarbij de bovenliggende index velden bevat die betrekking hebben op het bovenliggende document en de onderliggende index is geordend rond segmenten. De onderliggende index is het primaire zoekpakket, maar de bovenliggende index kan worden gebruikt voor opzoekquery's wanneer u de bovenliggende velden van een bepaald segment of voor onafhankelijke query's wilt ophalen.

De meeste implementaties zijn één index die is geordend rond segmenten met bovenliggende velden, zoals de bestandsnaam van het document, die voor elk segment wordt herhaald. Het systeem is echter ontworpen om afzonderlijke en meerdere onderliggende indexen te ondersteunen als dat uw behoeften is. Azure AI Search biedt geen ondersteuning voor indexdeelnames, zodat uw toepassingscode moet afhandelen welke index moet worden gebruikt.

Een indexprojectie wordt gedefinieerd in een vaardighedenset. Het is verantwoordelijk voor het coördineren van het indexeringsproces dat segmenten van inhoud naar een zoekindex verzendt, samen met de bovenliggende inhoud die aan elk segment is gekoppeld. Het verbetert de werking van systeemeigen gegevenssegmentering door meer opties te bieden voor het beheren van de wijze waarop inhoud van bovenliggende en onderliggende items wordt geïndexeerd.

In dit artikel wordt uitgelegd hoe u het indexschema en de projectiepatronen voor indexeerfuncties voor een-op-veel-indexering maakt.

Vereisten

De vaardighedenset bevat de indexeerfunctieprojectie die de gegevens voor een-op-veel-indexering vormgeeft. Een vaardighedenset kan ook andere vaardigheden hebben, zoals een insluitvaardigheid zoals AzureOpenAIEmbedding als uw scenario geïntegreerde vectorisatie omvat.

Afhankelijkheid van verwerking van indexeerfuncties

Een-op-veel-indexering heeft een afhankelijkheid van vaardighedensets en indexering op basis van indexeerfuncties die de volgende vier onderdelen bevatten:

  • Een gegevensbron
  • Een of meer indexen voor uw doorzoekbare inhoud
  • Een vaardighedenset met een indexprojectie*
  • Een indexeerfunctie

Uw gegevens kunnen afkomstig zijn van elke ondersteunde gegevensbron, maar de veronderstelling is dat de inhoud groot genoeg is om deze te segmenteren en de reden voor het segmenteren is dat u een RAG-patroon implementeert dat grondgegevens aan een chatmodel biedt. Of u implementeert vectorzoekopdrachten en moet voldoen aan de kleinere invoervereisten voor het insluiten van modellen.

Indexeerfuncties laden geïndexeerde gegevens in een vooraf gedefinieerde index. Hoe u het schema definieert en of u een of meer indexen wilt gebruiken, is de eerste beslissing die u moet nemen in een een-op-veel-indexeringsscenario. In de volgende sectie wordt het indexontwerp behandeld.

Een index maken voor een-op-veel-indexering

Of u nu één index maakt voor segmenten die bovenliggende waarden herhalen of afzonderlijke indexen voor plaatsing van bovenliggende en onderliggende velden, de primaire index die wordt gebruikt voor het zoeken, is ontworpen rond gegevenssegmenten. Deze moet de volgende velden hebben:

  • Een documentsleutelveld dat elk document uniek identificeert. Het moet worden gedefinieerd als type Edm.String met de keyword analyse.

  • Een veld dat elk segment aan het bovenliggende segment aan elkaar koppelen. Het moet van het type Edm.Stringzijn. Het kan niet het documentsleutelveld zijn en moet zijn filterable ingesteld op waar. Dit wordt parent_id genoemd in de voorbeelden en als een geprojecteerde sleutelwaarde in dit artikel.

  • Andere velden voor inhoud, zoals tekst of gevectoriseerde segmentvelden.

Er moet een index aanwezig zijn in de zoekservice voordat u de vaardighedenset maakt of de indexeerfunctie uitvoert.

Schema met één index inclusief bovenliggende en onderliggende velden

Eén index die is ontworpen rond segmenten met bovenliggende inhoud die voor elk segment wordt herhaald, is het overheersende patroon voor RAG- en vectorzoekscenario's. De mogelijkheid om de juiste bovenliggende inhoud aan elk segment te koppelen, wordt ingeschakeld via indexprojecties.

Het volgende schema is een voorbeeld dat voldoet aan de vereisten voor indexprojecties. In dit voorbeeld zijn bovenliggende velden de parent_id en de titel. Onderliggende velden zijn de vector- en nietvectorvectorsegmenten. De chunk_id is de document-id van deze index. De parent_id en titel herhalen voor elk segment in de index.

U kunt Azure Portal, REST API's of een Azure SDK gebruiken om een index te maken.

{
    "name": "my_consolidated_index",
    "fields": [
        {"name": "chunk_id", "type": "Edm.String", "key": true, "filterable": true, "analyzer": "keyword"},
        {"name": "parent_id", "type": "Edm.String", "filterable": true},
        {"name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "sortable": true, "retrievable": true},
        {"name": "chunk", "type": "Edm.String","searchable": true,"retrievable": true},
        {"name": "chunk_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": false, "stored": false, "dimensions": 1536, "vectorSearchProfile": "hnsw"}
    ],
    "vectorSearch": {
        "algorithms": [{"name": "hsnw", "kind": "hnsw", "hnswParameters": {}}],
        "profiles": [{"name": "hsnw", "algorithm": "hnsw"}]
    }
}

Indexprojecties toevoegen aan een vaardighedenset

Indexprojecties worden gedefinieerd in een definitie van een vaardighedenset en worden voornamelijk gedefinieerd als een matrix van selectors, waarbij elke selector overeenkomt met een andere doelindex in de zoekservice. Deze sectie begint met syntaxis en voorbeelden voor context, gevolgd door parameterreferentie.

Kies een tabblad voor de verschillende API-syntaxis. Er is momenteel geen portalondersteuning voor het instellen van projecties, behalve het bewerken van de JSON-definitie van de vaardighedenset. Raadpleeg het REST-voorbeeld voor JSON.

Indexprojecties zijn algemeen beschikbaar. We raden de meest recente stabiele API aan:

Hier volgt een voorbeeld van een nettolading voor een definitie van indexprojecties die u kunt gebruiken om afzonderlijke pagina's te projecteren op basis van de vaardigheid Tekst splitsen als hun eigen documenten in de zoekindex.

"indexProjections": {
    "selectors": [
        {
            "targetIndexName": "my_consolidated_index",
            "parentKeyFieldName": "parent_id",
            "sourceContext": "/document/pages/*",
            "mappings": [
                {
                    "name": "chunk",
                    "source": "/document/pages/*",
                    "sourceContext": null,
                    "inputs": []
                },
                {
                    "name": "chunk_vector",
                    "source": "/document/pages/*/chunk_vector",
                    "sourceContext": null,
                    "inputs": []
                },
                {
                    "name": "title",
                    "source": "/document/title",
                    "sourceContext": null,
                    "inputs": []
                }
            ]
        }
    ],
    "parameters": {
        "projectionMode": "skipIndexingParentDocuments"
    }
}

Parameterreferentie

Parameters voor indexprojectie Definitie
selectors Parameters voor de hoofdzoekopdracht, meestal de parameter die rond segmenten is ontworpen.
projectionMode Een optionele parameter met instructies voor de indexeerfunctie. De enige geldige waarde voor deze parameter is skipIndexingParentDocumentsen wordt gebruikt wanneer de segmentindex de primaire zoekactie is en u moet opgeven of bovenliggende velden worden geïndexeerd als extra zoekdocumenten in de gesegmenteerde index. Als u dit niet instelt skipIndexingParentDocuments, krijgt u extra zoekdocumenten in uw index die null zijn voor segmenten, maar alleen gevuld met bovenliggende velden. Als vijf documenten bijvoorbeeld 100 segmenten aan de index bijdragen, is het aantal documenten in de index 105. De vijf documenten die zijn gemaakt of bovenliggende velden hebben null-waarden voor segmentvelden (onderliggende velden), waardoor ze aanzienlijk verschillen van het grootste deel van de documenten in de index. We raden u aan projectionMode in te stellen op skipIndexingParentDocument.

Selectors hebben de volgende parameters als onderdeel van hun definitie.

Selectorparameters Definitie
targetIndexName De naam van de index waarin indexgegevens worden geprojecteerd. Dit is de enkelvoudige gesegmenteerde index met herhalende bovenliggende velden of de onderliggende index als u afzonderlijke indexen gebruikt voor bovenliggende en onderliggende inhoud.
parentKeyFieldName De naam van het veld met de sleutel voor het bovenliggende document.
sourceContext De verrijkingsaantekening waarmee de granulariteit wordt gedefinieerd waarmee gegevens kunnen worden toegewezen aan afzonderlijke zoekdocumenten. Zie Vaardigheidscontext en invoeraantekeningstaal voor meer informatie.
mappings Een matrix van toewijzingen van verrijkte gegevens aan velden in de zoekindex. Elke toewijzing bestaat uit:
name: De naam van het veld in de zoekindex waarin de gegevens moeten worden geïndexeerd.
source: Het verrijkingsaantekeningspad waaruit de gegevens moeten worden opgehaald.

Elk mapping kan ook recursief gegevens definiëren met een optioneel sourceContext veld, inputs vergelijkbaar met het kennisarchief of Shaper Skill. Afhankelijk van uw toepassing kunt u met deze parameters gegevens vormgeven in velden van het type Edm.ComplexType in de zoekindex. Sommige LLM's accepteren geen complex type in zoekresultaten, dus de LLM die u gebruikt, bepaalt of een complexe typetoewijzing nuttig is of niet.

De mappings parameter is belangrijk. U moet elk veld in de onderliggende index expliciet toewijzen, met uitzondering van de id-velden zoals documentsleutel en de bovenliggende id.

Deze vereiste is in tegenstelling tot andere veldtoewijzingsconventies in Azure AI Search. Voor sommige gegevensbrontypen kan de indexeerfunctie impliciet velden toewijzen op basis van vergelijkbare namen of bekende kenmerken (bijvoorbeeld blob-indexeerfuncties gebruiken het unieke opslagpad voor metagegevens als de standaarddocumentsleutel). Voor indexeerprojecties moet u echter expliciet elke veldtoewijzing aan de 'veel'-kant van de relatie opgeven.

Maak geen veldtoewijzing voor het bovenliggende sleutelveld. Hierdoor wordt het bijhouden van wijzigingen en het vernieuwen van gesynchroniseerde gegevens verstoord.

Bovenliggende documenten verwerken

Nu u verschillende patronen voor een-op-veel-indexeringen hebt gezien, kunt u belangrijke verschillen over elke optie vergelijken. Indexprojecties genereren effectief 'onderliggende' documenten voor elk 'bovenliggend' document dat wordt uitgevoerd via een vaardighedenset. U hebt verschillende opties voor het verwerken van de 'bovenliggende' documenten.

  • Als u bovenliggende en onderliggende documenten wilt verzenden naar afzonderlijke indexen, stelt u de targetIndexName definitie van de indexeerfunctie in op de bovenliggende index en stelt u de targetIndexName in de indexprojectieselector in op de onderliggende index.

  • Als u bovenliggende en onderliggende documenten in dezelfde index wilt bewaren, stelt u de indexeerfunctie targetIndexName en de indexprojectie targetIndexName in op dezelfde index.

  • Als u wilt voorkomen dat bovenliggende zoekdocumenten worden gemaakt en ervoor wilt zorgen dat de index alleen onderliggende documenten van een uniforme korrel bevat, stelt u zowel targetIndexName de definitie van de indexeerfunctie als de selector in op dezelfde index, maar voegt u een extra parameters object toe na selectors, waarbij een projectionMode sleutel is ingesteld op skipIndexingParentDocuments, zoals hier wordt weergegeven:

    "indexProjections": {
    "selectors": [
        ...
    ],
    "parameters": {
        "projectionMode": "skipIndexingParentDocuments"
    }
}

Veldtoewijzingen controleren

Indexeerfuncties zijn gekoppeld aan drie verschillende typen veldtoewijzingen. Voordat u de indexeerfunctie uitvoert, controleert u de veldtoewijzingen en weet u wanneer u elk type moet gebruiken.

Veldtoewijzingen worden gedefinieerd in een indexeerfunctie en worden gebruikt om een bronveld toe te wijzen aan een indexveld. Veldtoewijzingen worden gebruikt voor gegevenspaden die gegevens uit de bron opheffen en doorgeven voor indexering, zonder tussenliggende vaardighedenverwerkingsstap. Normaal gesproken kan een indexeerfunctie automatisch velden toewijzen met dezelfde naam en hetzelfde type. Expliciete veldtoewijzingen zijn alleen vereist wanneer er verschillen zijn. Bij een-op-veel-indexering en de patronen die tot nu toe zijn besproken, hebt u mogelijk geen veldtoewijzingen nodig.

Uitvoerveldtoewijzingen worden gedefinieerd in een indexeerfunctie en gebruikt om verrijkte inhoud die door een vaardighedenset wordt gegenereerd, toe te wijzen aan een veld in de hoofdindex. In de een-op-veel-patronen die in dit artikel worden behandeld, is dit de bovenliggende index in een oplossing met twee indexen. In de voorbeelden in dit artikel is de bovenliggende index sparse, met alleen een titelveld en dat veld wordt niet gevuld met inhoud van de vaardighedensetverwerking, dus we hebben geen toewijzing van uitvoervelden.

Indexeerfunctieprojectieveldtoewijzingen worden gebruikt om door vaardighedenset gegenereerde inhoud toe te wijzen aan velden in de onderliggende index. In gevallen waarin de onderliggende index ook bovenliggende velden bevat (zoals in de geconsolideerde indexoplossing), moet u veldtoewijzingen instellen voor elk veld met inhoud, inclusief het titelveld op bovenliggend niveau, ervan uitgaande dat u de titel wilt weergeven in elk gesegmenteerd document. Als u afzonderlijke bovenliggende en onderliggende indexen gebruikt, moeten de indexeerfuncties veldtoewijzingen hebben voor alleen de velden op onderliggend niveau.

Notitie

Zowel uitvoerveldtoewijzingen als veldtoewijzingen voor indexeerfuncties accepteren verrijkte documentstructuurknooppunten als broninvoer. Weten hoe u een pad naar elk knooppunt opgeeft, is essentieel voor het instellen van het gegevenspad. Zie Voor meer informatie over padsyntaxis een pad naar verrijkte knooppunten en definitie van vaardighedenset voor voorbeelden.

De indexeerfunctie uitvoeren

Zodra u een gegevensbron, indexen en vaardighedenset hebt gemaakt, kunt u de indexeerfunctie maken en uitvoeren. Met deze stap wordt de pijplijn in uitvoering gebracht.

Nadat de verwerking is voltooid, kunt u een query uitvoeren op uw zoekindex om uw oplossing te testen.

Levenscyclus van inhoud

Afhankelijk van de onderliggende gegevensbron kan een indexeerfunctie doorgaans doorlopende detectie van wijzigingen bijhouden en verwijderen bieden. In deze sectie wordt de levenscyclus van inhoud van een-op-veel-indexering uitgelegd, omdat het betrekking heeft op het vernieuwen van gegevens.

Voor gegevensbronnen die detectie van wijzigingen bijhouden en verwijderen bieden, kan een indexeerfunctie wijzigingen in uw brongegevens ophalen. Telkens wanneer u de indexeerfunctie en vaardighedenset uitvoert, worden de indexprojecties bijgewerkt als de vaardighedenset of onderliggende brongegevens zijn gewijzigd. Wijzigingen die door de indexeerfunctie worden opgehaald, worden via het verrijkingsproces doorgegeven aan de projecties in de index, zodat uw verwachte gegevens een huidige weergave van inhoud in de oorspronkelijke gegevensbron zijn. Gegevensvernieuwingsactiviteit wordt vastgelegd in een projected sleutelwaarde voor elk segment. Deze waarde wordt bijgewerkt wanneer de onderliggende gegevens worden gewijzigd.

Notitie

Hoewel u de gegevens in de geprojecteerde documenten handmatig kunt bewerken met behulp van de indexpush-API, moet u dit vermijden. Handmatige updates voor een index worden overschreven bij de volgende pijplijnaanroep, ervan uitgaande dat het document in de brongegevens wordt bijgewerkt en de gegevensbron de detectie van wijzigingen bijhouden of verwijderen heeft ingeschakeld.

Bijgewerkte inhoud

Als u nieuwe inhoud aan uw gegevensbron toevoegt, worden nieuwe segmenten of onderliggende documenten toegevoegd aan de index tijdens de volgende indexeerfunctieuitvoering.

Als u bestaande inhoud in de gegevensbron wijzigt, worden segmenten stapsgewijs bijgewerkt in de zoekindex als de gegevensbron die u gebruikt ondersteuning biedt voor het bijhouden en verwijderen van wijzigingen. Als een woord of zin in een document verandert, wordt het segment in de doelindex met dat woord of de zin bijgewerkt tijdens de volgende uitvoering van de indexeerfunctie. Andere typen updates, zoals het wijzigen van een veldtype en sommige toewijzingen, worden niet ondersteund voor bestaande velden. Zie Een indexschema wijzigen voor meer informatie over toegestane updates.

Sommige gegevensbronnen zoals Azure Storage ondersteunen standaard het bijhouden van wijzigingen en verwijderingen, op basis van de tijdstempel. Andere gegevensbronnen, zoals OneLake, Azure SQL of Azure Cosmos DB , moeten worden geconfigureerd voor het bijhouden van wijzigingen.

Verwijderde inhoud

Als de broninhoud niet meer bestaat (bijvoorbeeld als tekst wordt ingekort tot minder segmenten), wordt het bijbehorende onderliggende document in de zoekindex verwijderd. De resterende onderliggende documenten krijgen ook hun sleutel bijgewerkt om een nieuwe hashwaarde op te nemen, zelfs als hun inhoud anders niet is gewijzigd.

Als een bovenliggend document volledig uit de gegevensbron is verwijderd, worden de bijbehorende onderliggende documenten alleen verwijderd als de verwijdering wordt gedetecteerd door een dataDeletionDetectionPolicy gedefinieerde definitie van de gegevensbron. Als u geen geconfigureerd document hebt dataDeletionDetectionPolicy geconfigureerd en een bovenliggend document uit de gegevensbron wilt verwijderen, moet u de onderliggende documenten handmatig verwijderen als ze niet meer nodig zijn.

Verwachte sleutelwaarde

Om ervoor te zorgen dat gegevensintegriteit voor bijgewerkte en verwijderde inhoud wordt vernieuwd, is het vernieuwen van gegevens in een-op-veel-indexering afhankelijk van een verwachte sleutelwaarde aan de 'veel'-zijde. Als u geïntegreerde vectorisatie of de wizard Gegevens importeren en vectoriseren gebruikt, is de verwachte sleutelwaarde het parent_id veld in een segment of 'veel'-zijde van de index.

Een verwachte sleutelwaarde is een unieke id die door de indexeerfunctie voor elk document wordt gegenereerd. Het zorgt voor uniekheid en zorgt ervoor dat het bijhouden van wijzigingen en verwijderingen correct werkt. Deze sleutel bevat de volgende segmenten:

  • Een willekeurige hash om uniekheid te garanderen. Deze hash verandert als het bovenliggende document wordt bijgewerkt op volgende indexeerfunctie wordt uitgevoerd.
  • De sleutel van het bovenliggende document.
  • Het verrijkingsaantekeningspad waarmee de context wordt geïdentificeerd waaruit dat document is gegenereerd.

Als u bijvoorbeeld een bovenliggend document splitst met de sleutelwaarde 'aa1b22c33' in vier pagina's, wordt elk van deze pagina's als een eigen document geprojecteerd via indexprojecties:

  • aa1b22c33
  • aa1b22c33_pages_0
  • aa1b22c33_pages_1
  • aa1b22c33_pages_2

Als het bovenliggende document wordt bijgewerkt in de brongegevens, wat mogelijk resulteert in meer gesegmenteerde pagina's, worden de willekeurige hashwijzigingen, meer pagina's toegevoegd en wordt de inhoud van elk segment bijgewerkt zodat deze overeenkomt met wat er in het brondocument staat.

Voorbeeld van afzonderlijke bovenliggende en onderliggende indexen

In deze sectie ziet u voorbeelden voor afzonderlijke bovenliggende en onderliggende indexen. Het is een ongebruikelijk patroon, maar het is mogelijk dat u toepassingsvereisten hebt die het beste voldoen aan deze benadering. In dit scenario projecteert u bovenliggende en onderliggende inhoud in twee afzonderlijke indexen.

Elk schema bevat de velden voor de specifieke korrel, waarbij het bovenliggende id-veld gebruikelijk is voor beide indexen voor gebruik in een opzoekquery. Het primaire zoekpakket is de onderliggende index, maar geef vervolgens een opzoekquery uit om de bovenliggende velden op te halen voor elke overeenkomst in het resultaat. Azure AI Search biedt geen ondersteuning voor joins op het moment van query's, dus uw toepassingscode- of indelingslaag moet resultaten samenvoegen of sorteren die kunnen worden doorgegeven aan een app of proces.

De bovenliggende index heeft een parent_id veld en titel. De parent_id is de documentsleutel. U hebt geen configuratie voor vectorzoekopdrachten nodig, tenzij u velden op het bovenliggende documentniveau wilt vectoriseren.

{
    "name": "my-parent-index",
    "fields": [

        {"name": "parent_id", "type": "Edm.String", "filterable": true},
        {"name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "sortable": true, "retrievable": true},
    ]
}

De onderliggende index bevat de gesegmenteerde velden, plus het parent_id veld. Als u geïntegreerde vectorisatie, scoreprofielen, semantische rangschikking of analyses gebruikt, stelt u deze in de onderliggende index in.

{
    "name": "my-child-index",
    "fields": [
        {"name": "chunk_id", "type": "Edm.String", "key": true, "filterable": true, "analyzer": "keyword"},
        {"name": "parent_id", "type": "Edm.String", "filterable": true},
         {"name": "chunk", "type": "Edm.String","searchable": true,"retrievable": true},
        {"name": "chunk_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": false, "stored": false, "dimensions": 1536, "vectorSearchProfile": "hnsw"}
    ],
    "vectorSearch": {
        "algorithms": [{"name": "hsnw", "kind": "hnsw", "hnswParameters": {}}],
        "profiles": [{"name": "hsnw", "algorithm": "hnsw"}]
    },
    "scoringProfiles": [],
    "semanticConfiguration": [],
    "analyzers": []
}

Hier volgt een voorbeeld van een definitie van een indexprojectie die het gegevenspad aangeeft dat de indexeerfunctie moet gebruiken om inhoud te indexeren. Hiermee geeft u de naam van de onderliggende index op in de definitie van de indexprojectie en geeft u de toewijzingen van elk onderliggend veld of segmentniveau op. Dit is de enige plaats waar de naam van de onderliggende index is opgegeven.

"indexProjections": {
    "selectors": [
        {
            "targetIndexName": "my-child-index",
            "parentKeyFieldName": "parent_id",
            "sourceContext": "/document/pages/*",
            "mappings": [
                {
                    "name": "chunk",
                    "source": "/document/pages/*",
                    "sourceContext": null,
                    "inputs": []
                },
                {
                    "name": "chunk_vector",
                    "source": "/document/pages/*/chunk_vector",
                    "sourceContext": null,
                    "inputs": []
                }
            ]
        }
    ]
}

De definitie van de indexeerfunctie geeft de onderdelen van de pijplijn aan. In de definitie van de indexeerfunctie is de indexnaam die moet worden opgegeven de bovenliggende index. Als u veldtoewijzingen nodig hebt voor de velden op bovenliggend niveau, definieert u deze in outputFieldMappings. Voor een-op-veel-indexering die gebruikmaakt van afzonderlijke indexen, kan de definitie van de indexeerfunctie eruitzien als in het volgende voorbeeld.

{
  "name": "my-indexer",
  "dataSourceName": "my-ds",
  "targetIndexName": "my-parent-index",
  "skillsetName" : "my-skillset"
  "parameters": { },
  "fieldMappings": (optional) Maps fields in the underlying data source to fields in an index,
  "outputFieldMappings" : (required) Maps skill outputs to fields in an index,
}

Volgende stap

Gegevenssegmentering en een-op-veel-indexering maken deel uit van het RAG-patroon in Azure AI Search. Ga verder met de volgende zelfstudie en codevoorbeeld voor meer informatie.

Een RAG-oplossing bouwen met behulp van Azure AI Search