Tárolási és metrikaeltérésekkel kapcsolatos hibák elhárítása az Azure AI Keresésben

Ez a cikk az Azure Portalon, a REST API-kban és az Azure SDK-kban inkonzisztensnek tűnő tárolási metrikákkal kapcsolatos gyakori kérdésekre ad választ.

Az Azure AI Keresés tárolási értékeit rendszeres időközönként gyűjtjük, és előfordulhat, hogy nem tükrözik a valós idejű állapotot. Ezért a legtöbb forgatókönyvben rövid távú eltérések várhatók.

A metrikák gyűjtésének és jelentésének hátterét az Azure AI Keresés monitorozása című témakörben tekintheti meg.

Miért nem változik meg azonnal a tárterület a dokumentumok törlésekor vagy frissítésekor?

Dokumentumok törlésekor Azure AI Keresés azonnal nyugtázza a törlést, de a fizikai tároló helyrehozása háttéregyesítési műveletekkel történik. A mögöttes dokumentumot a rendszer töröltként jelöli meg, és a későbbi lekérdezések során kihagyja. Az új dokumentumok indexelése és a belső index növekedésével a rendszer megtisztítja a törölt dokumentumokat, és visszanyeri az erőforrásokat. Ez azt jelenti, hogy valószínűleg késés tapasztalható a dokumentumok törlése és a felszabadított mögöttes erőforrások között.

A dokumentumfrissítések hasonló hatással vannak a tárolásra. Mivel a dokumentumok nem módosíthatók, a frissítés belsőleg törlési és beszúrási művelet: a régi verzió törölve van, és egy új verzió lesz beszúrva. Amíg a háttéregyesítési műveletek nem törlik a régi verziót, megfigyelheti, hogy a tárterület átmenetileg nő, nem pedig ugyanaz marad.

Ezek az egyesítési műveletek általában 24–72 órán belül befejeződnek a szolgáltatás terhelésétől függően. Ha közel van a tarifacsomag tárolási korlátjához, vegye figyelembe ezt az ideiglenes növekedést, amikor nagy léptékű frissítéseket vagy dokumentumcseréket tervez.

További információ: Dokumentumok törlése keresési indexben , és az indexen belüli dokumentumok törlésével vagy frissítésével kapcsolatos többletterhelés.

Miért különböznek a portál- és API-értékek egy időben?

Az Azure Portal és a REST API-k eltérő értékeket jelenthetnek, mivel különböző frissítési gyakoriságokkal rendelkeznek. Ezek konkrétan a következők:

• A portál ÁttekintéslapJának Használat lapja rendszeresen, általában néhány percenként frissül.
• GET szolgáltatásstatisztika szolgáltatásszintű számlálókat ad vissza, beleértve storageSize, vectorIndexSize, és documentCount.
• A GET indexstatisztika indexenkénti számlálókat ad vissza.

A szolgáltatásszintű és az indexszintű statisztikákat egymástól függetlenül és különböző időközönként gyűjtjük. Előfordulhat, hogy az egyik felületről származó pillanatkép nem egyezik a másik pillanatképével, ha azokat nem rögzítették egyszerre. Ez a viselkedés normális, és nem jelez hibát.

A monitorozási felületekről további információt az Azure AI Keresés monitorozása című témakörben talál.

Miért nagyobb egy újraépített index, mint egy hasonló tartalommal rendelkező régebbi index?

Előfordulhat, hogy egy újraépített index ideiglenesen egy másik tárolási profilt jelenít meg, mert a háttéregyesítési műveletek nem fejezték be a régi dokumentumverziók tisztítását. A szolgáltatás terhelésétől függően ezek az egyesítések általában 24–72 órát vesznek igénybe. Ebben az időszakban a tárterület a vártnál nagyobbnak tűnhet, ami különösen fontos, ha a tarifacsomag tárterületkorlátjának közelében van. Tervezze meg a nagy újraépítési vagy migrálási műveleteket alacsonyabb indexelési tevékenység időszakában, és figyelje a tárolási metrikákat, amíg az egyesítések befejeződnek.

Az újraépített index végső mérete az egyesítési műveletek befejezése után is kissé eltérhet az eredetitől. Az indextároló mérete nem meghatározható, és számos tényező befolyásolja az eredményt:

• Sémamódosítások, például mezők, elemzők vagy vektorkonfigurációk hozzáadása.
• A törölt dokumentumok arányát befolyásoló betöltési és frissítési minták.
• Vektoroptimalizálási beállítások, például kvantálási vagy tárolási csökkentési lehetőségek.

A méretet befolyásoló tényezőkről további információt az Azure AI Keresésvektorindexének méretével, korlátaival és szolgáltatási korlátaival kapcsolatban talál.

Miért nem egyezik meg a teljes tárterület a vektorindex méretének megfelelően?

storageSize és vectorIndexSize mérjük a különböző dolgokat:

• storageSize az index teljes lemezlábnyoma, beleértve az összes adattípus tartalmát, például a szöveget, a metaadatokat és a vektorokat.
• vectorIndexSize a memóriába betöltött vektorindex méretének korlátja. A teljes KNN-algoritmust használó vektormezők nem használnak vektorindexkvótát, és nullát jelent a vectorIndexSize esetében. További információ: Vektorindex mérete és korlátai.

Lemezen a vektorok által felhasznált teljes tárterület nagyobb lehet, mint a memóriabeli vektorindex mérete, mivel az Azure AI Keresés több vektormező-példányt tárol különböző célokra. További információ ezekről a másolatokról és a lemezhasználat csökkentéséről: A nem kötelező vektorpéldányok eltávolítása a tárolóból.

Hogyan hasonlítsam össze helyesen a metrikákat?

Annak megállapításához, hogy az eltérés valós-e vagy időzítési összetevő, rögzítse az azonos felületről származó értékeket egy konzisztens UTC-időablakon belül:

1. Hívja meg a GET szolgáltatásstatisztikát és a GET indexstatisztikát ugyanabban az ötperces ablakban.
2. Ismételje meg a mintavételezést rögzített ütemben, például 20–30 percenként.
3. Hasonlítson össze legalább három egymást követő ablakot, mielőtt arra következtet, hogy az értékek nem konvergensek.
4. Értékelje ki a storageSize-t és a vectorIndexSize-t külön-külön, mert ezek eltérő fizikai struktúrákat követnek nyomon.

Mikor várható eltérés a tényleges hibával szemben?

A legtöbb eltérést beavatkozás nélkül várják és oldják meg. Ha a hibafeltételek teljesülnek, nyisson meg egy támogatási kérelmet a következő szakaszban ismertetett bizonyítékokkal.

Várható eltérés

• A közelmúltban nagy mértékű indexelést, frissítéseket vagy törléseket hajtott végre, és az értékek továbbra is konvergensek.
• A portál és az API értékei eltérőek, de a különbség az ismétlődő minták között szűkül.
• storageSize és vectorIndexSize nem egyeznek, ami azért van, mert különböző dolgokat mérnek.

Lehetséges hiba

• Az eltérés az alacsony írási vagy törlési tevékenység során legalább három igazított mintavételi ablakban is fennáll.
• Az ismételt mintavételezés ellenére nem látható konvergencia tendencia.
• A jelentett értékek helytelen üzemeltetési döntésekhez vezetnek, például késleltetett automatikus skálázási aktiváláshoz vagy kvótaérvényesítési hibákhoz.

Mit kell belefoglalnom egy támogatási kérelembe?

Adja meg a következő információkat a támogatási kérelemben:

• UTC időbélyegek minden portálhoz és API-mintához.
• Nyers JSON-válaszok a GET szolgáltatásstatisztikáiból és a GET indexstatisztikáiból.
• A megfigyelési időszak alatt hozzávetőlegesen az adatbeviteli, frissítési és törlési műveletek mennyisége.
• A működési hatás leírása, például skálázási késés, kvótablokk vagy helytelen kapacitásjelentés.

Kapcsolódó tartalom

• Az Azure AI Keresés monitorozása
• Vektorindex mérete és korlátai
• Szolgáltatási korlátok az Azure AI Keresésben
• Dokumentumok törlése keresési indexben