Delen via

Gegevensplatform voor AI-workloads in Azure

  • Artikel

Een gegevensplatform is een geïntegreerde set technologieën die zijn ontworpen voor het beheren van workloadvereisten door brongegevens op te nemen en deze vervolgens te filteren, samen te stellen en voor te bereiden op verbruik.

Gegevens hebben verschillende kenmerken die zijn gebaseerd op het beoogde gebruik. We raden u ten zeerste aan de principes van een goed ontwerp voor gegevenspijplijnen te begrijpen voordat u de technologische mogelijkheden verkent die in dit artikel worden beschreven. Zie Het ontwerp van trainingsgegevens en het ontwerp van grondgegevens voor meer informatie.

Het platform voldoet ook aan de opslagbehoeften wanneer gegevens zich op bepaalde punten in de pijplijn bevinden. Als de werkbelasting complex is en grootschalige gegevens verwerkt, kunt u pijplijntaken verdelen over verschillende onderdelen. Voor eenvoudigere gebruiksvoorbeelden evalueert u of u de brongegevens in een archief kunt gebruiken dat deze gecombineerde mogelijkheden biedt.

Stel uzelf de volgende vragen, zodat u kunt voorkomen dat u een te complexe architectuur voor uw gegevensplatform ontwerpt. Het is altijd het beste om dingen eenvoudig te houden wanneer u dat kunt.

  • Kan uw toepassing de verwachte voorspellende kracht hebben door gegevens op te nemen uit één bron?
  • Biedt uw eerste keuze voor gegevensopslag mogelijkheden voor datawarehousing?
  • Zijn de brongegevens al geoptimaliseerd voor AI-zoekopdrachten?

Als u ja op deze vragen beantwoordt, kunt u uw architectuur vereenvoudigen door de toepassing rechtstreeks toegang te geven tot de gegevensbron. Deze aanpak elimineert de noodzaak voor onderdelen van big data-architectuur, zoals gegevensopname, integratie van analytische opslag en externe gegevensverwerking. Als de brondatabase de vereiste zoekopdrachten kan verwerken, kan de integratie van de zoekindexfunctie rechtstreeks in de brondatabase een praktische benadering zijn. Zorg ervoor dat de bron rendabel kan worden geschaald om aan nieuwe eisen te voldoen.

Azure Cosmos DB ondersteunt bijvoorbeeld vectorzoekopdrachten, zodat u mogelijk geen andere index nodig hebt. Een andere use case is het gebruik van leesreplica's als eindpunten voor zoekbewerkingen. Voor SQL-databases met leesreplica's kunnen directe zoekopdrachten naar deze replica's de prestaties optimaliseren. Profiteer van de ingebouwde mogelijkheden van de database om de architectuur zoveel mogelijk te vereenvoudigen.

Een gegevensplatformarchitectuur voor grootschalige workloads is complexer.

Het opnemen van gegevens uit meerdere gegevensbronnen en het organiseren van zoekopdrachten op verschillende platforms kan complex en inefficiënt worden. Bovendien hebt u nog steeds wat extract, transformatie en belasting (ETL) nodig; extraheren, laden en transformeren (ELT); of el-processen (extraheren en laden) om de gegevens in het gegevensarchief opnieuw vorm te geven. Het scenario wordt complexer omdat de gegevens meer verwerking vereisen. U moet veel onderdelen toevoegen aan de architectuur om de end-to-end-pijplijn te verwerken van opname tot het leveren van query's. Veel big data-technologieën zijn zeer gespecialiseerd en gebouwd om deze verwerkingstaken effectief te verwerken.

Een dergelijke technologie is de zoekindex. Het belangrijkste voordeel van het toevoegen van een afzonderlijke index is de mogelijkheid om query's efficiënt te beheren en grote hoeveelheden gegevens met een hoge doorvoer te verwerken. Deze functie offload AI-mogelijkheden van de oorspronkelijke gegevensbron, zodat de index zich kan richten op de hoofdfunctie, die query's verwerkt.

Kies een platform op basis van de specifieke functionaliteit en het doel en houd rekening met uw functionele en technische vereisten. Als uw architectuur zich ontwikkelt om complexe gebruiksvoorbeelden af te handelen, richt u zich op de volgende secties over geaggregeerde gegevensarchieven, het verwerken van pijplijnen en zoekindexen.

Aanbevelingen

Hier volgt een samenvatting van de aanbevelingen in dit artikel.

Aanbeveling Beschrijving
Bouw veilige, krachtige en rendabele gegevensarchieven. Een belangrijk onderdeel van uw gegevensplatform is een gegevensarchief dat gegevens uit meerdere bronnen samenvoegt en integratie met verschillende integratietaken toestaat. Dit helpt uw workload op schaal uit te voeren. Zorg ervoor dat u de verschillende functionele en niet-functionele vereisten van uw gegevensarchief bekijkt om een rendabele implementatie te garanderen.

▪ Overwegingen voor het opslaan van geaggregeerde gegevens
Volg de aanbevolen procedures voor gegevensopname en -verwerking. Gegevens van hoge kwaliteit helpen de betrouwbaarheid van uw workload en de eindgebruikerservaring te verbeteren. Houd rekening met de vereisten van uw workload en de belangrijkste aanbevolen procedures voor het bouwen van efficiënte opname- en gegevensovergangsprocessen die helpen bij het onderhouden van een balk met hoge kwaliteit.

▪ Overwegingen voor het verwerken van gegevens
Ontwerp betrouwbare en relevante zoekindexen. Streven naar een krachtige, schrijf-en-veel-gegevensopslag die efficiënt omgaat met impromptu- en fuzzy query's, waarbij relevante resultaten worden geleverd aan uw gebruikersbasis, zelfs wanneer query's niet nauwkeurig zijn.

▪ Overwegingen voor een zoekindex
Zorg ervoor dat functionele gegevensarchieven op schaal worden uitgevoerd. Afhankelijk van de functionele vereisten van uw workload moet u mogelijk functionele gegevensarchieven maken, bijvoorbeeld voor offlinedeductie. Het is belangrijk dat u gegevensarchieven met hun aangewezen functie in gedachten maakt en best practices toepast voor de functie.

▪ Overwegingen voor een functiearchief
▪ Overwegingen voor een offlinedeductiegegevensarchief

Overwegingen voor het opslaan van geaggregeerde gegevens

In AI-workloads worden gegevens verplaatst door verschillende fasen van opslag en verwerking met behulp van pijplijnen die de werkstroom tussen deze fasen organiseren. Een belangrijke fase is een gegevensarchief dat gegevens bevat die worden opgenomen en samengevoegd uit meerdere bronnen. U hebt deze opslag nodig om de verwerking uit te voeren totdat de gegevens een geschikte status hebben voor training of indexering. De primaire focus is om ervoor te zorgen dat de gegevens nauwkeurig de bron weerspiegelen.

Notitie

Een alternatieve benadering is om rechtstreeks toegang te krijgen tot gegevensbronnen. Deze aanpak kan echter leiden tot prestatieproblemen, omdat deze de bronsystemen mogelijk overbelast raakt met AI-functies. Er kunnen ook problemen zijn met gegevenstoegang. Om deze problemen te voorkomen, raden we u aan gegevens naar dit archief te kopiëren.

Het gegevensplatform voor dit archief moet voldoen aan de beveiligingsstandaarden die worden toegepast op gegevensbronnen, kostenefficiënt zijn en ondersteuning bieden voor integratie met ETL-, ELT- en EL-verwerkingstaken. Opties verschillen van basisopslag tot big data-technologieën op basis van gegevensvolume. Kies voordelige opslag waarmee u voldoende betrouwbaarheid en prestaties kunt bereiken.

In de volgende sectie vindt u richtlijnen over de mogelijkheden die u moet overwegen wanneer u een technologie voor gegevensopslag selecteert. Zie Pijplijnen voor gegevensverwerking voor meer informatie.

Functionele vereisten

  • Kan het platform verschillende gegevensindelingen verwerken?

    Het gegevensarchief moet verschillende gegevensindelingen kunnen opslaan en deze zo nodig transformeren naar andere indelingen.

    Stel dat uw opnamepijplijngegevens uit een relationele database en een Parquet-bestand gegevensbronnen, zodat deze zowel gestructureerde als semi-gestructureerde gegevens ondersteunt. U wilt relationele gegevens converteren naar Parquet-indeling in overeenstemming met de bijbehorende schemadefinities. Het gegevensplatform moet ingebouwde mogelijkheden hebben om die transformatie uit te voeren zonder dat u aangepaste code hoeft te schrijven.

  • Verwacht u dat u meerdere versies van de gegevens opslaat?

    Gegevenswaarden en schema's kunnen na verloop van tijd veranderen en het beheren van meerdere versies van de gegevens wordt belangrijk.

    Bronsystemen slaan doorgaans alleen huidige gegevens op, niet historische gegevens. Als het belangrijk is om historische gegevens te behouden, moet u mogelijk grote gegevenssets dupliceren uit bronsystemen. In dit geval kan versiebeheer de huidige gegevens van historische gegevens niet eenduidig maken.

    In sommige gevallen moet u mogelijk kopieën van gegevens onderhouden voor verschillende gebruiksvoorbeelden. Ter ondersteuning van dit scenario moet u mogelijk gegevens forken. Elke vork kan onafhankelijk muteren om de kwaliteit en bruikbaarheid ervan te verbeteren. Uw gegevensplatform moet de juiste versiebeheer van deze forks kunnen onderhouden.

    Uw gegevensplatform moet in staat zijn om in de loop van de tijd versies van gegevens op te slaan om historische context te bieden. Deze contetxt is nuttig voor het verwerken en trainen van AI-modellen, omdat het meerdere waarnemingen biedt in plaats van slechts één bepaald tijdstip.

  • Beschikt het platform over ingebouwde mogelijkheden voor gegevenslevenscyclusbeheer?

    DLM (Data Lifecycle Management) is een proces voor het beheren van gegevens van het maken tot het verwijderen ervan, met fasen zoals gegevensverzameling, opslag, gebruik, archivering en verwijdering.

    Zonder DLM kunnen gegevens onbeheerd groeien, wat vaak resulteert in meerdere kopieën terwijl deze door kwaliteitslagen worden verplaatst. Het gegevensplatform moet DLM-mogelijkheden hebben om niet-gebonden gegevensgroei te voorkomen.

    Houd rekening met dit scenario. De voorverwerkingsstap moet worden herhaald om de gegevens te verfijnen totdat deze een acceptabele kwaliteit voor trainingsdoeleinden bereikt. Uw gegevensplatform moet tussenliggende kopieën van de gegevens kunnen verwijderen.

    In sommige gevallen moet u mogelijk gegevens bewaren voor regelgevingscontroles. Het gegevensplatform moet koude opslagmogelijkheden hebben voor niet-vaak geopende gegevens, zodat u deze tegen lagere kosten kunt archiveren.

  • Biedt het platform ondersteuning voor functies voor gegevensbeheer?

    Controlebaarheid is een belangrijk aspect voor AI-workloads. Het gegevensarchief moet audittrails onderhouden waarmee gegevenstoegang kan worden bijgehouden, privacy kan worden gegarandeerd en de oorsprong van gegevens kan worden begrepen.

    Gebruik een functie voor gegevenswoordenlijst om metagegevens, gegevenstypen, doeleinden en herkomst te beheren. Deze functie is vooral belangrijk wanneer gegevens uit meerdere bronnen worden opgenomen.

  • Bent u van plan om training uit te voeren met productiegegevens?

    Er zijn twee benaderingen voor implementaties, modelimplementatie en code-implementatie. Bij modelimplementatie worden productiegegevens gebruikt in ontwikkeling, waarvoor strenge beveiligingsmaatregelen zijn vereist. In code-implementatie ziet het model geen productiegegevens totdat het in productie is. Hoewel code-implementatie beveiligingsproblemen in de ontwikkelomgeving vereenvoudigt, kunnen de rekenkosten worden verhoogd. Welke benadering u ook kiest, uw gegevensplatform moet afzonderlijke omgevingen ondersteunen voor ontwikkeling en productie.

  • Prioriteit geven aan handige functies ten opzichte van belangrijke functionele functies?

    Wanneer u een gegevensplatform kiest voor AI of machine learning, vertrouwt u niet alleen op de notebookmogelijkheden. Hoewel notebooks nuttig zijn voor verkennende gegevensanalyse, moeten ze niet de beslissingsfactor zijn. Rekenresources voor notebooks vallen doorgaans buiten het bereik van het aggregatiegegevensarchief. Ze zijn meestal geïntegreerd met andere resources, zoals Azure Machine Learning.

Niet-functionele vereisten

  • Hoeveel gegevens verwacht u op te slaan?

    AI-workloads genereren veel gegevens. Volume kan aanzienlijk toenemen vanwege meerdere versies en extra metagegevens.

    Schaalbaarheid voor opslag en doorvoer is belangrijk. Het gegevensplatform moet efficiënt gegevens uit de opnamepijplijn gebruiken terwijl het gegevensvolume verwerkt, gelijktijdige schrijfbewerkingen beheert en zorgt voor afzonderlijke schrijfprestaties zonder degradatie. Deze criteria zijn ook van toepassing op de verwerkingspijplijn die leest, verwerkt en zelfs terugschrijft naar het archief.

    Wanneer u een beslissing neemt, moet u rekening houden met het hele proces, omdat opname en verwerking vaak tegelijkertijd plaatsvinden. Het ontwerp moet in staat zijn om frequente gegevensverplaatsing en -verwerking te kunnen beheren. Het gegevensplatform moet een hoog niveau van parallelle uitvoering bieden om gegevens effectief te verwerken.

    De platformtechnologie moet telemetrie verzenden die zinvol inzicht biedt in de doorvoer en prestaties van de lees- en schrijfbewerkingen.

  • Is dit gegevensarchief een essentieel onderdeel dat bijdraagt aan het betrouwbaarheidsdoel van de workload?

    Kies een gegevensarchief dat de betrouwbaarheid en schaalbaarheid verbetert met behulp van meerdere exemplaren. Big data-archieven hebben vaak een ingebouwde controller waarmee gegevensverwerking in verschillende exemplaren wordt georganiseerd. Als de ene kopie mislukt, kan er een andere worden gebruikt.

    Houd er rekening mee dat gegevens niet het doel ervan dienen als ze niet juist of toegankelijk zijn. Het gegevensplatform moet duurzaamheid garanderen en ervoor zorgen dat de gegevens intact blijven. Zorg ervoor dat de API's die een query uitvoeren op de gegevens toegankelijk zijn. Overweeg bovendien gegevensarchieven met back-upfuncties.

    Over het algemeen hoeft u geen back-ups te maken van deze gegevens. Als de kosten voor het aggregeren van gegevens echter aanzienlijk hoog zijn, kunt u overwegen om de gegevens van een back-up te reactiveren.

  • Hebt u kostenbeperkingen?

    Als de betrouwbaarheid en prestaties van gegevens voldoende zijn, moet u rekening houden met de kostenimpact.

    Het systeem moet één keer worden geoptimaliseerd voor schrijven, veel lezen om te voorkomen dat er te veel wordt besteed aan gegevensopslag. De trainings- of grondgegevens zijn belangrijk, maar niet kritiek, zoals een productiedatabase, waarvoor directe reactiesnelheid vereist is. De focus ligt op het verdelen van kosten met precies genoeg efficiëntie om het rendement op investeringen te maximaliseren.

De voorgaande vereisten kunnen natuurlijk leiden tot het gebruik van een data lake omdat het DLM, kwaliteitslagen, waarneembaarheid en ondersteuning biedt voor diverse bestandsindelingen. Als uw workload al gebruikmaakt van een data lake, kunt u profiteren van die resource om te voldoen aan uw AI-behoeften. U kunt ook andere opslagopties kiezen, zoals Azure Blob Storage, die een bepaald niveau van DLM, bewakingsmogelijkheden en hoge transactiesnelheden biedt.

Overwegingen voor het verwerken van gegevens

U moet gegevens in het geaggregeerde gegevensarchief verwerken om het bijbehorende hulpprogramma downstream te verhogen. ETL-pijplijnen voeren deze taak uit, wat het belangrijkst is op de volgende punten:

  • Opnamelaag

    De pijplijn is verantwoordelijk voor het verzamelen van gegevens uit verschillende bronnen en het verplaatsen ervan naar het samengevoegde gegevensarchief. Tijdens dit proces voert de pijplijn doorgaans eenvoudige voorverwerking uit en kan deze zelfs de gegevens structureren in een doorzoekbare indeling.

    Om de noodzaak van aangepaste code te minimaliseren, raden we u aan veel van deze verantwoordelijkheid te offloaden naar een gegevensplatform. Wanneer u een technologie selecteert, moet u rekening houden met de ETL-kenmerken die nodig zijn om modeltraining en -uitbreiding te ondersteunen.

  • Verwerkingslaag

    Gegevens uit het samengevoegde gegevensarchief worden uitgebreid verwerkt voordat ze kunnen worden gebruikt voor het indexeren of trainen van modellen. De verwerkingspijplijn vereist niveaus van betrouwbaarheid en schalen die vergelijkbaar zijn met de opnamepijplijn. Het belangrijkste verschil is het type verwerking dat op de gegevens wordt uitgevoerd.

    Het proces omvat aanzienlijke rescoping en herstructurering van gegevens. Dit proces omvat taken zoals entiteitsherkenning, het integreren van extra gegevens in de gegevensset en het uitvoeren van zoekacties. Dit proces kan ook het verwijderen van onnodige gegevens omvatten en het toepassen van gegevenslogica via een platform voor gegevensindeling.

De gegevensverwerkingsfase kan verschillende uitvoer produceren, die voor verschillende intenties in verschillende bestemmingen terechtkomen. Het belangrijkste doel is om gegevens uit het geaggregeerde gegevensarchief voor gebruik door de eindbestemming voor te bereiden en over te dragen. De consument kan gegevens ophalen wanneer dat nodig is, of de verwerkingslaag kan gegevens pushen wanneer deze gereed is.

Notitie

In de context van machine learning en generatieve AI is het belangrijk om onderscheid te maken tussen ETL-, ELT- en EL-processen. Traditionele ETL is van cruciaal belang voor datawarehousing en object-relationele toewijzingen, waarbij, vanwege schemabeperkingen, gegevens moeten worden getransformeerd voordat u deze in het doelsysteem laadt. ELT omvat het extraheren van gegevens, het laden ervan in een data lake en het vervolgens transformeren met behulp van hulpprogramma's zoals Python of PySpark. In generatieve AI, met name voor het ophalen van augmented generation (RAG), omvat het proces vaak eerst het extraheren en laden van documenten naar opslag, gevolgd door transformaties zoals segmentering of extractie van afbeeldingen.

In de volgende sectie vindt u richtlijnen voor het selecteren van een technologie voor gegevensverwerking met ETL-mogelijkheden.

Functionele vereisten

  • Wat is de ondersteuning voor het maken van verbinding met gegevensbronnen?

    Gegevens die moeten worden verwerkt, kunnen worden opgeslagen in relationele databases, big data-bronnen of verschillende opslagoplossingen.

    De meeste gegevensverwerkingstechnologieën ondersteunen vooraf gemaakte integraties waarmee u verbinding kunt maken met verschillende gegevensbronnen zonder code te schrijven. De connectors hebben functies zoals de mogelijkheid om gegevens van bron naar sink te kopiëren, zoekacties uit te voeren en een vorm van gegevensbeheer toe te passen. Er zijn hulpprogramma's die functies voor slepen en neerzetten bieden om onnodige codering te voorkomen.

    Kies een gegevensplatform waarmee u eenvoudig kunt integreren met de verwachte gegevensbronnen.

  • Kan het platform verschillende gegevensindelingen verwerken?

    Gegevens kunnen verschillende indelingen hebben, zoals gestructureerde gegevens, zoals databases en JSON, ongestructureerde gegevens, zoals afbeeldingen en documenten, of streaminggegevens, zoals gegevens van Internet of Things-apparaten. De pijplijnen moeten de verwachte bestandstypen kunnen verwerken.

  • Biedt het platform functies voor gegevensvoorbereiding en het bereik ervan?

    U moet gegevens verwerken die u wilt gebruiken voor training of uitbreiding totdat deze geschikt zijn voor training, afstemming of indexering. In uw strategieën voor gegevensontwerp moeten de vereisten expliciet worden beschreven.

    In de volgende artikelen worden specifieke overwegingen beschreven:

    Als onderdeel van eenvoudige reiniging verwijdert het platform duplicaten, vult ontbrekende waarden in en elimineert overbodige ruis tijdens opname. Voor bepaalde gebruiksscenario's, zoals het implementeren van een RAG-patroon, wordt u aangeraden kleine segmenten te gebruiken.

    Hoewel deze voorverwerkingsstappen nodig zijn, moet het platform ook uitgebreide gegevensmanipulatie ondersteunen die specifiek is voor uw behoeften. Dit proces omvat het laden, wijzigen van het bereik en het transformeren van gegevens. Voor bepaalde modellen moet het platform externe bronnen kunnen opvragen voor documentanalyse, zoals documentinformatie of andere AI-hulpprogramma's. Dit werk is nodig voor het voorbereiden van de gegevens en voor gegevensverrijking.

    Als uw gegevensarchief dit verwerkingsniveau ondersteunt, kunt u deze fase in het archief lokaliseren zonder het ergens anders te verplaatsen. Anders hebt u een externe technologie nodig, zoals Azure Databricks of Azure Data Factory. Deze technologieën zijn geschikt voor het verplaatsen van gegevens en het uitvoeren van manipulaties, zoals filteren, het vullen van ontbrekende waarden en het standaardiseren van tekenreeksbehuizing. Voor complexere taken is doorgaans een jobhostingplatform vereist. U kunt Spark-pools gebruiken voor indeling van big data.

    In bepaalde gevallen wilt u deze verantwoordelijkheid mogelijk externaliseren voor de consument van de gegevens. AI-modellen die gebruikmaken van machine learning bieden bijvoorbeeld mogelijkheden voor taakverwerking voor het lezen, bewerken en schrijven van gegevens met behulp van aangepaste Python-code.

    Een ander voorbeeld is RAG-implementatie. Een veelvoorkomende verwerkingsstap is segmenteren, waarbij een document is onderverdeeld in meerdere segmenten en elk segment wordt een rij in de index. Er worden ook insluitingen opgeslagen, die vaak door een OpenAI-service worden gegenereerd, voor deze segmenten. In AI-zoekopdrachten wordt dit proces ingedeeld in de indexeringswerkstroom, ongeacht of u OpenAI of Azure AI Search gebruikt.

  • Is er een ingebouwde orchestrator voor het beheren van werkstromen?

    De verwerkingstaken zijn modulair en worden uitgevoerd als taken. Het platform moet indelingsmogelijkheden hebben die de werkstroom opsplitsen in stappen of taken. Elke taak moet onafhankelijk worden gedefinieerd, uitgevoerd en bewaakt.

    In complexe werkstromen zijn bepaalde stappen afhankelijk van de geslaagde voltooiing van eerdere werkstromen. De orchestrator moet taakafhankelijkheden verwerken en ervoor zorgen dat taken in de juiste volgorde worden voltooid.

    Gegevensontwerp is een iteratief proces, dus het orchestratorhulpprogramma moet flexibel genoeg zijn om werkstromen eenvoudig te wijzigen. U moet nieuwe stappen kunnen invoeren of bestaande stappen kunnen aanpassen zonder grote delen van code te herschrijven.

    Data Factory is een populaire keuze omdat het een uitgebreide functieset biedt voor het beheren van gegevenswerkstromen. Azure Databricks kan ook complexe werkstromen beheren en taken plannen en bewaken. U moet ook rekening houden met de gevolgen voor de kosten. Azure Databricks-functies kunnen bijvoorbeeld uitgebreid zijn, maar ze zijn ook kostbaar. Een opensource-alternatieve optie, zoals Apache NiFi, is mogelijk rendabeler.

    Welke tool u kiest, is uiteindelijk afhankelijk van wat uw organisatie toestaat en de vaardigheden waarmee het workloadteam vertrouwd is.

Niet-functionele vereisten

Wanneer u een verwerkingspijplijn kiest, is het van cruciaal belang om de doorvoer en waarneembaarheid te verdelen. De pijplijn moet de benodigde gegevens voor modellen of indexen binnen een voldoende tijdsbestek betrouwbaar verwerken en landen. Het moet licht genoeg zijn om uw huidige behoeften te ondersteunen en schaalbaar te zijn voor toekomstige groei. Teams moeten bepalen hoeveel ze nodig hebben om het platform toekomstbestendig te maken om later technische schulden te voorkomen. Belangrijke overwegingen zijn onder meer de frequentie en het volume van gegevensopname, de betrouwbaarheid van het proces en de noodzaak om waarneembaarheid te controleren en problemen onmiddellijk op te lossen.

  • Hoeveel gegevens verwacht u op te nemen?

    Voor de opname- en verwerkingsfasen kunt u de schaalbaarheid en snelheid van het platform overwegen voor het afhandelen van taken. U verwacht bijvoorbeeld 10 terabytes aan gegevens dagelijks in een index te laden of voor modeltraining. Uw gegevensopnameplatform moet dat volume en met de verwachte doorvoer kunnen verwerken. In dit geval is het gebruik van Azure Logic Apps mogelijk niet haalbaar omdat deze kan mislukken onder een dergelijke belasting. In plaats daarvan is Data Factory beter geschikt voor deze schaal van gegevensverwerking.

    Een manier om grote volumes te verwerken, is door parallelle uitvoering, omdat het efficiëntere gegevensverwerking en -verwerking mogelijk maakt. Platformen zoals Azure Databricks kunnen taken organiseren door meerdere exemplaren voor dezelfde taak te maken en de belasting efficiënt te distribueren.

    Houd ook rekening met de acceptabele latentie en de complexiteit van de taken. Het opschonen van gegevens omvat bijvoorbeeld het valideren en mogelijk vervangen van ongeldige velden of het maskeren van gevoelige informatie. Voor deze taken zijn echter belangrijke resources vereist, omdat elke rij afzonderlijk wordt verwerkt, wat bijdraagt aan de totale tijd.

  • Welke bewakingsmogelijkheden hebt u nodig?

    Pijplijnen voor gegevensverwerking moeten bewakingsmogelijkheden hebben en inzicht bieden in de prestaties en status van taken van de pijplijn.

    U moet de voortgang van de taken kunnen bijhouden. Stel dat de pijplijn een taak voor het opschonen van gegevens uitvoert die niet gedeeltelijk wordt voltooid of voltooid. Er kan downstream-impact zijn op de kwaliteit van gegevens waarmee het model wordt getraind, wat van invloed kan zijn op de voorspellende kracht.

    Net als andere onderdelen in de workload moet u logboeken, metrische gegevens en waarschuwingen voor de gegevenspijplijn inschakelen om het gedrag ervan te begrijpen. Verzamel en analyseer metrische prestatiegegevens om inzicht te hebben in de efficiëntie- en betrouwbaarheidsaspecten.

    Identificeer eventuele hiaten in de ingebouwde telemetrie en bepaal welke aanvullende bewaking u moet implementeren. Deze bewaking kan betrekking hebben op het toevoegen van aangepaste logboekregistratie of metrische gegevens om specifieke details over de taakstappen vast te leggen.

  • Hoeveel betrouwbaarheid verwacht u van het gegevensverwerkingsplatform?

    De betrouwbaarheid van een pijplijn voor gegevensverwerking varieert op basis van de keuze van het platform. Hoewel Logic Apps indelingsmogelijkheden heeft, is het mogelijk niet zo betrouwbaar als Data Factory. Data Factory, gehost op een AKS-cluster (Azure Kubernetes Service), kan verschillende betrouwbaarheidskenmerken hebben.

    Setups met één exemplaar worden beschouwd als storingspunten. Kies een platform dat ondersteuning biedt voor betrouwbaarheidsfuncties, zoals meerdere exemplaren, om te voldoen aan uw vereisten.

    Het platform moet ook tolerantiefuncties ondersteunen. De orchestrator moet bijvoorbeeld automatisch een mislukte taak opnieuw proberen, waardoor handmatig opnieuw moet worden opgestart.

    Batchverwerking kan minder betrouwbaar zijn dan deductie, afhankelijk van de vereisten voor versheid en latentie van gegevens. Als de training wekelijks plaatsvindt en de verwerking één dag duurt, zijn incidentele fouten acceptabel omdat er voldoende tijd is om het opnieuw te proberen.

  • Zijn er kostenbeperkingen?

    Wanneer u de kosteneffectiviteit van een pijplijn voor gegevensverwerking beschouwt, is het belangrijk om een oplossing te kiezen die voldoet aan uw behoeften zonder onnodige kosten. Als uw vereisten de geavanceerde functies van Azure Databricks niet rechtvaardigen, is een voordeligere optie, zoals Data Factory, mogelijk voldoende. Daarnaast kunnen opensource-hulpprogramma's zoals Apache Airflow of Apache NiFi robuuste mogelijkheden bieden tegen lagere kosten. De sleutel is om te voorkomen dat er te veel wordt toegewezen aan functies die u niet nodig hebt en een platform selecteert dat de functionaliteit en kostenefficiëntie in balans brengt.

  • Wat zijn de beveiligingsvereisten voor de werkstromen en de gegevens die u verwerkt?

    Wees duidelijk over de vereisten voor beveiliging, privacy en gegevenslocatie. Denk bijvoorbeeld aan geografische wettelijke vereisten. Voldoen aan de vereisten voor gegevenslocatie door ervoor te zorgen dat gegevens worden opgeslagen en verwerkt binnen specifieke regio's. Mogelijk moet u afzonderlijke pijplijnen uitvoeren voor verschillende regio's, zoals één voor Europa en een andere voor Amerika, om te voldoen aan lokale nalevingsregels.

    Het gegevenspijplijnplatform moet identiteits- en toegangsbeheer ondersteunen om ervoor te zorgen dat alleen geautoriseerde identiteiten toegang hebben tot specifieke taken of stappen binnen werkstromen. Als uw ETL-proces bijvoorbeeld uit verschillende werkstromen bestaat en een van deze werkstromen zeer vertrouwelijke gegevens verwerkt, moet het platform u in staat stellen om de toegang tot die werkstroom te beperken terwijl de anderen toegankelijk blijven. Met deze mogelijkheid kunt u voldoen aan de beveiligingsvereisten zonder dat u afzonderlijke platforms nodig hebt voor verschillende vertrouwelijkheidsniveaus voor gegevens. In het ideale geval moet het platform ingebouwde ondersteuning bieden voor dergelijke isolatie die efficiënt en veilig gegevensbeheer mogelijk maakt.

Pijplijnen voor gegevensverwerking kunnen de gegevens uitvoeren naar een zoekindex of een pijplijn voor modeltraining. Zie de secties over zoekindexen of functiearchieven, afhankelijk van de use-case.

Overwegingen voor een zoekindex

De zoekindex is ontworpen om contextuele of grondgegevens op te slaan die naar het eindpunt voor modeldeductie moeten worden verzonden, samen met de prompt. Beide aanroepen, de indexquery en de aanroep van het deductie-eindpunt, vinden plaats in de context van het onderhouden van dezelfde HTTP-aanvragen van clients. In tegenstelling tot ETL-processen die offline- en batchtaken verwerken, ondersteunt deze index realtime deductie, waarvoor hoge prestaties en betrouwbaarheid vereist zijn. Het is gespecialiseerd voor AI-query's en biedt functies zoals het indexeren en filteren van trefwoorden, die niet typisch zijn voor big data-archieven. Het doel is om een hoog presterend, write-once, read-many-gegevensarchief te hebben dat ondersteuning biedt voor impromptu- en fuzzy query's. Dit gegevensarchief kan relevante resultaten bieden zonder nauwkeurige query's.

Functionele vereisten

  • Welke zoektypen ondersteunt de zoekindex?

    Query's die het systeem ontvangt, zijn in wezen zoekopdrachten en de index moet uitgebreide zoekmogelijkheden ondersteunen. Voor RAG is vectorzoekopdrachten niet toegestaan omdat gegevens worden opgeslagen als berekende vectoren of insluitingen, die worden gebruikt om te zoeken.

    Vectorzoekopdrachten zijn krachtig en combineren met filteren en zoeken in volledige tekst verbetert de effectiviteit van de zoekindex. Uw gegevensontwerp moet rekening houden met het combineren van deze typen zoekopdrachten, zoals vector, zoeken in volledige tekst, filteren en speciale gegevenstypen, zoals geografische locatie.

    Uw gegevensontwerp moet deze vereisten expliciet aangeven. Zie Efficiënt query's uitvoeren in het gegevensontwerp voor meer informatie.

  • Ondersteunt de index multimodale gegevens?

    Kies indextechnologieën die ondersteuning bieden voor multimodale gegevens. AI-zoekopdrachten kunnen bijvoorbeeld een e-mailbericht analyseren, een afbeelding erin converteren naar vectoren en de beschrijving opslaan in de index. Gebruik deze functie om te zoeken naar verschillende inhoudsmodaliteiten, waaronder afbeeldingen, video's en audiobestanden.

  • Biedt de index ondersteuning voor mogelijkheden voor automatische updates wanneer de gegevens in de gegevensbronnen worden gewijzigd?

    Kies een index met functies voor automatische updates. Als deze niet beschikbaar is, moet u handmatig wijzigingen in de index detecteren en pushen. Met deze mogelijkheden kan de indexeerfunctie wijzigingen in gegevensbronnen detecteren en automatisch updates ophalen. Door deze verantwoordelijkheid naar het platform te offloaden, kunt u de operationele overhead verminderen en het onderhoudsproces vereenvoudigen.

Niet-functionele vereisten

  • Kan de index worden uitgevoerd met grote hoeveelheden gegevens?

    De index moet grote hoeveelheden gegevens kunnen verwerken, schaalbaar zijn en goed presteren voor zware zoekworkloads. De index slaat de onbewerkte gegevens en alle metagegevens, verrijkingen en entiteiten op die eraan zijn gekoppeld. In de context van het RAG-patroon kan één document dat is gesplitst in meerdere segmenten leiden tot een aanzienlijke toename van het gegevensvolume.

  • Heeft de index ingebouwde betrouwbaarheidsfuncties?

    Houd rekening met de uitlijning tussen de betrouwbaarheid van het deductie-eindpunt of het model en het gegevensarchief, omdat deze afhankelijk zijn van elkaar.

    Het zoekproces omvat twee stappen: een query uitvoeren op het gegevensarchief en vervolgens het deductie-eindpunt opvragen. Beide stappen moeten vergelijkbare betrouwbaarheidskenmerken hebben. Balans tussen uw betrouwbaarheidsdoelstellingen tussen beide onderdelen om de effectiviteit van de zoekfunctie te waarborgen.

    Om tolerantie te garanderen, moet de workload het verwachte aantal gelijktijdige gebruikers ondersteunen en voldoende bandbreedte hebben om verkeerspieken af te handelen. In het ideale geval moet het platform zonegebonden storingen overleven.

    Het gegevensplatform moet worden ontworpen om het gebruik van een beschadigde index voor deductie te voorkomen. In dergelijke gevallen moet u de index eenvoudig opnieuw kunnen opbouwen. De index moet ook ondersteuning bieden voor betrouwbaar wisselen tussen indexen met behulp van functies zoals aliasing om downtime tijdens indexwisselingen te minimaliseren. Zonder deze functionaliteit moet u mogelijk vertrouwen op een back-up van de index. Het beheren van een back-up heeft meer complexiteit.

    Begrijp vanuit het perspectief van een workload de mogelijke foutmodi of stressindicatoren, zoals beperking. Hoewel het systeem bijvoorbeeld normaal gesproken 50 gelijktijdige gebruikers ondersteunt, kan het slechts 30 gebruikers ondersteunen tijdens een herindexeringsproces dat wordt uitgevoerd als achtergrondtaak. In dat geval wordt de timing van de achtergrondtaak belangrijk. Wanneer u de doorvoer van een index evalueert, moet u zowel front-endquery's als back-endtaken opnemen.

  • Wat zijn de belangrijkste kostenfactoren van deze technologie?

    Wanneer u kosten modelleert, maakt u een schatting van de kosten die zijn gekoppeld aan het gegevensvolume, het aantal query's en de verwachte doorvoer van de index. Houd er rekening mee dat indexen voornamelijk PaaS (Platform as a Service) zijn, waarbij prijzen worden geabstraheerd. Onderzoekslagen en hun mogelijkheden om te voorkomen dat ongebruikte capaciteit of functies te veel worden betaald.

    AI Search factureert bijvoorbeeld als eenheden, waaronder capaciteit, doorvoer en opslag. Extra functies kunnen leiden tot meer kosten. Een uitgebreid gebruik van functies voor het extraheren van afbeeldingen kan bijvoorbeeld leiden tot een hoge factuur. Afhankelijkheden, zoals de functie vaardighedenset, die buiten het bereik van de index vallen, maar deel uitmaken van gegevensverwerking, kunnen extra kosten in rekening worden gebracht.

    Betalen voor een laag zonder gebruik van de volledige capaciteit kan leiden tot overbetalen. Op dezelfde manier zijn het aantal tabellen in uw index en de mogelijkheid om gelijktijdig verkeer te verwerken van invloed op de kosten.

    Zie De kosten van een AI-Search-service plannen en beheren voor meer informatie over de kosten die zijn gekoppeld aan AI Search.

  • Voldoen de beveiligingsfuncties van de index aan het ontwerp van uw beveiligingsgegevens?

    Uw gegevensontwerp moet duidelijk de beveiligings- en privacyvereisten opgeven. In ontwikkel- en testomgevingen waar echte productiegegevens worden gebruikt, moet de index ondersteuning bieden voor mogelijkheden die voldoen aan alle toegangscontroles en traceringsmaatregelen. Bekijk beveiligingsfuncties zoals gegevensmaskering en het verwijderen van persoonlijke gegevens in de index.

    Kies een index die de mogelijkheid heeft om clients uniek te identificeren via Microsoft Entra-id. De zoekindex moet ook toegangsbeheer op documentniveau ondersteunen om query's op relevantie per identiteit toe te staan. Als de index deze functies niet biedt, past u uw ontwerp aan om vergelijkbare mogelijkheden te bereiken met queryfilters. Zie Beveiligingsfilters voor het bijsnijden van resultaten in AI Search voor meer informatie.

    In het ideale geval moet de zoekindex overeenkomen met de vereisten voor netwerkbeveiliging. Als u bijvoorbeeld uitgaand verkeer naar niet-Microsoft-sites wilt filteren en waarneembaarheid wilt behouden, moet de index uitgaand verkeer bieden. Het moet ook netwerksegmentatie ondersteunen. Als de back-end-rekenkracht zich in een virtueel netwerk bevindt, is privéconnectiviteit voor belangrijke onderdelen, inclusief de index, essentieel om blootstelling aan het openbare internet te voorkomen. De index moet eenvoudig worden geïntegreerd met particuliere netwerken en beheerde identiteiten ondersteunen voor verificatie via Microsoft Entra-id.

Overwegingen voor een functiearchief

Voor discriminerende modellen kan uw gegevensontwerp een tussenliggend gegevensarchief bevatten dat gegevens opslaat voor extra verfijning. Met dit archief, ook wel een functiearchief genoemd, kunnen gegevenswetenschappers functies opslaan als een laatste stap, buiten het samengevoegde gegevensarchief.

Het functiearchief helpt catalogusgegevens voor meerdere toepassingen door metagegevens toe te voegen, zoals generatietijd en oorsprong. Deze tussenlandingsplek is ideaal voor gouden trainingsgegevens.

Het beheerde functiearchief in Machine Learning is een optie voor gegevensopslag die kan worden geïntegreerd met MLflow en andere hulpprogramma's. Hiermee worden gegevens opgehaald en getraind uit het samengevoegde gegevensarchief, waarbij een herbruikbare laag wordt toegevoegd voor betere gegevensherkomst en formele identificatie in Machine Learning.

Wanneer u een functiearchief gebruikt, behandelt u het als een gegevensarchief met beveiligings- en toegangsoverwegingen.

Overwegingen voor een offlinedeductiegegevensarchief

In sommige scenario's is het gebruik van een afzonderlijk archief geschikt voor snellere toekomstige zoekacties, omdat deductie vooraf wordt uitgevoerd op vooraf verzamelde en vooraf berekende gegevens. In dit proces bereikt de gebruikersaanvraag nooit het AI-model. Er zijn verschillende voordelen:

  • Verbeterde efficiëntie en gebruikerservaring door latentie te verminderen. Resultaten worden sneller geleverd voor frequente query's, zoals het genereren van veelgestelde vragen als resultaat.
  • Deductieoproepen kunnen eenvoudiger worden uitgeschaald als een batchproces zonder de beperkingen van realtime verwerking.
  • Staat prevalidatie toe om de nauwkeurigheid vóór de productie te garanderen.
  • Omdat de aanvraag niet wordt omgeleid naar het interferentie-eindpunt, vermindert het de belasting, wat bijdraagt aan de betrouwbaarheid van de workload.
  • Kan rendabeler zijn omdat het de noodzaak voor high-performance hardware vermindert die nodig is voor realtime verwerking.

Deze aanpak is echter alleen effectief als u de mogelijke aanvragen kunt voorspellen en een aanzienlijk deel van de voorspellingen naar verwachting door gebruikers wordt aangevraagd. Voor scenario's met minder herhaalde aanvragen is een offlinedeductiearchief mogelijk minder effectief.

Het gegevensarchief voor dit scenario moet worden geoptimaliseerd voor leesbewerkingen, moet grote hoeveelheden gegevens kunnen verwerken en efficiënt kunnen worden opgehaald. Het moet ook kunnen worden geïntegreerd in het samengevoegde gegevensarchief. Elk archief met deze mogelijkheden kan worden overwogen, zoals Azure Cosmos DB of zelfs een tabelopslag.

Resources

Deze artikelen bevatten meer informatie over Azure-producten die we aanbevelen als technologieopties voor de overwegingen die in dit artikel worden besproken.

Volgende stappen

Ontwerpgebied: MLOps en GenAIOps