Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Note
Azure AI-sökning är tillgängligt via Azure-portalen, REST-API:er och Azure-SDK:er. Den ligger också till grund för Foundry IQ, det hanterade kunskapsskiktet som omvandlar företagsinnehåll till återanvändbara, behörighetsmedvetna kunskapsbaser för agenter i Microsoft Foundry-portalen.
Den här artikeln besvarar vanliga frågor om lagringsmått som verkar inkonsekventa i Azure-portalen, REST-API:er och Azure SDK:er.
Lagringsvärden i Azure AI-sökning samlas in regelbundet och återspeglar kanske inte realtidstillståndet. Därför förväntas kortsiktiga avvikelser i de flesta scenarier.
Bakgrund om hur mått samlas in och rapporteras finns i Övervaka Azure AI-sökning.
Varför ändras inte lagringen omedelbart när jag tar bort eller uppdaterar dokument?
När du tar bort dokument bekräftar Azure AI-sökning borttagningen omedelbart, men fysisk lagringsåtertagning sker genom bakgrundssammanslagningsåtgärder. Det underliggande dokumentet markeras som borttaget och utelämnas under efterföljande sökfrågor. När nya dokument indexeras och det interna indexet växer rensar systemet borttagna dokument och återtar resurserna. Det innebär att du sannolikt kommer att se en fördröjning mellan att ta bort dokument och de underliggande resurser som frigörs.
Dokumentuppdateringar har en liknande effekt på lagringen. Eftersom dokument inte kan ändras är en uppdatering internt en borttagnings- och infogningsåtgärd: den gamla versionen markeras som borttagen och en ny version infogas. Tills bakgrundssammanslagningsåtgärder rensar den gamla versionen kan du observera att lagringen ökar tillfälligt i stället för att förbli densamma.
Dessa sammanslagningsåtgärder slutförs vanligtvis inom 24 till 72 timmar, beroende på mängden belastning på tjänsten. Om du är nära prisnivåns lagringsgräns tar du hänsyn till den här tillfälliga ökningen när du planerar storskaliga uppdateringar eller dokumentbyten.
Mer information finns i Ta bort dokument i ett sökindex och Overhead från att ta bort eller uppdatera dokument i indexet.
Varför skiljer sig portal- och API-värden åt vid samma tidpunkt?
Azure-portalen och REST-API:erna kan rapportera olika värden eftersom de har olika uppdateringstakt. Specifikt:
- Fliken Användning på portalen Översiktssida uppdateras regelbundet, vanligtvis med några minuters mellanrum.
-
GET Service Statistics returnerar räknare på tjänstnivå, inklusive
storageSize,vectorIndexSizeochdocumentCount. - GET Index Statistics returnerar indexspecifika räknare.
Statistik på tjänstnivå och indexnivå samlas in oberoende och med olika intervall. En ögonblicksbild från en yta kanske inte överensstämmer med en ögonblicksbild från den andra om de inte avbildas samtidigt. Det här beteendet är normalt och indikerar inte någon defekt.
Mer information om övervakningsytor finns i Övervaka Azure AI-sökning.
Varför är ett ombyggt index större än ett äldre index med liknande innehåll?
Ett återskapat index kan tillfälligt visa en annan lagringsprofil eftersom bakgrundssammanslagningsåtgärder inte har rensat de gamla dokumentversionerna. Beroende på tjänstbelastning tar dessa sammanslagningar vanligtvis 24 till 72 timmar. Under den här perioden kan lagringen verka större än förväntat, vilket är särskilt viktigt att tänka på om du är nära prisnivåns lagringsgräns. Planera stora ombyggnads- eller migreringsåtgärder under perioder med lägre indexeringsaktivitet och övervaka lagringsmått tills sammanslagningar har slutförts.
Även när sammanslagningsåtgärderna har slutförts kan den slutliga storleken på ett återskapat index skilja sig något från originalet. Indexlagringsstorleken är icke-terministisk och flera faktorer påverkar resultatet:
- Schemaändringar, till exempel att lägga till fält, analysverktyg eller vektorkonfigurationer.
- Inmatnings- och uppdateringsmönster som påverkar förhållandet för borttagna dokument.
- Inställningar för vektoroptimering, till exempel kvantisering eller alternativ för lagringsminskning.
Mer information om faktorer som påverkar storleken finns i Vektorindexstorlek och -gränser och Tjänstgränser i Azure AI-sökning.
Varför matchar inte den totala lagringen vektorindexstorleken?
storageSize och vectorIndexSize mäter olika saker:
-
storageSizeär det totala diskavtrycket för ett index, inklusive innehåll för alla datatyper, till exempel text, metadata och vektorer. -
vectorIndexSizeär en gräns för storleken på ett vektorindex som läses in i minnet. Vektorfält som använder den fullständiga KNN-algoritmen förbrukar inte vektorindexkvot och rapporterar noll förvectorIndexSize. Mer information finns i Storlek och gränser för vektorindex.
På disken kan det totala lagringsutrymmet som förbrukas av vektorer vara större än storleken på minnesinternt vektorindex eftersom Azure AI-sökning lagrar flera kopior av vektorfält för olika ändamål. Information om vad dessa kopior är och hur du minskar diskförbrukningen finns i Eliminera valfria vektorinstanser från lagring.
Hur ska jag jämföra mått korrekt?
Ta reda på om en avvikelse är verklig eller en tidsartefakt genom att samla in värden från samma yta inom ett konsekvent UTC-tidsfönster:
- Anropa GET Service Statistics och GET Index Statistics inom samma femminutersfönster.
- Upprepa sampling på en fast takt, till exempel var 20:e till 30:e minut.
- Jämför minst tre fönster i följd innan du drar slutsatsen att värdena inte konvergerar.
- Utvärdera
storageSizeseparat frånvectorIndexSizeeftersom de spårar olika fysiska strukturer.
När förväntas en avvikelse jämfört med en faktisk defekt?
De flesta avvikelser förväntas och löses utan åtgärder. Om defektkriterierna uppfylls öppnar du en supportbegäran med de bevis som beskrivs i nästa avsnitt.
Förväntad divergering
- Du har nyligen utfört tung indexering, uppdateringar eller borttagningar och värden konvergerar fortfarande.
- Portal- och API-värden skiljer sig åt, men klyftan minskar mellan upprepade exempel.
-
storageSizeochvectorIndexSizematchar inte, vilket är avsiktligt eftersom de mäter olika saker.
Möjlig defekt
- Avvikelsen kvarstår i minst tre justerade samplingsfönster under en period med låg skriv- eller borttagningsaktivitet.
- Ingen konvergenstrend är synlig trots upprepad sampling.
- Rapporterade värden leder till felaktiga driftsbeslut, till exempel fördröjda autoskalningsutlösare eller kvottillämpningsfel.
Vad ska jag inkludera i en supportbegäran?
Inkludera följande information i din supportbegäran:
- UTC-tidsstämplar för varje portal och API-exempel.
- Råa JSON-svar från GET-tjänststatistik och GET-indexstatistik.
- Ungefärliga volymer av inmatning, uppdatering och borttagning av data under observationsperioden.
- Beskrivning av driftpåverkan, till exempel en skalningsfördröjning, kvotblock eller felaktig kapacitetsrapportering.