Kosten optimaliseren voor het serverloze prijsmodel in Azure AI Zoeken

Opmerking

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.

Azure AI Zoeken ondersteunt twee prijsmodellen, die elk zijn ontworpen voor verschillende workloadpatronen:

  • Gereserveerd: vaste prijsstelling gemeten in Search Units (SU's). U selecteert een servicelaag en u wordt per uur gefactureerd op basis van ingerichte eenheden.

  • Serverloos (preview): op verbruik gebaseerde prijzen gemeten op basis van rekeneenheden per uur (CU/hr) en per GB/maand voor geïndexeerde opslag.

Important

De serverloze ontwikkelaarslaag is momenteel beschikbaar als preview-versie. Deze preview wordt geleverd zonder service level agreement en wordt niet aanbevolen voor productieworkloads. Bepaalde functies worden mogelijk niet ondersteund of hebben mogelijk beperkte mogelijkheden. Zie Aanvullende gebruiksvoorwaarden voor Microsoft Azure Previews voor meer informatie.

De facturering voor de serverloze ontwikkelaarslaag begint op 13 september 2026. Kosten voor gebruik op of na die datum worden weergegeven op uw Azure factuur. Er worden vóór 13 september 2026 geen kosten in rekening gebracht voor gebruik. Serverless Developer is een betaald abonnement zodra de facturering start. De serverloze ontwikkelaarslaag biedt geen ondersteuning voor migratie naar of van andere prijscategorieën en sommige functies die beschikbaar zijn in andere lagen, worden niet ondersteund tijdens openbare preview. Servicelimieten, ondersteunde functies en prijsgegevens kunnen vóór algemene beschikbaarheid veranderen.

Tijdens de preview wordt het serverloze prijsmodel alleen ondersteund in specifieke regio's.

Zie Een prijsmodel en servicelaag kiezen voor meer informatie over prijsmodel- en servicelaagverschillen.

Hoe de kosten worden bepaald in het serverloze model

Het Dedicated- en Serverless-prijsmodel verrekenen werk in de zoekservice op verschillende manieren. Toegewezen services voeren query's, indexering en resultaatverwerking uit op ingerichte capaciteit die u al hebt aangeschaft. Serverloze services meten de reken-, geheugen- en schijf-I/O die deze bewerkingen gebruiken en converteren naar rekeneenheden (RU's). Als gevolg hiervan is prestatieoptimalisatie rechtstreeks van invloed op serverloze kosten.

Serverloze kosten zijn gekoppeld aan de uitvoering van workloads:

  • Query's en indexering verbruiken rekenkracht, gemeten in rekeneenheden per uur (CU/h).
  • Actieve indexen verbruiken rekenkracht op basis van hun resourcegebruik en hoe lang ze actief blijven.
  • Een index blijft 10 minuten na de laatste query of indexeringsaanvraag actief voordat deze inactief wordt.
  • Inactieve indexen hebben geen minimale of gereserveerde rekenkosten. Het rekengebruik voor inactieve indexen wordt geschaald naar nul. Er zijn geen minimale rekenkosten wanneer een index inactief is.
  • Opslag wordt afzonderlijk gefactureerd op basis van de indexgrootte op schijf en gaat door of een index al dan niet wordt gebruikt.
  • Agentische retrieval verbruikt rekenkracht voor zoekquery's en orkestratie die binnen de zoekservice worden uitgevoerd.

Opslagkosten worden alleen gestopt wanneer u de index verwijdert.

Hoe de indexgrootte van invloed is op het rekengebruik

Terwijl een index actief is, evalueert Azure AI Zoeken twee eindige resources om het rekengebruik te bepalen:

  • Totale indexgrootte: de totale ruimte die de index in beslag neemt op schijf, inclusief tekst, metagegevens en vectoren.
  • Grootte van vectorindex: het geheugen dat door de vectorindex wordt gebruikt. Geheugen vergt meer resources dan schijfruimte, dus de grootte van de vectorindex krijgt een hoger gewicht wanneer deze wordt omgezet naar CU’s.

Azure AI Zoeken voegt de twee resulterende CU-bedragen niet samen. Het rekengebruik is gebaseerd op het bedrag dat hoger is. De grootte van de vectorindex kan bijvoorbeeld het rekengebruik bepalen, zelfs wanneer de totale indexgrootte op schijf relatief klein is.

Als u het rekengebruik van de actieve index wilt verminderen, identificeert u welke resource het hogere CU-bedrag produceert. Verminder vervolgens de totale indexgrootte, vectorindexgrootte of beide. Geïndexeerde opslag blijft afzonderlijk per GB/maand in rekening gebracht.

Het serverloze prijsmodel is het meest rendabel voor workloads met variabele, onregelmatige of onvoorspelbare verkeer, waarbij ingerichte capaciteit onderbenut wordt.

Important

De kosten voor serverloze CU’s dekken werkzaamheden die binnen de zoekservice worden uitgevoerd, waaronder query’s, indexering, resultaatverwerking en agentische retrieval-orkestratie. Modeloproepen en andere werkzaamheden die buiten de zoekservice worden uitgevoerd, blijven hun bestaande factureringsmeters gebruiken. Voorbeelden hiervan zijn semantische classificatie, rewriting van agentische query's, extractie van afbeeldingen en het uitvoeren van vaardigheden.

Meer informatie over rekeneenheden (RU's)

Een Compute Unit (CU) vertegenwoordigt de gemeten systeemresources die nodig zijn voor het uitvoeren van zoek- en indexeringsbewerkingen in het serverloze model. CU-kosten worden voornamelijk bepaald door CPU-, geheugen- en IO-gebruik, en in mindere mate door de indexgrootte en de payloadgrootte van documenten, waarbij het gebruik wordt gefactureerd als Compute Unit per uur (CU/h).

Rekenkosten schalen mee met:

  • Querycomplexiteit
  • Indexgrootte (GB) en structuur
  • Documentgrootte (KB)
  • Aantal velden en opgehaalde resultaten

Verschillende bewerkingen hebben verschillende kostenprofielen:

  • Opzoeken: Lage kosten. Het ophalen van één document op basis van zijn ID is de meest efficiënte bewerking.
  • Trefwoorden zoeken: lage kosten. Zoeken in tekst maakt gebruik van omgekeerde indexen, die zijn geoptimaliseerd voor snelheid en laag rekengebruik.
  • Vectordoorzoeking: Hoge kosten. Vectorquery's zijn rekenintensief omdat ze similariteitsberekeningen over hoogdimensionale embeddings vereisen. Vergeleken met zoekopdrachten op trefwoorden verbruiken ze aanzienlijk meer rekenkracht.
  • Hybride zoeken: combineert de kosten van trefwoorden en vectorzoekopdrachten, terwijl beide pijplijnen voor elke query worden uitgevoerd, plus een kleine extra overhead voor Wederzijdse Rank Fusion (RRF) om resultaten samen te voegen.

Rekengebruik bewaken

Door rekenverbruik te bewaken, kunt u dure bewerkingen identificeren, querypatronen optimaliseren en kosten schatten. De Compute Unit (CU)-kosten van elk verzoek worden in de x-ms-azs-compute-units-consumed HTTP-antwoordheader geretourneerd als een floating-pointgetal. Gebruik deze header om dure bewerkingen te identificeren en querypatronen te optimaliseren. U kunt de CU-kosten van elke aanvraag bijhouden door de HTTP-antwoordheaders en bewerkingsevenementen in Azure Monitor te controleren. Zie Monitor Azure AI Zoeken voor meer informatie over de typen bewakingsgegevens die beschikbaar zijn en methoden voor het analyseren van die gegevens.

  • Koptekst: x-ms-azs-compute-units-consumed: <value>
  • Waarde: Een drijvendekommagetal dat de verbruikte CA's vertegenwoordigt.

Example:

Status: 200 OK
Content-Type: application/json
x-ms-azs-compute-units-consumed: 12.45

In dit voorbeeld verbruikte de aanvraag 12,45 rekeneenheden. U kunt deze waarde gebruiken om bewerkingen met hoge kosten te identificeren en de relatieve kosten van verschillende querypatronen te vergelijken.

Als u het historische rekenverbruik voor een serverloze zoekservice wilt bekijken, gebruikt u de Azure Monitor metrische gegevens in de Azure-portal:

  1. Navigeer naar uw zoekservice.
  2. Selecteer Metrische gegevens.
  3. Selecteer + Metrische waarde toevoegen.
  4. Selecteer het gebruik van rekeneenheden in de lijst met metrische gegevens.
  5. Gebruik de grafiek om gebruikstrends te analyseren en perioden van verhoogd rekenverbruik te identificeren.

Door het aggregaatgebruik te bewaken, krijgt u inzicht in de totale servicekosten en kunt u workloads identificeren die de meeste rekenresources verbruiken. Zie Referentie voor bewakingsgegevens voor beschrijvingen van beschikbare bewakingsgegevens. U kunt Azure Monitor logboeken gebruiken om het cumulatieve CU-gebruik in de loop van de tijd bij te houden en deze te correleren met wijzigingen in het queryvolume en de workload.

Schermopname van het bewakingsdashboard voor metrische gegevens voor serverloze rekeneenheden in de Azure Portal.

Waarschuwingen configureren voor rekengebruik

U kunt een waarschuwingsregel maken die moet worden gewaarschuwd wanneer het rekenverbruik een opgegeven drempelwaarde bereikt in de Azure-portal.

  1. Ga naar Waarschuwingen in uw zoekservice.
  2. Selecteer + Waarschuwingsregel maken.
  3. Kies onder Voorwaardehet gebruik van rekeneenheden als signaal.
  4. Definieer de waarschuwingslogica. Trigger bijvoorbeeld wanneer het totale gebruik groter is dan een opgegeven waarde.
  5. Configureer acties, zoals e-mail, sms of webhookmeldingen.
  6. Voer de resterende stappen uit en selecteer Beoordelen en maken.

Met waarschuwingen kunt u proactief reageren op onverwachte gebruikspieken en kosten beheren.

Schermopname van het maken van een waarschuwingsregel in de Azure Portal.

Kosten voor serverloze toepassingen schatten

De Azure prijscalculator en op SU's gebaseerde richtlijnen voor capaciteitsplanning zijn niet van toepassing op services die gebruikmaken van het serverloze prijsmodel.

Om de serverless-kosten te schatten:

  1. Representatieve voorbeeldgegevens indexeren.
  2. Voer typische indexerings- en queryworkloads uit.
  3. Noteer de x-ms-azs-compute-units-consumed geretourneerde waarde voor elke bewerking.
  4. Gebruik Azure Monitor metrische gegevens om het geaggregeerde gebruik in de loop van de tijd te meten.
  5. Extrapoleer kosten op basis van verwacht productieverkeer.

Gebruik het tabblad Schaal en kosten in de Azure-portal om uw huidige gebruik te bekijken en kosten te schatten.

Omdat dezelfde aanvraag op basis van dezelfde gegevens in het algemeen vergelijkbaar rekenverbruik produceert, kunnen representatieve workloads een betrouwbare basis bieden voor kostenramingen.

Serverloos gebruik wordt continu gemeten en geaggregeerd voor facturering. Het rekenverbruik wordt gedurende elke minuut bijgehouden en wordt alleen verzonden wanneer rekenresources worden gebruikt.

Bij het schatten van kosten gebruikt u kostenwaarden voor aanvragen om inzicht te hebben in de kosten van afzonderlijke bewerkingen en Azure Monitor metrische gegevens om inzicht te verkrijgen in de algehele gebruikspatronen van de service.

Gebruik beide gegevensbronnen samen om inzicht te verkrijgen in de kosten: kostengegevens per aanvraag helpen u bij het evalueren van afzonderlijke bewerkingen, terwijl Azure Monitor metrische gegevens u inzicht geven in het geaggregeerde serviceverbruik in de loop van de tijd. Voor een volledige kostenafbeelding moet u ook rekening houden met functies die afzonderlijk van rekeneenheden worden gefactureerd.

Facturering is gebaseerd op geaggregeerd rekengebruik in plaats van afzonderlijke aanvragen. Het gebruik wordt gemeten in intervallen van één minuut en afgerond op de dichtstbijzijnde 0,25 CU per minuut. Deze gebruiksintervallen van één minuut worden gedurende een uur verzameld om het factureerbare CU/uurbedrag te bepalen. Intern wordt het gebruik geaggregeerd van milli-compute-eenheden (mCU) naar compute-eenheden (CU) en omgezet in het gebruik per uur dat voor facturering wordt gerapporteerd.

Verschillende bewerkingen verbruiken verschillende hoeveelheden rekenkracht. In het algemeen:

  • Trefwoordzoekopdrachten gebruiken doorgaans de minste rekenresources.
  • Vectorzoekopdrachten gebruiken doorgaans meer rekenresources dan trefwoordzoekopdrachten.
  • Hybride zoekopdrachten combineren de uitvoering van trefwoorden en vectorzoekopdrachten, zodat ze doorgaans meer rekenresources gebruiken dan een van beide technieken.

Het werkelijke rekenverbruik is afhankelijk van factoren zoals querycomplexiteit, indexgrootte, gegevensvolume, vectorconfiguratie en het aantal geretourneerde resultaten. Het bewaken van aanvraagkosten en statistische gebruiksgegevens kan u helpen bij het identificeren van optimalisatiekansen en het beter voorspellen van de productiekosten.

Rekenkosten verlagen door middel van optimalisatie

Efficiënte query's en een goed indexontwerp verminderen het rekenverbruik en verlagen de kosten.

Uw schema optimaliseren

Uw indexschema bepaalt de reken- en opslagkosten volgens de basislijn:

  • Veldkenmerken beperken: schakel indien nodig alleen kenmerken in (doorzoekbaar, filterbaar, facetable, sorteerbaar). Elk kenmerk verhoogt de indexgrootte en indexeringskosten.
  • Complexe typen plat maken: geneste JSON-structuren waar mogelijk toewijzen aan eenvoudige velden of verzamelingen.
  • Stel retrievable=false in voor velden die alleen worden gebruikt om te filteren of te sorteren: Als een veld wordt gebruikt om te filteren of te sorteren, maar niet hoeft te worden geretourneerd in de resultaten, houd het dan geïndexeerd en stel retrievable=false in om de opslag op schijf en de opslagkosten per GB per maand te verlagen.
  • Gebruik indien mogelijk opvraagbare velden: bijvoorbeeld velden die alleen worden gebruikt voor weergave (zoals afbeeldings-URL's) mogen niet doorzoekbaar zijn.
  • Vectordimensies verminderen: hogere dimensionale vectoren verhogen de opslag- en querykosten. Gebruik, indien van toepassing, kleinere insluitingsmodellen of kwantisatie.
  • Minimaliseer de nettolading van het document voordat u indexeert: grotere documenten kosten meer om te indexeren. Verwijder overbodige velden, trim lange tekst en strip HTML voordat u documenten naar de index verzendt.

Indexeringsaanvragen optimaliseren

Hoe u gegevens naar de index verzendt, is van invloed op zowel kosten als doorvoer:

  • Gebruik indien mogelijk grotere batches: Batchindexering vermindert overhead per aanvraag door netwerk- en verwerkingskosten af te schrijven voor meer documenten. In het algemeen zijn batches van maximaal ~1000 documenten of ~16 MB cu-efficiënt dan veel kleine aanvragen. De optimale batchgrootte is echter afhankelijk van uw workload. Test om de doorvoer, latentie en betrouwbaarheid te verdelen.

  • Alleen nieuwe of gewijzigde gegevens indexeren: vermijd indien mogelijk volledige herindexering. Het verzenden van alleen toevoegingen en updates vermindert het aantal verwerkte documenten, het verlagen van de rekenkosten en het verbeteren van de opnamesnelheid.

  • Sla afbeeldingsextractie over, tenzij u deze nodig hebt: bij het extraheren van afbeeldingen wordt extra verwerkingswerk toegevoegd en kan dit een afzonderlijk kostenstuurprogramma worden. Schakel deze functie alleen in voor documenten of werkstromen die daadwerkelijk afbeeldingsinhoud nodig hebben.

  • Rekening houden met de groei van de indexgrootte: maak waar mogelijk kleinere indexen. Naarmate een index groeit, nemen de indexeringskosten toe omdat er meer gegevens moeten worden opgeslagen en onderhouden, en bewerkingen vereisen meer rekenkracht. Voor zeer grote gegevenssets kunt u overwegen om gegevens over meerdere indexen te partitioneren om de prestaties en kosten te beheren. Hoewel de kosten stijgen met indexgrootte, is de toename sublijnig. Grotere indexen kosten meer per bewerking, maar niet proportioneel meer.

Zie Tips voor betere prestaties in Azure AI Zoeken voor meer richtlijnen.

Indexeerbewerkingen optimaliseren

Het rekengebruik van een serverloze indexeerfunctie is afhankelijk van het werk dat tijdens elke uitvoering van de indexeerfunctie wordt uitgevoerd. Gebruik voor rijgeoriënteerde bronnen het aantal documenten dat is verwerkt als indicator van het workloadvolume. Voor op bestanden gebaseerde bronnen, zoals Azure Blob Storage en Azure Data Lake Storage Gen2, controleert u de hoeveelheid verwerkte brongegevens. Het werkelijke rekengebruik is ook afhankelijk van nettoladingen van documenten, indexstructuur, verrijking en andere verwerkingen die tijdens de uitvoering worden uitgevoerd.

Het rekengebruik van de indexeerfunctie verminderen:

  • Wijzigingsdetectie en incrementele indexering gebruiken: alleen nieuwe of gewijzigde gegevens verwerken in plaats van de volledige gegevensbron herhaaldelijk te indexeren.

  • Indexeerschema's met de juiste grootte: kies een schema dat voldoet aan de vereisten voor het vernieuwen van gegevens. Gebruik telemetrie van rekeneenheden om het effect van de planningsfrequentie te evalueren.

  • Verminder onnodige documentinhoud: verwijder inhoud die niet hoeft te worden geïndexeerd en sluit bestanden of bestandstypen uit die niet vereist zijn.

  • Beperk verrijkingsvaardigheden zorgvuldig: voer vaardigheden alleen uit op velden en documenten waarvoor verrijking nodig is, en vermijd het genereren van uitvoer die verderop in het proces niet wordt gebruikt. Factureerbare vaardigheden kunnen afzonderlijke transactiekosten in rekening brengen.

  • Mislukte en herhaalde uitvoeringen bewaken: een indexeerfunctie kan rekenkracht verbruiken voor werk dat is voltooid voordat deze mislukt. Bekijk de uitvoeringsgeschiedenis en het gebruik van rekeneenheden om terugkerende fouten en patronen voor opnieuw proberen te identificeren.

Uw query's optimaliseren

Het ontwerp van query’s is een belangrijke drijfveer voor de variabele kosten:

  • Gebruik $select om de geretourneerde velden te beperken: Hierdoor worden de payloadgrootte en de voor serialisatie benodigde rekenkracht verminderd.

    GET /docs?search=test&$select=id,title,url

  • Gebruik searchFields dit om te beperken waar tekst wordt doorzocht: Beperk querytijd die overeenkomt met de velden die voor het scenario van belang zijn. Elk extra doorzoekbaar veld verhoogt het querywerk en kan CU/h verhogen.

  • Geef de voorkeur aan exacte overeenkomsten of eenvoudige zoekwoordquery's: Fuzzyquery's, jokertekenquery's, regexquery's en prefixquery's kunnen leiden tot brede indexscans en aanzienlijk meer CU/h verbruiken. Gebruik deze alleen wanneer u gedeeltelijk overeenkomend gedrag nodig hebt en waar mogelijk exacte overeenkomsten of eenvoudigere trefwoordquery's kiest.

  • Zoekacties gebruiken in plaats van zoekopdrachten indien mogelijk: het ophalen van een document op id is efficiënter dan het uitvoeren van een zoekquery. Als u de document-id kent, gebruik dan een opzoekbewerking in plaats van een zoekopdracht. Zoekacties zijn efficiënter omdat ze een document rechtstreeks op sleutel ophalen, terwijl zoekquery's de volledige querypijplijn aanroepen (parseren, indexkruising, scoren en rangschikken), waardoor de rekenkosten toenemen.

  • Vermijd diepe paging ($skip): grote $skip waarden verhogen de berekening omdat de engine alle voorgaande resultaten moet verwerken en rangschikken (bijvoorbeeld $skip=5000 vereist dat ten minste 5.000 documenten worden beoordeeld die niet worden geretourneerd). Dit verspilt compute-eenheden (CU's) en verhoogt de kosten. Gebruik in plaats daarvan filters om de resultaten te beperken en het aantal te beperken dat wordt geretourneerd met $top. De juiste grootte $top aanpassen aan de weergave van uw gebruikersinterface. Zo zijn $top=10 bijvoorbeeld goedkoper dan $top=50, omdat er minder resultaten worden beoordeeld en geretourneerd. Vraag alleen zoveel resultaten aan als uw toepassing nodig heeft en vermijd patronen waarvoor de engine grote aantallen ongebruikte resultaten moet verwerken.

  • Minimaliseer het aantal facetten en het facetbereik: vraag alleen de facetten aan die worden weergegeven in uw gebruikersinterface en behoud elke facetwaarde count zo laag als praktisch. Facetten vereisen aggregaties voor elke query, en hoge aantallen verhogen de rekenkosten.

  • Gebruiken search.in voor filteren: Wanneer u filtert op een lijst met id's of waarden, gebruikt u de search.in functie in plaats van meerdere or voorwaarden (bijvoorbeeld id eq '1' or id eq '2'). Deze aanpak is efficiënter en vermindert de rekenoverhead. U moet ook voorkomen dat velden met een hoge kardinaliteit (velden met veel unieke waarden, zoals unieke id's of vrijetekstbeschrijvingen) als filterbaar of facetteerbaar worden gemarkeerd, tenzij dit nodig is, omdat dit de indexgrootte en querykosten verhoogt.

Uw beheeraanvragen optimaliseren

Naast query- en indexeringsbewerkingen bevat Azure AI Zoeken beheerbewerkingen op object- en serviceniveau (zoals het ophalen van indexschema's of servicestatistieken). Deze aanvragen hebben een vaste kosten per aanvraag. Hoewel elke aanvraag goedkoop is, kunnen herhaalde of onnodige aanroepen zich in de loop van de tijd verzamelen en het totale rekengebruik verhogen.

  • Vermijd overmatige beheeraanvragen: Cachemetagegevens, zoals indexschema's, aan de clientzijde in plaats van deze herhaaldelijk op te halen. Als u bijvoorbeeld het indexschema ophaalt voordat elke schrijfbewerking onnodige kosten introduceert. In het serverloze model verhoogt dit patroon rechtstreeks de rekenkosten, terwijl in toegewezen services de impact vaak wordt verborgen door vaste facturering per uur.

Vectorkosten optimaliseren

Vectorworkloads zijn doorgaans het hoogste kostenonderdeel bij het zoeken naar het serverloze prijsmodel, omdat ze van invloed zijn op zowel rekeneenheden (query's en indexering) als opslag (vectorgrootte op schijf). Om de kosten te verlagen, optimaliseert u zowel hoe vectoren worden opgeslagen als hoe ze worden opgevraagd.

Vectoropslag en -schema optimaliseren

Vectorvelden kunnen de indexgrootte en indexeringskosten aanzienlijk verhogen. Gebruik de volgende technieken om de opslagoverhead te verminderen:

  • Gebruik compressie om de vectorgrootte te verminderen: kwantisatie toepassen om de opslagvoetafdruk te verminderen met minimale relevantieimpact. Scalaire kwantisatie kan bijvoorbeeld vectoropslag verminderen met maximaal 4× met minimale invloed op de zoekkwaliteit.

  • Schakel opslag voor vectoren uit wanneer dat niet nodig is: Stel opgeslagen=onwaar in vectorvelden in als u alleen vectoren nodig hebt voor zoeken, niet ophalen. Dit voorkomt dat de oorspronkelijke vectoren in de index worden opgeslagen, waardoor de opslagkosten worden verminderd zonder dat dit van invloed is op het querygedrag.

  • Gebruik indien mogelijk kleinere insluitingsdimensies: hogere dimensionale vectoren verhogen zowel de opslag- als de querykosten. Gebruik voor niet-kritieke workloads kleinere insluitingsmodellen (bijvoorbeeld 384 of 768 dimensies in plaats van 1536) om de kosten te verlagen.

De uitvoering van vectorquery's optimaliseren

Vectorquery's zijn rekenintensief omdat ze overeenkomstenberekeningen vereisen ten opzichte van hoogdimensionale gegevensstructuren.

  • Hybride zoekopdrachten selectief gebruiken: hybride query's voeren zowel trefwoorden als vector ophalen uit. Gebruik alleen wanneer dit nodig is voor relevantie.

  • maxTextRecallSize afstemmen op hybride query’s: Stel hybridSearch.maxTextRecallSize in om te bepalen hoeveel door BM25 gerangschikte tekstresultaten beschikbaar zijn voor Reciprocal Rank Fusion (RRF). De standaardwaarde is 1000 en het ondersteunde bereik is 1 tot en met 10.000. Als u de waarde verlaagt, kan het ophalen van tekst en het resultaatfusiewerk verminderen, waardoor het resourcegebruik en de latentie kunnen worden verminderd. Het kan echter relevante trefwoordresultaten uitsluiten, inclusief exacte termen, id's en acroniemen die vectorzoekopdrachten kunnen missen. Test representatieve query's en vergelijk relevantie, latentie en de x-ms-azs-compute-units-consumed antwoordheader voordat u een waarde selecteert. Beheer vectorkandidaten afzonderlijk door k in te stellen voor elke vectorquery.

  • Pas filters toe vóór vectorquery’s: beperk de verzameling kandidaten vóór het vectorzoeken om de hoeveelheid verwerkte gegevens te verminderen. Zie Hoe filteren werkt in vectorquery’s.

Kosten verlagen door het gebruik te minimaliseren

Het serverloze model brengt alleen kosten in rekening voor verbruikte resources. Wanneer er geen aanvragen zijn, neemt het rekengebruik dienovereenkomstig af.

Gebruikskosten minimaliseren:

  • Voer query's alleen uit wanneer dat nodig is.
  • Vermijd redundante of te frequente aanvragen.
  • Bewaak het gebruik en stem workloads af op basis van vraag.

Tip

Dezelfde query kan verschillende latentie- en CU-profielen hebben, afhankelijk van of de service warm of koud is. Na een periode zonder lees- of schrijfverkeer daalt het rekengebruik in het serverloze prijsmodel naar nul. De volgende aanvraag kan een hogere latentie hebben en meer CA's verbruiken terwijl gegevenspaden worden opgewarmd. Grotere indexen hebben over het algemeen meer tijd nodig om op te warmen dan kleinere indexen, dus koude-start-effecten zijn vaak meer merkbaar bij grotere services.

Opslagkosten optimaliseren

Opslag wordt gefactureerd per GB/maand op basis van de grootte van de schijfindex, die de onbewerkte gegevensgrootte kan overschrijden. Om opslagkosten te verlagen:

  • Verwijder ongebruikte indexen.
  • Opgeslagen velden minimaliseren.
  • Ontwerp schema’s en houd rekening met opslagoverhead.
  • Gebruik suggesties selectief omdat ze de opslaggrootte aanzienlijk kunnen vergroten.

Zie Optimaliseren voor vectoropslag en -verwerking voor vectorspecifieke technieken (compressie, pruning en opslaginstellingen).

Zie Tips voor betere prestaties in Azure AI Zoeken voor meer richtlijnen voor opslag- en queryprestaties.

  • Last updated on