Grote gegevenssets indexeren in Azure AI Zoeken

Notitie

Azure AI Zoeken is beschikbaar via de Azure-portal, REST API's en Azure-SDK's. Het vormt ook een basis voor Foundry IQ, de beheerde kennislaag die bedrijfsinhoud transformeert in herbruikbare, machtigingsbewuste knowledge bases voor agents in de Microsoft Foundry-portal.

Als u grote of complexe gegevenssets in uw zoekoplossing moet indexeren, worden in dit artikel strategieën besproken voor langdurige processen in Azure AI Zoeken.

Bij deze strategieën wordt ervan uitgegaan dat u vertrouwd bent met de twee basismethoden voor het importeren van gegevens: gegevens naar een index pushen of gegevens ophalen uit een ondersteunde gegevensbron met behulp van een zoekindexeerfunctie. Als uw scenario rekenintensieve AI-verrijking omvat, zijn indexeerfuncties vereist, gezien de afhankelijkheid van de vaardighedenset van indexeerfuncties.

Dit artikel vormt een aanvulling op tips voor betere prestaties, die aanbevolen procedures biedt voor index- en queryontwerp. Een goed ontworpen index die alleen de velden en kenmerken bevat die u nodig hebt, is een belangrijke vereiste voor grootschalige indexering.

Gebruik een zoekservice die na 3 april 2024 is gemaakt voor een hogere opslag per partitie. U kunt ook oudere services upgraden om te profiteren van hogere partitieopslag.

Notitie

Bij de strategieën die in dit artikel worden beschreven, wordt uitgegaan van één grote gegevensbron. Als voor uw oplossing indexering van meerdere gegevensbronnen is vereist, raadpleegt u Meerdere gegevensbronnen indexeren in Azure AI Zoeken voor een aanbevolen benadering.

Gegevens indexeren met behulp van de push-API's

Push-API's , zoals de Documents Index REST API of de Methode IndexDocuments (Azure SDK voor .NET) zijn de meest voorkomende vorm van indexering in Azure AI Zoeken. Voor oplossingen die een push-API gebruiken, heeft de strategie voor langlopende indexering een of beide van de volgende onderdelen:

  • Documenten groeperen
  • Threads beheren

Meerdere documenten per aanvraag batchgewijs verwerken

Een eenvoudig mechanisme voor het indexeren van een grote hoeveelheid gegevens is het indienen van meerdere documenten of records in één aanvraag. Zolang de volledige nettolading minder is dan 16 MB, kan een aanvraag maximaal 1000 documenten verwerken in een bulksgewijs uploadbewerking. Deze limieten zijn van toepassing, ongeacht of u de REST API van Documents Index of de methode IndexDocuments in de .NET SDK gebruikt. Met beide API's kunt u 1000 documenten verpakken in de hoofdtekst van elke aanvraag.

Het batcheren van documenten verkort de hoeveelheid tijd die nodig is om een groot gegevensvolume te doorlopen. Het vaststellen van de optimale batchgrootte voor uw gegevens is een belangrijk onderdeel van voor het optimaliseren van de indexeringssnelheid. De twee primaire factoren die van invloed zijn op de optimale batchgrootte zijn:

  • Het schema van uw index
  • De grootte van uw gegevens

Omdat de optimale batchgrootte afhankelijk is van uw index en uw gegevens, kunt u het beste verschillende batchgrootten testen om te bepalen welke de snelste indexeringssnelheden voor uw scenario oplevert. Zie Zelfstudie: Indexering optimaliseren met de push-API voor voorbeeldcode om batchgrootten te testen met behulp van de .NET SDK.

Threads en een strategie voor opnieuw proberen beheren

Indexeerfuncties hebben ingebouwd threadbeheer, maar wanneer u de push-API's gebruikt, moet uw toepassingscode threads beheren. Zorg ervoor dat er voldoende threads zijn om volledig gebruik te maken van de beschikbare capaciteit, met name als u uw service onlangs hebt bijgewerkt, bent overgeschakeld naar een hogere prijscategorie of hogere partities.

  1. Verhoog het aantal gelijktijdige threads in uw clientcode.

  2. Wanneer u de aanvragen voor de zoekservice opvoert, kunt u HTTP-statuscodes tegenkomen die aangeven dat de aanvraag niet volledig is geslaagd. Twee veelvoorkomende HTTP-statuscodes die zich tijdens het indexeren kunnen voordoen, zijn:

    • 503 Service niet beschikbaar: deze fout betekent dat het systeem zwaar wordt belast en uw aanvraag op dit moment niet kan worden verwerkt.

    • 207 Multi-Status: Deze fout betekent dat sommige documenten zijn geslaagd, maar ten minste één is mislukt.

  3. Als u fouten wilt afhandelen, moeten aanvragen opnieuw worden geprobeerd met behulp van een herhalingsstrategie met exponentieel uitstel.

De Azure .NET SDK probeert automatisch 503's en andere mislukte aanvragen opnieuw, maar u moet uw eigen logica implementeren om 207s opnieuw te proberen. Opensource-hulpprogramma's als Polly kunnen ook worden gebruikt voor het implementeren van een herhaalstrategie.

Indexeerfuncties en de pull-API's gebruiken

Indexeerfuncties bieden verschillende mogelijkheden die handig zijn voor langlopende processen:

  • Documenten groeperen
  • Parallelle indexering over gepartitioneerde gegevens
  • Planning en wijzigingsdetectie voor het indexeren van alleen nieuwe en gewijzigde documenten in de loop van de tijd

Indexeerschema's kunnen de verwerking hervatten op het laatst bekende stoppunt. Als de gegevens niet volledig worden geïndexeerd binnen het verwerkingsvenster, gaat de indexeerfunctie bij de volgende uitvoering verder waar deze was gebleven, ervan uitgaand dat u een gegevensbron gebruikt die wijzigingsdetectie ondersteunt.

Het partitioneren van gegevens in kleinere afzonderlijke gegevensbronnen maakt parallelle verwerking mogelijk. U kunt brongegevens opsplitsen, zoals in meerdere containers in Azure Blob Storage, een gegevensbron maken voor elke partitie en vervolgens de indexeerfuncties parallel uitvoeren, afhankelijk van het aantal zoekeenheden van uw zoekservice.

De batchgrootte van de indexeerfunctie controleren

Net als bij de push-API kunt u met indexeerfuncties het aantal items per batch configureren. Voor indexeerfuncties op basis van de REST API voor Indexeerfunctie maken stelt u het batchSize argument in om deze instelling aan te passen zodat deze beter overeenkomt met de kenmerken van uw gegevens.

Standaard batchgrootten zijn gegevensbronspecifiek. Azure SQL Database en Azure Cosmos DB hebben een standaard batchgrootte van 1000. Daarentegen stelt Azure Blob- en SharePoint (preview)-indexering de batchgrootte in op 10 documenten om de grotere gemiddelde documentgrootte te herkennen.

Indexeerfuncties plannen voor langlopende processen

Het plannen van indexeringsactiviteiten is een belangrijk mechanisme voor het verwerken van grote gegevenssets en voor het accommoderen van langzaam verlopende processen zoals beeldanalyse in een verrijkingsketen.

Normaal gesproken wordt de verwerking van de indexeerfunctie binnen een periode van twee uur uitgevoerd. Als de indexeringsworkload dagen in beslag neemt in plaats van uren, kunt u de indexeerder op een opeenvolgende, terugkerende planning plaatsen die om de twee uur begint. Ervan uitgaande dat het bijhouden van wijzigingen is ingeschakeld voor de gegevensbron, wordt de verwerking hervat waar deze het laatst is gebleven. Bij deze frequentie kan een indexeerfunctie een documentachterstand gedurende een reeks dagen doorlopen totdat alle niet-verwerkte documenten worden verwerkt. Dit patroon is vooral belangrijk tijdens de eerste keer dat het wordt uitgevoerd of bij het indexeren van grote blobcontainers, waarbij het opsommen van blobs alleen al meerdere uren of dagen kan duren. In deze periode laat de indexeerfunctie niet zien dat er blobs worden verwerkt, maar tenzij er een fout wordt gemeld, doorloopt deze waarschijnlijk nog steeds de bloblijst. Documentverwerking en verrijking beginnen pas nadat deze fase is voltooid en dit gedrag wordt verwacht.

{
    "dataSourceName" : "hotels-ds",
    "targetIndexName" : "hotels-idx",
    "schedule" : { "interval" : "PT2H", "startTime" : "2024-01-01T00:00:00Z" }
}

Wanneer er geen nieuwe of bijgewerkte documenten meer zijn in de gegevensbron, worden 0/0 documenten verwerkt in de geschiedenis van indexeruitvoeringen en vindt er geen verdere verwerking plaats.

Zie REST API voor Indexeerfunctie maken of Indexeerfuncties plannen voor Azure AI Zoeken voor meer informatie over het instellen van planningen.

Notitie

Het maximale verwerkingsvenster is afhankelijk van of de indexeerfunctie een vaardighedenset heeft. Indexeerfuncties met vaardighedensets worden uitgevoerd in een intern beheerde multitenant-omgeving met een maximum van 2 uur. Indexeerfuncties die zijn geconfigureerd voor het gebruik van gedeelde privékoppelingen worden uitgevoerd met een maximum van 24 uur. Indexeerfuncties zonder vaardighedensets worden uitgevoerd met een maximum van 24 uur.

Als uw indexeerfunctie gebruikmaakt van een vaardighedenset met verrijkingscaching, raadpleegt u de volgende informatie voordat u de cache inschakelt voor grootschalige workloads.

Caution

Voor workloads met langlopende vaardigheden, herhaalde onderbrekingen of frequente fouten kan een verrijkingscache de totale herverwerking tijdens de eerste opname of het herstel verhogen. Een verrijkingscache is geen back-up en houdt niet bij welke documenten de verwerking is voltooid.

Indexeerfuncties parallel uitvoeren

Als u uw gegevens partitioneert, kunt u meerdere combinaties van indexeerfuncties voor gegevensbronnen maken die uit elke gegevensbron worden opgehaald en naar dezelfde zoekindex worden geschreven. Omdat elke indexeerfunctie uniek is, kunt u ze tegelijkertijd uitvoeren, zodat u een zoekindex sneller vult dan wanneer u ze opeenvolgend hebt uitgevoerd.

Zorg ervoor dat u voldoende capaciteit hebt. Eén zoekeenheid in uw service kan op elk gewenst moment één indexeerfunctie uitvoeren. Het maken van meerdere indexeerfuncties is alleen nuttig als ze parallel kunnen worden uitgevoerd.

Het aantal indexeringstaken dat tegelijkertijd kan worden uitgevoerd, varieert voor indexering op basis van tekst en vaardigheden. Zie De uitvoering van de indexeerfunctie voor meer informatie.

Als uw gegevensbron een Azure Blob Storage-container of Azure Data Lake Storage Gen 2 is, kan het opsommen van een groot aantal blobs lang (zelfs uren) duren totdat deze bewerking is voltooid. Als gevolg hiervan lijkt het aantal geslaagde documenten van uw indexeerfunctie in die periode niet toe te nemen en kan het lijken alsof er geen voortgang wordt geboekt, terwijl dat wel het geval is. Als u wilt dat documentverwerking sneller verloopt voor een groot aantal blobs, kunt u overwegen om uw gegevens te partitioneren in meerdere containers en parallelle indexeerfuncties te maken die verwijzen naar één index.

  1. Ga naar uw zoekservice in Azure Portal.

  2. Controleer het aantal zoekeenheden dat door uw zoekservice wordt gebruikt. Selecteer Instellingen>schalen om het nummer boven aan de pagina weer te geven. Het aantal indexeerfuncties dat parallel wordt uitgevoerd, is ongeveer gelijk aan het aantal zoekeenheden.

  3. Partitiebrongegevens tussen meerdere containers of meerdere virtuele mappen in dezelfde container.

  4. Maak meerdere gegevensbronnen, één voor elke partitie, gekoppeld aan een eigen indexeerfunctie.

  5. Geef dezelfde doelzoekindex op in elke indexeerfunctie.

  6. Plan de indexeerders.

  7. Controleer de status van de indexeerfunctie en uitvoeringsgeschiedenis voor bevestiging.

Er zijn enkele risico's verbonden aan parallelle indexering. Onthoud eerst dat indexering niet op de achtergrond wordt uitgevoerd, wat de kans verhoogt dat query's worden beperkt of verwijderd.

Ten tweede vergrendelt Azure AI Zoeken de index niet voor updates. Gelijktijdige schrijfbewerkingen worden beheerd door een nieuwe poging aan te roepen als een bepaalde schrijfbewerking niet lukt bij de eerste poging, maar u ziet mogelijk een toename in indexeringsfouten.

Hoewel meerdere indexeerder-gegevensbronsets op dezelfde index kunnen zijn gericht, moet u voorzichtig zijn met indexeerprocessen die bestaande waarden in de index kunnen overschrijven. Als een tweede indexeerfunctie-gegevensbron gericht is op dezelfde documenten en velden, worden alle waarden van de eerste uitvoering overschreven. Veldwaarden worden volledig vervangen; een indexeerfunctie kan geen waarden uit meerdere uitvoeringen samenvoegen in hetzelfde veld.

Big data indexeren in Spark

Als u een big data-architectuur hebt en uw gegevens zich in een Spark-cluster bevinden, gebruikt u SynapseML voor het laden en indexeren van gegevens. De zelfstudie bevat stappen voor het aanroepen van Foundry Tools voor AI-verrijking, maar u kunt ook de AzureSearchWriter-API gebruiken voor tekstindexering.

Gerelateerde inhoud

  • Laatst bijgewerkt om