Problemen met opslag- en metrische verschillen in Azure AI Zoeken oplossen

In dit artikel vindt u antwoorden op veelgestelde vragen over metrische opslaggegevens die inconsistent lijken in Azure Portal, REST API's en Azure SDK's.

Opslagwaarden in Azure AI Zoeken worden periodiek verzameld en weerspiegelen mogelijk niet de realtime status. Daarom worden in de meeste scenario's afwijkingen op korte termijn verwacht.

Zie Monitor Azure AI Zoeken voor achtergrondinformatie over hoe metrische gegevens worden verzameld en gerapporteerd.

Waarom wordt de opslag niet onmiddellijk gewijzigd wanneer ik documenten verwijder of bijwerk?

Wanneer u documenten verwijdert, verwerkt Azure AI Zoeken de verwijdering onmiddellijk, maar het vrijmaken van fysieke opslagruimte gebeurt via samenvoegingsbewerkingen op de achtergrond. Het onderliggende document wordt gemarkeerd als verwijderd en overgeslagen tijdens volgende query's. Naarmate er nieuwe documenten worden geïndexeerd en de interne index groeit, worden verwijderde documenten opgeschoond en worden de resources vrijgemaakt. Dit betekent dat u waarschijnlijk een vertraging ondervindt tussen het verwijderen van documenten en de onderliggende resources die worden vrijgemaakt.

Documentupdates hebben een vergelijkbaar effect op de opslag. Omdat documenten onveranderbaar zijn, is een update intern een bewerking voor verwijderen en invoegen: de oude versie wordt gemarkeerd als verwijderd en er wordt een nieuwe versie ingevoegd. Totdat bewerkingen voor achtergrondsamenvoeging de oude versie opschonen, ziet u mogelijk dat de opslag tijdelijk toeneemt in plaats van hetzelfde te blijven.

Deze samenvoegbewerkingen worden doorgaans binnen 24 tot 72 uur voltooid, afhankelijk van de hoeveelheid belasting van de service. Als u dicht bij de opslaglimiet van uw prijscategorie bent, moet u rekening houden met deze tijdelijke toename wanneer u grootschalige updates of documentvervangingen plant.

Zie Documenten verwijderen in een zoekindex en overhead voor het verwijderen of bijwerken van documenten in de index voor meer informatie.

Waarom verschillen portal- en API-waarden op hetzelfde moment?

Azure Portal en REST API's kunnen verschillende waarden rapporteren omdat ze verschillende vernieuwingsfrequenties hebben. Specifiek:

• Het tabblad Gebruik op de overzichtspagina van de portal wordt regelmatig vernieuwd, meestal om de paar minuten.
• GET Service Statistics retourneert prestatiemeters op serviceniveau, zoals storageSize, vectorIndexSize, en documentCount.
• GET Index Statistics geeft indexspecifieke tellers terug.

Statistieken op service- en indexniveau worden onafhankelijk en met verschillende intervallen verzameld. Een momentopname van het ene oppervlak is mogelijk niet afgestemd op een momentopname van het andere als deze niet tegelijkertijd zijn vastgelegd. Dit gedrag is normaal en geeft geen defect aan.

Zie Azure AI Zoeken bewaken voor meer informatie over het bewaken van oppervlakten.

Waarom is een herbouwde index groter dan een oudere index met vergelijkbare inhoud?

Een herbouwde index kan tijdelijk een ander opslagprofiel weergeven omdat bewerkingen voor het samenvoegen van achtergronden de oude documentversies niet hebben opgeschoond. Afhankelijk van de belasting van de service duren deze samenvoegingen doorgaans 24 tot 72 uur. Gedurende deze periode kan de opslag groter zijn dan verwacht. Dit is vooral belangrijk om rekening mee te houden als u de opslaglimiet van uw prijscategorie nadert. Plan grote herbouw- of migratiebewerkingen tijdens perioden van lagere indexeringsactiviteit en bewaak metrische opslaggegevens totdat de samenvoegingen zijn voltooid.

Zelfs nadat de samenvoegbewerkingen zijn voltooid, kan de uiteindelijke grootte van een herbouwde index enigszins afwijken van het origineel. De grootte van de indexopslag is niet-deterministisch en verschillende factoren zijn van invloed op het resultaat:

• Schemawijzigingen, zoals het toevoegen van velden, analysen of vectorconfiguraties.
• Opname- en updatepatronen die van invloed zijn op de verhouding van verwijderde documenten.
• Instellingen voor vectoroptimalisatie, zoals kwantisatie of opslagreductieopties.

Zie Vector-indexgrootte en -limieten en servicelimietenin Azure AI Zoeken voor meer informatie over factoren die van invloed zijn op de grootte.

Waarom komt de totale grootte van de opslag-vectorindex niet overeen?

storageSize en vectorIndexSize meet verschillende dingen:

• storageSize is de totale schijfvoetafdruk van een index, inclusief inhoud van alle gegevenstypen, zoals tekst, metagegevens en vectoren.
• vectorIndexSize is een limiet voor de grootte van een vectorindex die in het geheugen is geladen. Vectorvelden waarvoor het uitgebreide KNN-algoritme wordt gebruikt, verbruiken geen vectorindexquotum en rapporteren nul voor vectorIndexSize. Zie Vector-indexgrootte en -limieten voor meer informatie.

Op schijf kan de totale opslag die door vectoren wordt verbruikt, groter zijn dan de indexgrootte van de in-memory vector omdat Azure AI Zoeken meerdere kopieën van vectorvelden opslaat voor verschillende doeleinden. Zie Optionele vectorexemplaren uit de opslag verwijderen voor informatie over wat deze kopieën zijn en hoe u het schijfverbruik kunt verminderen.

Hoe moet ik metrische gegevens correct vergelijken?

Als u wilt bepalen of een discrepantie reëel is of een timingartefact, legt u waarden vast van hetzelfde oppervlak binnen een consistent UTC-tijdvenster:

1. Roep GET-servicestatistieken en GET-indexstatistieken aan binnen hetzelfde venster van vijf minuten.
2. Herhaal steekproeven op een vaste frequentie, zoals elke 20 tot 30 minuten.
3. Vergelijk ten minste drie opeenvolgende vensters voordat u besluit dat waarden niet worden samengevoegd.
4. Evalueer storageSize afzonderlijk van vectorIndexSize , omdat ze verschillende fysieke structuren bijhouden.

Wanneer is een discrepantie verwacht versus een werkelijk defect?

De meeste verschillen worden verwacht en opgelost zonder tussenkomst. Als aan de defectcriteria wordt voldaan, opent u een ondersteuningsaanvraag met het bewijs dat in de volgende sectie wordt beschreven.

Verwachte afwijking

• U hebt onlangs zware indexering, updates of verwijderingen uitgevoerd en waarden worden nog steeds samengevoegd.
• Portal- en API-waarden verschillen, maar de kloof wordt kleiner bij herhaalde steekproeven.
• storageSize en vectorIndexSize niet overeenkomen, wat standaard is omdat ze verschillende dingen meten.

Mogelijk defect

• De discrepantie blijft behouden in ten minste drie uitgelijnde steekproefvensters tijdens een periode van lage schrijf- of verwijderactiviteit.
• Er is geen convergentietrend zichtbaar ondanks herhaalde steekproeven.
• Gerapporteerde waarden leiden tot onjuiste operationele beslissingen, zoals het vertraagd activeren van automatische schaalaanpassing of het falen bij het afdwingen van quota.

Wat moet ik opnemen in een ondersteuningsaanvraag?

Neem de volgende informatie op in uw ondersteuningsaanvraag:

• UTC-tijdstempels voor elke portal en API-voorbeeld.
• Onbewerkte JSON-antwoorden van GET Service Statistics en GET Index Statistics.
• Geschatte opname, update en verwijdervolume tijdens de observatieperiode.
• Beschrijving van de operationele impact, zoals een schaalvertraging, quotumblok of onjuiste capaciteitsrapportage.

Verwante inhoud

• Azure AI Zoeken monitoren
• Grootte en limieten van vectorindex
• Servicelimieten in Azure AI Zoeken
• Documenten verwijderen in een zoekindex