I dagens informasjonsalder utgjør de enorme datavolumene som ligger i utallige dokumenter både en utfordring og en mulighet for bedrifter. Tradisjonelle dokumentbehandlingsmetoder kommer ofte til kort når det gjelder effektivitet og nøyaktighet, og gir rom for innovasjon, kostnadseffektivitet og optimaliseringer. Dokumentbehandling har vært vitne til betydelige fremskritt med bruken av Intelligent Document Processing (IDP). Med IDP kan bedrifter transformere ustrukturerte data fra ulike dokumenttyper til strukturert, handlingskraftig innsikt, noe som dramatisk forbedrer effektiviteten og reduserer manuell innsats. Potensialet slutter imidlertid ikke der. Ved å integrere generativ kunstig intelligens (AI) i prosessen, kan vi forbedre IDP-evnene ytterligere. Generativ AI introduserer ikke bare forbedrede muligheter i dokumentbehandling, den introduserer også en dynamisk tilpasningsevne til endrede datamønstre. Dette innlegget tar deg gjennom synergien mellom IDP og generativ AI, og avslører hvordan de representerer den neste frontlinjen innen dokumentbehandling.
Vi diskuterer IDP i detalj i vår serie Intelligent dokumentbehandling med AWS AI-tjenester (Del 1 og Del 2). I dette innlegget diskuterer vi hvordan man kan utvide en ny eller eksisterende IDP-arkitektur med store språkmodeller (LLM). Mer spesifikt diskuterer vi hvordan vi kan integrere amazontekst med Langkjede som dokumentlaster og Amazonas grunnfjell å trekke ut data fra dokumenter og bruke generative AI-funksjoner innenfor de ulike IDP-fasene.
Amazon Textract er en maskinlæringstjeneste (ML) som automatisk trekker ut tekst, håndskrift og data fra skannede dokumenter. Amazon Bedrock er en fullt administrert tjeneste som tilbyr et utvalg av høyytende fundamentmodeller (FM-er) gjennom brukervennlige API-er.
Følgende diagram er en referansearkitektur på høyt nivå som forklarer hvordan du kan forbedre en IDP-arbeidsflyt ytterligere med grunnmodeller. Du kan bruke LLM-er i én eller alle faser av IDP avhengig av brukstilfellet og ønsket resultat.
I de følgende delene dykker vi dypt inn i hvordan Amazon Textract er integrert i generative AI-arbeidsflyter ved å bruke LangChain for å behandle dokumenter for hver av disse spesifikke oppgavene. Kodeblokkene som er gitt her har blitt trimmet ned for korthets skyld. Se vår GitHub repository for detaljerte Python-notatbøker og en trinn-for-trinn-gjennomgang.
Tekstutvinning fra dokumenter er et avgjørende aspekt når det gjelder å behandle dokumenter med LLM-er. Du kan bruke Amazon Textract til å trekke ut ustrukturert råtekst fra dokumenter og bevare de originale semistrukturerte eller strukturerte objektene som nøkkelverdi-par og tabeller som finnes i dokumentet. Dokumentpakker som helsetjenester og forsikringskrav eller boliglån består av komplekse skjemaer som inneholder mye informasjon på tvers av strukturerte, semistrukturerte og ustrukturerte formater. Dokumentutvinning er et viktig skritt her fordi LLM-er drar nytte av det rike innholdet for å generere mer nøyaktige og relevante svar, som ellers kan påvirke kvaliteten på LLM-enes produksjon.
LangChain er et kraftig åpen kildekode-rammeverk for integrering med LLM-er. LLM-er generelt er allsidige, men kan slite med domenespesifikke oppgaver der dypere kontekst og nyanserte svar er nødvendig. LangChain gir utviklere i slike scenarier mulighet til å bygge agenter som kan bryte ned komplekse oppgaver i mindre underoppgaver. Underoppgavene kan deretter introdusere kontekst og minne i LLM-er ved å koble sammen og lenke LLM-meldinger.
LangChain tilbyr dokumentlastere som kan laste inn og transformere data fra dokumenter. Du kan bruke dem til å strukturere dokumenter i foretrukne formater som kan behandles av LLM-er. De AmazonTextractPDFLoader er en tjenestelaster type dokumentlaster som gir rask måte å automatisere dokumentbehandling ved å bruke Amazon Textract i kombinasjon med LangChain. For mer informasjon om AmazonTextractPDFLoader
, referere til Langkjede dokumentasjon. For å bruke Amazon Textract-dokumentlasteren, starter du med å importere den fra LangChain-biblioteket:
from langchain.document_loaders import AmazonTextractPDFLoader
https_loader = AmazonTextractPDFLoader("https://sample-website.com/sample-doc.pdf")
https_document = https_loader.load() s3_loader = AmazonTextractPDFLoader("s3://sample-bucket/sample-doc.pdf")
s3_document = s3_loader.load()
Du kan også lagre dokumenter i Amazon S3 og referere til dem ved å bruke s3:// URL-mønsteret, som forklart i Få tilgang til en bøtte med S3://, og send denne S3-banen til Amazon Textract PDF-lasteren:
import boto3
textract_client = boto3.client('textract', region_name='us-east-2') file_path = "s3://amazon-textract-public-content/langchain/layout-parser-paper.pdf"
loader = AmazonTextractPDFLoader(file_path, client=textract_client)
documents = loader.load()
Et flersidet dokument vil inneholde flere sider med tekst, som deretter kan nås via dokumentobjektet, som er en liste over sider. Følgende kode går gjennom sidene i dokumentobjektet og skriver ut dokumentteksten, som er tilgjengelig via page_content
Egenskap:
print(len(documents)) for document in documents: print(document.page_content)
Amazon Comprehend og LLM-er kan effektivt brukes til dokumentklassifisering. Amazon Comprehend er en naturlig språkbehandlingstjeneste (NLP) som bruker ML for å trekke ut innsikt fra tekst. Amazon Comprehend støtter også tilpasset klassifiseringsmodellopplæring med layoutbevissthet på dokumenter som PDF-er, Word- og bildeformater. For mer informasjon om bruk av Amazon Comprehend-dokumentklassifisereren, se Amazon Comprehend dokumentklassifiserer legger til layoutstøtte for høyere nøyaktighet.
Når sammenkoblet med LLM-er, blir dokumentklassifisering en kraftig tilnærming for å administrere store mengder dokumenter. LLM-er er nyttige i dokumentklassifisering fordi de kan analysere teksten, mønstrene og kontekstuelle elementene i dokumentet ved hjelp av naturlig språkforståelse. Du kan også finjustere dem for spesifikke dokumentklasser. Når en ny dokumenttype introdusert i IDP-rørledningen trenger klassifisering, kan LLM behandle tekst og kategorisere dokumentet gitt et sett med klasser. Følgende er en eksempelkode som bruker LangChain-dokumentlasteren drevet av Amazon Textract for å trekke ut teksten fra dokumentet og bruke den til å klassifisere dokumentet. Vi bruker Antropiske Claude v2 modell via Amazon Bedrock for å utføre klassifiseringen.
I det følgende eksemplet trekker vi først ut tekst fra en pasientutskrivningsrapport og bruker en LLM for å klassifisere den gitt en liste over tre forskjellige dokumenttyper—DISCHARGE_SUMMARY
, RECEIPT
og PRESCRIPTION
. Følgende skjermbilde viser rapporten vår.
from langchain.document_loaders import AmazonTextractPDFLoader
from langchain.llms import Bedrock
from langchain.prompts import PromptTemplate
from langchain.chains import LLMChain loader = AmazonTextractPDFLoader("./samples/document.png")
document = loader.load() template = """ Given a list of classes, classify the document into one of these classes. Skip any preamble text and just give the class name. <classes>DISCHARGE_SUMMARY, RECEIPT, PRESCRIPTION</classes>
<document>{doc_text}<document>
<classification>""" prompt = PromptTemplate(template=template, input_variables=["doc_text"])
bedrock_llm = Bedrock(client=bedrock, model_id="anthropic.claude-v2") llm_chain = LLMChain(prompt=prompt, llm=bedrock_llm)
class_name = llm_chain.run(document[0].page_content) print(f"The provided document is = {class_name}")
Oppsummering innebærer å kondensere en gitt tekst eller et dokument til en kortere versjon samtidig som den beholder nøkkelinformasjonen. Denne teknikken er gunstig for effektiv informasjonshenting, som gjør det mulig for brukere å raskt forstå hovedpunktene i et dokument uten å lese hele innholdet. Selv om Amazon Textract ikke direkte utfører tekstoppsummering, gir det de grunnleggende mulighetene for å trekke ut hele teksten fra dokumenter. Denne utpakkede teksten fungerer som input til vår LLM-modell for å utføre tekstoppsummeringsoppgaver.
Ved å bruke den samme prøveutskrivningsrapporten bruker vi AmazonTextractPDFLoader
for å trekke ut tekst fra dette dokumentet. Som før bruker vi Claude v2-modellen via Amazon Bedrock og initialiserer den med en ledetekst som inneholder instruksjonene om hva du skal gjøre med teksten (i dette tilfellet oppsummering). Til slutt kjører vi LLM-kjeden ved å sende inn den utpakkede teksten fra dokumentlasteren. Dette kjører en slutningshandling på LLM med ledeteksten som består av instruksjonene for å oppsummere, og dokumentets tekst markert med Document
. Se følgende kode:
Koden genererer sammendraget av en sammendragsrapport for pasientutskrivning:
Det foregående eksemplet brukte et enkeltsides dokument for å utføre oppsummering. Imidlertid vil du sannsynligvis håndtere dokumenter som inneholder flere sider som trenger oppsummering. En vanlig måte å utføre oppsummering på flere sider er å først generere sammendrag på mindre tekstbiter og deretter kombinere de mindre sammendragene for å få et endelig sammendrag av dokumentet. Merk at denne metoden krever flere anrop til LLM. Logikken for dette kan lages enkelt; LangChain har imidlertid en innebygd oppsummeringskjede som kan oppsummere store tekster (fra flersidige dokumenter). Oppsummeringen kan skje enten via map_reduce
eller med stuff
alternativer, som er tilgjengelige som alternativer for å administrere flere anrop til LLM. I følgende eksempel bruker vi map_reduce
for å oppsummere et flersidig dokument. Følgende figur illustrerer arbeidsflyten vår.
La oss først starte med å trekke ut dokumentet og se det totale antall tokener per side og det totale antallet sider:
Deretter bruker vi LangChains innebygde load_summarize_chain
for å oppsummere hele dokumentet:
from langchain.chains.summarize import load_summarize_chain summary_chain = load_summarize_chain(llm=bedrock_llm, chain_type='map_reduce')
output = summary_chain.run(document)
print(output.strip())
Standardisering og spørsmål og svar
I denne delen diskuterer vi standardisering og spørsmål og svar-oppgaver.
Standardisering
Utdatastandardisering er en tekstgenereringsoppgave der LLM-er brukes for å gi en konsistent formatering av utdatateksten. Denne oppgaven er spesielt nyttig for automatisering av utvinning av nøkkelenheter som krever at utdataene er justert med ønskede formater. For eksempel kan vi følge umiddelbare beste praksiser for ingeniørarbeid for å finjustere en LLM for å formatere datoer til MM/DD/ÅÅÅÅ-format, som kan være kompatibelt med en database DATO-kolonne. Følgende kodeblokk viser et eksempel på hvordan dette gjøres ved hjelp av en LLM og prompt engineering. Ikke bare standardiserer vi utdataformatet for datoverdiene, vi ber også modellen om å generere den endelige utgangen i et JSON-format slik at den lett kan brukes i nedstrømsapplikasjonene våre. Vi bruker LangChain Expression Language (LCEL) for å lenke sammen to handlinger. Den første handlingen ber LLM om å generere en utdata i JSON-format med bare datoene fra dokumentet. Den andre handlingen tar JSON-utdata og standardiserer datoformatet. Merk at denne to-trinns handlingen også kan utføres i ett enkelt trinn med riktig prompt engineering, som vi vil se i normalisering og maling.
Utdata fra det foregående kodeeksemplet er en JSON-struktur med datoer 07/09/2020 og 08/09/2020, som er i formatet DD/MM/ÅÅÅÅ og er henholdsvis pasientens innleggelses- og utskrivningsdato fra sykehuset, iht. til utslippsrapporten.
Spørsmål og svar med Retrieval Augmented Generation
LLM-er er kjent for å beholde faktainformasjon, ofte referert til som deres verdenskunnskap eller verdenssyn. Når de er finjustert, kan de produsere toppmoderne resultater. Det er imidlertid begrensninger for hvor effektivt en LLM kan få tilgang til og manipulere denne kunnskapen. Som et resultat, i oppgaver som i stor grad er avhengige av spesifikk kunnskap, kan det hende at ytelsen deres ikke er optimal for visse brukstilfeller. For eksempel, i spørsmål og svar-scenarier, er det viktig at modellen holder seg strengt til konteksten gitt i dokumentet uten å stole utelukkende på sin verdenskunnskap. Å avvike fra dette kan føre til feilaktige fremstillinger, unøyaktigheter eller til og med feil svar. Den mest brukte metoden for å løse dette problemet er kjent som Retrieval Augmented Generation (FILLE). Denne tilnærmingen synergerer styrken til både gjenfinningsmodeller og språkmodeller, og forbedrer presisjonen og kvaliteten på responsene som genereres.
LLM-er kan også pålegge token-begrensninger på grunn av deres minnebegrensninger og begrensningene til maskinvaren de kjører på. For å håndtere dette problemet, brukes teknikker som chunking for å dele store dokumenter i mindre deler som passer innenfor token-grensene til LLM. På den annen side brukes innebygginger i NLP først og fremst for å fange den semantiske betydningen av ord og deres forhold til andre ord i et høydimensjonalt rom. Disse innebyggingene transformerer ord til vektorer, slik at modeller kan behandle og forstå tekstdata effektivt. Ved å forstå de semantiske nyansene mellom ord og setninger, gjør innebygginger det mulig for LLM-er å generere sammenhengende og kontekstuelt relevante utdata. Legg merke til følgende nøkkelord:
- chunking – Denne prosessen bryter ned store mengder tekst fra dokumenter til mindre, meningsfulle tekstbiter.
- Innebygging – Dette er fastdimensjonale vektortransformasjoner av hver del som beholder den semantiske informasjonen fra delene. Disse innebyggingene blir deretter lastet inn i en vektordatabase.
- Vektordatabase – Dette er en database med ordinnbygginger eller vektorer som representerer konteksten til ord. Den fungerer som en kunnskapskilde som hjelper NLP-oppgaver i dokumentbehandlingsrørledninger. Fordelen med vektordatabasen her er at den bare lar den nødvendige konteksten gis til LLM-ene under tekstgenerering, som vi forklarer i den følgende delen.
RAG bruker kraften til innebygginger til å forstå og hente relevante dokumentsegmenter under gjenfinningsfasen. Ved å gjøre det kan RAG arbeide innenfor token-begrensningene til LLM-er, og sikre at den mest relevante informasjonen velges for generering, noe som resulterer i mer nøyaktige og kontekstuelt relevante utdata.
Følgende diagram illustrerer integreringen av disse teknikkene for å lage input til LLM-er, forbedre deres kontekstuelle forståelse og muliggjøre mer relevante i kontekst-svar. En tilnærming involverer likhetssøk, ved å bruke både en vektordatabase og chunking. Vektordatabasen lagrer innebygginger som representerer semantisk informasjon, og chunking deler tekst inn i håndterbare seksjoner. Ved å bruke denne konteksten fra likhetssøk, kan LLM-er kjøre oppgaver som spørsmålssvar og domenespesifikke operasjoner som klassifisering og berikelse.
For dette innlegget bruker vi en RAG-basert tilnærming for å utføre spørsmål og svar i kontekst med dokumenter. I følgende kodeeksempel trekker vi ut tekst fra et dokument og deler deretter opp dokumentet i mindre tekstbiter. Chunking er nødvendig fordi vi kan ha store flersidige dokumenter og våre LLM-er kan ha token-grenser. Disse bitene blir deretter lastet inn i vektordatabasen for å utføre likhetssøk i de påfølgende trinnene. I det følgende eksempelet bruker vi Amazon Titan Embed Text v1-modellen, som utfører vektorinnbyggingen av dokumentbitene:
Koden skaper en relevant kontekst for LLM ved å bruke tekstbitene som returneres av likhetssøkehandlingen fra vektordatabasen. For dette eksempelet bruker vi en åpen kildekode FAISS vektorbutikk som en eksempelvektordatabase for å lagre vektorinnbygginger av hver tekstbit. Vi definerer deretter vektordatabasen som en LangChain retriever, som føres inn i RetrievalQA
kjede. Dette kjører internt et likhetssøk på vektordatabasen som returnerer de øverste n (hvor n=3 i vårt eksempel) tekstbiter som er relevante for spørsmålet. Til slutt kjøres LLM-kjeden med den relevante konteksten (en gruppe relevante tekstbiter) og spørsmålet som LLM skal svare på. For en trinnvis kodegjennomgang av Q&A med RAG, se Python-notatboken på GitHub.
Som et alternativ til FAISS kan du også bruke Amazon OpenSearch Service vektordatabasefunksjoner, Amazon Relational Database Service (Amazon RDS) for PostgreSQL med pgvektor utvidelse som vektordatabaser, eller åpen kildekode Chroma Database.
Spørsmål og svar med tabelldata
Tabelldata i dokumenter kan være utfordrende for LLM-er å behandle på grunn av dens strukturelle kompleksitet. Amazon Textract kan utvides med LLM-er fordi det gjør det mulig å trekke ut tabeller fra dokumenter i et nestet format av elementer som side, tabell og celler. Å utføre spørsmål og svar med tabelldata er en flertrinnsprosess, og kan oppnås via selvsøkende. Følgende er en oversikt over trinnene:
- Trekk ut tabeller fra dokumenter ved hjelp av Amazon Textract. Med Amazon Textract kan tabellstrukturen (rader, kolonner, overskrifter) trekkes ut fra et dokument.
- Lagre tabelldataene i en vektordatabase sammen med metadatainformasjon, for eksempel overskriftsnavnene og beskrivelsen av hver overskrift.
- Bruk ledeteksten til å konstruere en strukturert spørring, ved å bruke en LLM, for å utlede dataene fra tabellen.
- Bruk spørringen til å trekke ut de relevante tabelldataene fra vektordatabasen.
For eksempel, i en kontoutskrift, gitt spørsmålet "Hva er transaksjonene med mer enn $1000 i innskudd", vil LLM fullføre følgende trinn:
- Lag et søk, for eksempel
“Query: transactions” , “filter: greater than (Deposit$)”
. - Konverter spørringen til en strukturert spørring.
- Bruk den strukturerte spørringen på vektordatabasen der tabelldataene våre er lagret.
For en trinnvis kodegjennomgang av spørsmål og svar med tabeller, se Python-notatboken i GitHub.
Maling og normaliseringer
I denne delen ser vi på hvordan du bruker prompte ingeniørteknikker og LangChains innebygde mekanisme for å generere en utgang med uttrekk fra et dokument i et spesifisert skjema. Vi utfører også en viss standardisering av de utvunnede dataene ved å bruke teknikkene som er diskutert tidligere. Vi starter med å definere en mal for ønsket utgang. Dette vil tjene som et skjema og innkapsle detaljene om hver enhet vi ønsker å trekke ut fra dokumentets tekst.
Merk at for hver av enhetene bruker vi beskrivelsen til å forklare hva den enheten er for å hjelpe LLM med å trekke ut verdien fra dokumentets tekst. I den følgende eksempelkoden bruker vi denne malen til å lage forespørselen vår om LLM sammen med teksten som er hentet fra dokumentet ved å bruke AmazonTextractPDFLoader
og deretter utføre inferens med modellen:
Som du kan se, er {keys}
en del av ledeteksten er nøklene fra malen vår, og {details}
er nøklene sammen med beskrivelsen. I dette tilfellet ber vi ikke modellen eksplisitt om formatet til utdataene annet enn å spesifisere i instruksjonen for å generere utdata i JSON-format. Dette fungerer for det meste; Men fordi utdataene fra LLM-er er ikke-deterministisk tekstgenerering, ønsker vi å spesifisere formatet eksplisitt som en del av instruksjonen i ledeteksten. For å løse dette kan vi bruke LangChain sine strukturert utdataparser modul for å dra nytte av den automatiserte ledeteksten som hjelper til med å konvertere malen vår til en formatinstruksjonsprompt. Vi bruker malen definert tidligere for å generere formatinstruksjonen som følger:
Vi bruker deretter denne variabelen i vår opprinnelige ledetekst som en instruksjon til LLM, slik at den trekker ut og formaterer utdataene i ønsket skjema ved å gjøre en liten modifikasjon av ledeteksten vår:
Så langt har vi kun hentet dataene ut av dokumentet i et ønsket skjema. Men vi må fortsatt utføre en viss standardisering. For eksempel ønsker vi at pasientens innleggelsesdato og utskrivningsdato trekkes ut i DD/MM/ÅÅÅÅ format. I dette tilfellet forsterker vi description
av nøkkelen med formateringsinstruksjonen:
Se Python-notisboken i GitHub for en full trinn-for-trinn gjennomgang og forklaring.
Stavekontroller og rettelser
LLM-er har vist bemerkelsesverdige evner til å forstå og generere menneskelignende tekst. En av de mindre diskuterte, men uhyre nyttige applikasjonene til LLM-er, er deres potensiale i grammatiske kontroller og setningskorreksjon i dokumenter. I motsetning til tradisjonelle grammatikkkontrollere som er avhengige av et sett med forhåndsdefinerte regler, bruker LLM-er mønstre som de har identifisert fra enorme mengder tekstdata for å finne ut hva som utgjør et korrekt eller flytende språk. Dette betyr at de kan oppdage nyanser, kontekst og finesser som regelbaserte systemer kan gå glipp av.
Se for deg teksten som er hentet fra et sammendrag av pasientutskrivning som lyder «Pasienten Jon Doe, som ble innlagt med alvorlig lungebetennelse, har vist betydelig bedring og kan trygt skrives ut. Oppfølging er planlagt til neste uke." En tradisjonell stavekontroll kan gjenkjenne "innrømmet", "lungebetennelse", "forbedring" og "nex" som feil. Konteksten til disse feilene kan imidlertid føre til ytterligere feil eller generiske forslag. En LLM, utstyrt med omfattende opplæring, kan foreslå: «Pasienten John Doe, som ble innlagt med alvorlig lungebetennelse, har vist betydelig bedring og kan trygt utskrives. Oppfølging er planlagt til neste uke."
Følgende er et dårlig håndskrevet eksempeldokument med samme tekst som forklart tidligere.
Vi trekker ut dokumentet med en Amazon Textract-dokumentlaster og instruerer deretter LLM, via prompt engineering, om å korrigere den utpakkede teksten for å rette eventuelle stave- og/eller grammatiske feil:
Utdataene fra den foregående koden viser den originale teksten som er trukket ut av dokumentlasteren etterfulgt av den korrigerte teksten generert av LLM:
Husk at så kraftige som LLM-er er, er det viktig å se forslagene deres som nettopp det – forslag. Selv om de fanger språkets forviklinger imponerende godt, er de ikke ufeilbarlige. Noen forslag kan endre den tiltenkte betydningen eller tonen i originalteksten. Derfor er det avgjørende for menneskelige anmeldere å bruke LLM-genererte rettelser som en guide, ikke en absolutt. Samarbeidet mellom menneskelig intuisjon og LLM-evner lover en fremtid der vår skriftlige kommunikasjon ikke bare er feilfri, men også rikere og mer nyansert.
konklusjonen
Generativ AI endrer hvordan du kan behandle dokumenter med IDP for å få innsikt. I posten Forbedrer AWS intelligent dokumentbehandling med generativ AI, diskuterte vi de ulike stadiene i pipelinen og hvordan AWS-kunden Ricoh forbedrer sin IDP-pipeline med LLM-er. I dette innlegget diskuterte vi ulike mekanismer for å utvide IDP-arbeidsflyten med LLM-er via Amazon Bedrock, Amazon Textract og det populære LangChain-rammeverket. Du kan komme i gang med den nye Amazon Textract-dokumentlasteren med LangChain i dag ved å bruke eksempelnotatbøkene som er tilgjengelige i vår GitHub repository. For mer informasjon om arbeid med generativ AI på AWS, se Annonserer nye verktøy for bygging med generativ AI på AWS.
Om forfatterne
Sonali Sahu leder intelligent dokumentbehandling med AI/ML-tjenesteteamet i AWS. Hun er en forfatter, tankeleder og lidenskapelig teknolog. Hennes kjernefokusområde er AI og ML, og hun snakker ofte på AI- og ML-konferanser og møter rundt om i verden. Hun har både bred og dyp erfaring innen teknologi og teknologibransjen, med bransjekompetanse innen helsevesen, finanssektoren og forsikring.
Anjan Biswas er en senior AI Services Solutions Architect med fokus på AI/ML og Data Analytics. Anjan er en del av det verdensomspennende AI-tjenesteteamet og jobber med kunder for å hjelpe dem med å forstå og utvikle løsninger på forretningsproblemer med AI og ML. Anjan har over 14 års erfaring med å jobbe med globale forsyningskjeder, produksjons- og detaljhandelsorganisasjoner, og hjelper aktivt kunder med å komme i gang og skalere på AWS AI-tjenester.
Chinmayee Rane er en AI/ML-spesialistløsningsarkitekt hos Amazon Web Services. Hun brenner for anvendt matematikk og maskinlæring. Hun fokuserer på å designe intelligent dokumentbehandling og generative AI-løsninger for AWS-kunder. Utenom jobben liker hun salsa og bachata dans.
- SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
- PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
- PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
- PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
- PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
- kilde: https://aws.amazon.com/blogs/machine-learning/intelligent-document-processing-with-amazon-textract-amazon-bedrock-and-langchain/
- : har
- :er
- :ikke
- :hvor
- . vedlegg
- $1000
- $OPP
- 1
- 10
- 100
- 11
- 12
- 13
- 14
- 15%
- 16
- 22
- 23
- 33
- 35%
- 7
- 9
- a
- evner
- Om oss
- Absolute
- adgang
- aksesseres
- Ifølge
- nøyaktighet
- nøyaktig
- oppnådd
- tvers
- Handling
- handlinger
- aktivt
- aktivitet
- handlinger
- Ad
- adresse
- Legger
- overholde
- innrømme
- innrømmet
- fremskritt
- Fordel
- advent
- alder
- agenter
- AI
- AI-tjenester
- AI / ML
- justert
- Alle
- tillate
- tillater
- langs
- også
- alternativ
- Selv
- Amazon
- Amazon Comprehend
- Amazon RDS
- amazontekst
- Amazon Web Services
- beløp
- an
- analytics
- analysere
- og
- besvare
- Antropisk
- noen
- APIer
- søknader
- anvendt
- avtaler
- tilnærming
- arkitektur
- ER
- AREA
- rundt
- Kunst
- kunstig
- kunstig intelligens
- Kunstig intelligens (AI)
- AS
- aspektet
- bistå
- Assistent
- At
- øke
- augmented
- forfatter
- automatisere
- Automatisert
- automatisk
- Automatisering
- tilgjengelig
- bevissthet
- AWS
- AWS-kunde
- Bank
- BE
- fordi
- blir
- vært
- før du
- gunstig
- nytte
- BEST
- beste praksis
- mellom
- Blokker
- Blocks
- både
- bredde
- Break
- pauser
- bygge
- Bygning
- innebygd
- virksomhet
- bedrifter
- men
- by
- Samtaler
- CAN
- Kan få
- evner
- fangst
- saken
- saker
- Celler
- viss
- kjede
- kjeder
- utfordre
- utfordrende
- endring
- Endringer
- endring
- Sjekker
- valg
- krav
- klasse
- klasser
- klassifisering
- Klassifisere
- kode
- SAMMENHENGENDE
- samarbeid
- Kolonne
- kolonner
- kombinasjon
- kombinere
- kommer
- Felles
- vanligvis
- Kommunikasjon
- kompatibel
- fullføre
- komplekse
- kompleksitet
- fatte
- konsis
- konferanser
- Tilkobling
- konsistent
- består
- begrensninger
- konstruere
- inneholde
- inneholdt
- inneholder
- innhold
- kontekst
- kontekstuelle
- konvertere
- Kjerne
- korrigere
- Korrigert
- Korreksjoner
- kunne
- lage
- utformet
- skaper
- avgjørende
- skikk
- kunde
- Kunder
- Dans
- dato
- Data Analytics
- Database
- databaser
- Dato
- datoer
- avtale
- dyp
- dypere
- definere
- definert
- definere
- demonstrert
- avhengig
- avleiringer
- dybde
- beskrevet
- beskrivelse
- utforme
- ønsket
- detalj
- detaljert
- detaljer
- oppdage
- Bestem
- utvikle
- utviklere
- Kosthold
- forskjellig
- direkte
- diskutere
- diskutert
- dykk
- dele
- skillelinjer
- do
- Doktor
- dokument
- dokumentasjon
- dokumenter
- doe
- ikke
- gjør
- Don
- gjort
- ikke
- ned
- dramatisk
- to
- under
- dynamisk
- e
- hver enkelt
- Tidligere
- lett
- lett-å-bruke
- effektivt
- effektivitet
- effektiv
- effektivt
- innsats
- enten
- elementer
- embed
- ansatt
- bemyndiger
- muliggjøre
- muliggjør
- muliggjør
- slutt
- Ingeniørarbeid
- forbedre
- forbedret
- styrke
- sikre
- sikrer
- Hele
- enheter
- enhet
- utstyrt
- feil
- avgjørende
- Selv
- eksempel
- Unntatt
- unntak
- eksisterende
- erfaring
- ekspertise
- Forklar
- forklarte
- forklarer
- forklaring
- eksplisitt
- uttrykk
- utvide
- forlengelse
- omfattende
- trekke ut
- utdrag
- ekstrakter
- Fall
- falsk
- langt
- tretthet
- Felt
- Figur
- slutt~~POS=TRUNC
- Endelig
- finansiell
- Finansiell sektor
- Først
- passer
- Fokus
- fokuserer
- følge
- fulgt
- etter
- følger
- Til
- format
- skjemaer
- funnet
- Fundament
- Rammeverk
- Gratis
- ofte
- fra
- Frontier
- fullt
- fullt
- videre
- framtid
- general
- generere
- generert
- genererer
- genererer
- generasjonen
- generative
- Generativ AI
- få
- Gi
- gitt
- Global
- grammatikk
- gripe
- større
- Gruppe
- veilede
- hånd
- håndtere
- skje
- Skjer
- maskinvare
- Ha
- overskrifter
- helsetjenester
- tungt
- hjelpe
- nyttig
- hjelpe
- hjelper
- her
- her.
- høyt nivå
- høytytende
- høyere
- holder
- sykehus
- Hvordan
- Hvordan
- Men
- HTML
- HTTPS
- menneskelig
- i
- ID
- identifisert
- if
- illustrerer
- bilde
- umåtelig
- Påvirkning
- importere
- viktig
- importere
- pålegge
- forbedring
- in
- Inkludert
- indeks
- industri
- informasjon
- Informasjon Alder
- Innovasjon
- inngang
- innsikt
- f.eks
- instruksjoner
- forsikring
- integrere
- integrert
- Integrering
- integrering
- Intelligens
- Intelligent
- Intelligent dokumentbehandling
- tiltenkt
- internt
- inn
- forviklinger
- introdusere
- introdusert
- Introduserer
- IT
- DET ER
- Jackson
- John
- JOHN DOE
- jon
- jpg
- JSON
- bare
- nøkkel
- nøkler
- Vet
- kunnskap
- kjent
- Språk
- stor
- Layout
- føre
- leder
- ledende
- læring
- forlater
- Bibliotek
- i likhet med
- Sannsynlig
- begrensninger
- grenser
- Liste
- LLM
- laste
- loader
- logikk
- Se
- Lot
- maskin
- maskinlæring
- Making
- administrer
- overkommelig
- fikk til
- administrerende
- håndbok
- produksjon
- merket
- matematikk
- Kan..
- me
- betyr
- meningsfylt
- midler
- mekanisme
- mekanismer
- Meetups
- Minne
- Meta
- metadata
- metode
- metoder
- kunne
- tankene
- gå glipp av
- feil
- ML
- modell
- modeller
- Moduler
- mer
- boliglån
- mest
- flere
- navn
- navn
- Naturlig
- Natural Language Processing
- nødvendig
- Trenger
- nødvendig
- behov
- Ny
- neste
- neste uke
- nlp
- bærbare
- nå
- skyggelegging
- Antall
- objekt
- gjenstander
- of
- Tilbud
- ofte
- on
- ONE
- bare
- åpen kildekode
- Drift
- Opportunity
- optimal
- alternativer
- or
- organisasjoner
- original
- Annen
- ellers
- vår
- ut
- Utfallet
- produksjon
- utganger
- utenfor
- enn
- oversikt
- pakker
- side
- sider
- Smerte
- sammen
- par
- del
- spesielt
- passere
- bestått
- Passerer
- lidenskapelig
- banen
- pasient
- Mønster
- mønstre
- for
- Utfør
- ytelse
- utført
- utfører
- utfører
- fase
- phd
- setninger
- rørledning
- fly
- plato
- Platon Data Intelligence
- PlatonData
- vær så snill
- lungebetennelse
- poeng
- Populær
- mulig
- Post
- potensiell
- makt
- powered
- kraftig
- praksis
- nettopp
- Precision
- trekkes
- presentere
- tidligere
- primært
- Skrive ut
- utskrifter
- Problem
- problemer
- prosess
- Bearbeidet
- prosessering
- produsere
- lover
- ordentlig
- gi
- forutsatt
- leverandør
- gir
- Python
- Q & A
- kvalitet
- spørsmål
- Rask
- raskt
- Raw
- Lesning
- gjenkjenne
- redusere
- referere
- referanse
- referert
- Relasjoner
- relevant
- avhengige
- avhengig
- bemerkelsesverdig
- rapporterer
- representere
- representerer
- påkrevd
- Krever
- henholdsvis
- svar
- restriksjoner
- resultere
- resulterende
- Resultater
- detaljhandel
- beholde
- støttemur
- avkastning
- Rich
- rom
- regler
- Kjør
- går
- s
- trygt
- samme
- sier
- Skala
- scenarier
- planlagt
- Søk
- Sekund
- Seksjon
- seksjoner
- sektor
- se
- segmenter
- valgt
- senior
- dømme
- Serien
- betjene
- serverer
- tjeneste
- Tjenester
- sett
- alvorlig
- hun
- Kort
- bør
- vist
- Viser
- signifikant
- enkelt
- liten
- mindre
- tekstutdrag
- So
- utelukkende
- Solutions
- LØSE
- noen
- kilde
- Rom
- Snakker
- spesialist
- spesifikk
- spesielt
- spesifisert
- staving
- splittet
- stadier
- standardisering
- Begynn
- startet
- state-of-the-art
- Uttalelse
- Trinn
- Steps
- Still
- oppbevare
- lagret
- butikker
- styrker
- String
- strukturell
- struktur
- strukturert
- Struggle
- senere
- I ettertid
- slik
- foreslår
- oppsummere
- SAMMENDRAG
- levere
- forsyningskjeden
- støtte
- Støtter
- synergi
- Systemer
- bord
- Ta
- tar
- Oppgave
- oppgaver
- lag
- teknikk
- teknikker
- teknolog
- Teknologi
- mal
- vilkår
- tekst
- tekstlig
- enn
- Det
- De
- verden
- deres
- Dem
- deretter
- Der.
- derfor
- Disse
- de
- denne
- trodde
- tre
- Gjennom
- titan
- til
- i dag
- dagens
- sammen
- token
- tokens
- TONE
- verktøy
- topp
- Totalt
- tradisjonelle
- Etterfølgende
- Kurs
- Transaksjoner
- Transform
- transformasjoner
- sant
- prøve
- to
- typen
- typer
- forstå
- forståelse
- I motsetning til
- avdukingen
- URL
- bruke
- bruk sak
- brukt
- Brukere
- bruker
- ved hjelp av
- benyttes
- utnytte
- v1
- verdi
- Verdier
- variabel
- ulike
- enorme
- allsidig
- versjon
- av
- Se
- volumer
- walkthrough
- ønsker
- var
- Vei..
- we
- web
- webtjenester
- uke
- VI VIL
- Hva
- når
- hvilken
- mens
- HVEM
- vil
- med
- innenfor
- uten
- vitne
- ord
- ord
- Arbeid
- arbeidsflyt
- arbeidsflyt
- arbeid
- virker
- verden
- ville
- skrevet
- X
- år
- Du
- zephyrnet