Det här inlägget är skrivet tillsammans med Stanislav Yeshchenko från Q4 Inc.
Företag vänder sig till Retrieval Augmented Generation (RAG) som en vanlig metod för att bygga Q&A chatbots. Vi fortsätter att se nya utmaningar som härrör från arten av utbudet av tillgängliga datauppsättningar. Dessa datamängder är ofta en blandning av numerisk och textdata, ibland strukturerad, ostrukturerad eller semistrukturerad.
Q4 Inc. behövde ta itu med några av dessa utmaningar i ett av deras många AI-användningsfall byggda på AWS. I det här inlägget diskuterar vi ett användningsfall för Q&A-bot som Q4 har implementerat, de utmaningar som numeriska och strukturerade datauppsättningar presenterade och hur Q4 drog slutsatsen att användning av SQL kan vara en hållbar lösning. Slutligen tar vi en närmare titt på hur Q4-teamet använde Amazonas berggrund och SQLDatabaseChain för att implementera en RAG-baserad lösning med SQL-generering.
Använda fallöversikt
Q4 Inc., med huvudkontor i Toronto, med kontor i New York och London, är en ledande plattform för tillgång till kapitalmarknader som förändrar hur emittenter, investerare och säljare effektivt ansluter, kommunicerar och interagerar med varandra. Q4-plattformen underlättar interaktioner över kapitalmarknaderna genom IR-webbplatsprodukter, lösningar för virtuella evenemang, engagemangsanalys, investerarrelationer Customer Relationship Management (CRM), aktieägar- och marknadsanalys, övervakning och ESG-verktyg.
I dagens snabba och datadrivna finansiella landskap spelar Investor Relations Officers (IROS) en avgörande roll för att främja kommunikationen mellan ett företag och dess aktieägare, analytiker och investerare. Som en del av sina dagliga uppgifter analyserar IRO olika datauppsättningar, inklusive CRM, ägarregister och aktiemarknadsdata. Sammantaget av dessa data används för att generera finansiella rapporter, sätta upp mål för investerarrelationer och hantera kommunikationen med befintliga och potentiella investerare.
För att möta den växande efterfrågan på effektiv och dynamisk datahämtning, syftade Q4 till att skapa ett chatbot Q&A-verktyg som skulle ge en intuitiv och enkel metod för IRO:er att få tillgång till den nödvändiga informationen de behöver i ett användarvänligt format.
Slutmålet var att skapa en chatbot som sömlöst skulle integrera offentligt tillgänglig data, tillsammans med egen kundspecifik Q4-data, samtidigt som den högsta nivån av säkerhet och dataintegritet bibehölls. När det gäller prestanda var målet att bibehålla en svarstid för frågor på sekunder för att säkerställa en positiv upplevelse för slutanvändarna.
Finansmarknaderna är en reglerad bransch med höga insatser involverade. Att tillhandahålla felaktig eller föråldrad information kan påverka investerarnas och aktieägarnas förtroende, förutom andra möjliga datasekretessrisker. För att förstå branschen och kraven, sätter Q4 datasekretess och svarsnoggrannhet som sina vägledande principer för att utvärdera en lösning innan den kan tas ut på marknaden.
Som proof of concept beslutade Q4 att använda en datauppsättning för finansiellt ägande. Datauppsättningen består av tidsseriedatapunkter som representerar antalet ägda tillgångar; transaktionshistoriken mellan investeringsinstitut, individer och offentliga företag; och många fler element.
Eftersom Q4 ville säkerställa att det kunde uppfylla alla funktionella och icke-funktionella krav som vi har diskuterat, behövde projektet också förbli kommersiellt genomförbart. Detta respekterades under hela processen med att besluta om tillvägagångssätt, arkitektur, val av teknik och lösningsspecifika element.
Experiment och utmaningar
Det var tydligt från början att för att förstå en mänsklig språkfråga och generera korrekta svar, skulle Q4 behöva använda stora språkmodeller (LLM).
Följande är några av experimenten som genomfördes av teamet, tillsammans med de utmaningar som identifierats och lärdomar:
- Förträning – Q4 förstod komplexiteten och utmaningarna som följer med att förträna en LLM med hjälp av sin egen datauppsättning. Det blev snabbt uppenbart att detta tillvägagångssätt är resurskrävande med många icke-triviala steg, såsom förbearbetning av data, utbildning och utvärdering. Utöver insatsen skulle det vara kostsamt. Med tanke på arten av tidsseriedataset insåg Q4 också att det kontinuerligt skulle behöva utföra inkrementell förträning allt eftersom ny data kom in. Detta skulle ha krävt ett dedikerat tvärvetenskapligt team med expertis inom datavetenskap, maskininlärning och domän kunskap.
- Finjustering – Att finjustera en förutbildad grundmodell (FM) involverade att använda flera märkta exempel. Detta tillvägagångssätt visade viss initial framgång, men i många fall var modellhallucination en utmaning. Modellen kämpade för att förstå nyanserade kontextuella ledtrådar och gav felaktiga resultat.
- RAG med semantisk sökning – Konventionell RAG med semantisk sökning var det sista steget innan man gick över till SQL-generering. Teamet experimenterade med att använda sökning, semantisk sökning och inbäddningar för att extrahera sammanhang. Under inbäddningsexperimentet konverterades datasetet till inbäddningar, lagrades i en vektordatabas och matchades sedan med inbäddningarna av frågan för att extrahera sammanhang. Den hämtade kontexten i något av de tre experimenten användes sedan för att utöka den ursprungliga prompten som en input till LLM. Detta tillvägagångssätt fungerade bra för textbaserat innehåll, där data består av naturligt språk med ord, meningar och stycken. Med tanke på karaktären på Q4:s datauppsättning, som mestadels är finansiell data bestående av siffror, finansiella transaktioner, aktiekurser och datum, var resultaten i alla tre fallen suboptimala. Även vid användning av inbäddningar kämpade de inbäddningar som genererades från siffror med likhetsrankning, och ledde i många fall till att felaktig information hämtades.
Q4:s slutsats: Att generera SQL är vägen framåt
Med tanke på de utmaningar som ställs inför med konventionell RAG-metodik började teamet överväga SQL-generering. Tanken var att använda LLM för att först generera en SQL-sats från användarfrågan, presenterad för LLM på naturligt språk. Den genererade frågan körs sedan mot databasen för att hämta den relevanta kontexten. Kontexten används slutligen för att utöka inmatningsuppmaningen för ett summeringssteg.
Q4:s hypotes var att för att få högre minne för hämtningssteget, specifikt för den numeriska datamängden, behövde de först generera SQL från användarfrågan. Detta ansågs inte bara öka noggrannheten, utan också hålla sammanhanget inom affärsdomänen för en given fråga. För frågegenereringen och för att generera korrekt SQL behövde Q4 göra LLM fullt medveten om sin datauppsättningsstruktur. Detta innebar den uppmaning som behövdes för att inkludera databasschemat, några exempeldatarader och läsbara fältförklaringar för fälten som inte är lätta att förstå.
Baserat på de första testerna visade denna metod utmärkta resultat. LLM utrustad med all nödvändig information kunde generera rätt SQL, som sedan kördes mot databasen för att hämta rätt kontext. Efter att ha experimenterat med idén beslutade Q4 att SQL-generering var vägen framåt för att ta itu med utmaningar för kontextextraktion för sin egen specifika dataset.
Låt oss börja med att beskriva den övergripande lösningen, dela upp den till dess komponenter och sätt sedan ihop delarna.
Lösningsöversikt
LLM:er är stora modeller med miljarder parametrar som är förtränade med hjälp av mycket stora mängder data från en mängd olika källor. På grund av bredden på utbildningsdatauppsättningarna förväntas LLM:er ha allmän kunskap inom en mängd olika domäner. LLM:er är också kända för sina resonemangsförmåga, som varierar från en modell till en annan. Detta allmänna beteende kan optimeras för en specifik domän eller bransch genom att ytterligare optimera en grundmodell med hjälp av ytterligare domänspecifika förträningsdata eller genom att finjustera med märkta data. Med rätt kontext, metadata och instruktioner kan en väl utvald allmän LLM producera SQL av god kvalitet så länge den har tillgång till rätt domänspecifik kontext.
I Q4:s use case börjar vi med att översätta kundfrågan till SQL. Vi gör detta genom att kombinera användarfrågan, databasschemat, några exempeldatabasrader och detaljerade instruktioner som en uppmaning till LLM att generera SQL. Efter att vi har SQL kan vi köra ett valideringssteg om det anses nödvändigt. När vi är nöjda med kvaliteten på SQL kör vi frågan mot databasen för att hämta den relevanta kontexten som vi behöver för följande steg. Nu när vi har det relevanta sammanhanget kan vi skicka användarens ursprungliga fråga, det hämtade sammanhanget och en uppsättning instruktioner tillbaka till LLM för att producera ett slutligt sammanfattat svar. Målet med det sista steget är att få LLM att sammanfatta resultaten och ge ett kontextuellt och korrekt svar som sedan kan skickas vidare till användaren.
Valet av LLM som används i varje steg av processen påverkar noggrannheten, kostnaden och prestandan i hög grad. Att välja en plattform eller teknik som kan ge dig flexibiliteten att växla mellan LLM:er inom samma användningsfall (flera LLM-resor för olika uppgifter), eller över olika användningsfall, kan vara fördelaktigt för att optimera kvaliteten på output, latens och kostnad . Vi tar upp valet av LLM längre fram i detta inlägg.
Lösning byggstenar
Nu när vi har lyft fram tillvägagångssättet på en hög nivå, låt oss dyka ner i detaljerna, börja med lösningens byggstenar.
Amazonas berggrund
Amazon Bedrock är en fullt hanterad tjänst som erbjuder ett urval av högpresterande FM:er från ledande företag, inklusive AI21 Labs, Anthropic, Cohere, Meta, Stability AI och Amazon. Amazon Bedrock erbjuder också en bred uppsättning verktyg som behövs för att bygga generativa AI-applikationer, förenkla utvecklingsprocessen och upprätthålla integritet och säkerhet. Dessutom kan du med Amazon Bedrock välja mellan olika FM-alternativ, och du kan finjustera modellerna ytterligare privat med hjälp av din egen data för att anpassa modellernas svar med dina användningsfallskrav. Amazon Bedrock är helt serverlöst utan underliggande infrastruktur för att hantera utökad åtkomst till tillgängliga modeller genom ett enda API. Slutligen stöder Amazon Bedrock flera säkerhets- och integritetskrav, inklusive HIPAA-kvalificering och GDPR-efterlevnad.
I Q4:s lösning använder vi Amazon Bedrock som en serverlös, API-baserad modellbyggsten med flera grunder. Eftersom vi avser att göra flera resor till LLM inom samma användningsfall, baserat på uppgiftstypen, kan vi välja den modell som är mest optimal för en specifik uppgift, vare sig det är SQL-generering, validering eller sammanfattning.
Langkedja
Langkedja är ett ramverk för öppen källkod för integration och orkestrering med en uppsättning förbyggda moduler (I/O, hämtning, kedjor och agenter) som du kan använda för att integrera och orkestrera uppgifter mellan FM:er, datakällor och verktyg. Ramverket underlättar att bygga generativa AI-applikationer som kräver orkestrering av flera steg för att producera önskad utdata, utan att behöva skriva kod från början. LangChain stöder Amazon Bedrock som en multi-foundation modell API.
Specifikt för Q4:s användningsfall använder vi LangChain för att koordinera och orkestrera uppgifter i vårt arbetsflöde, inklusive anslutning till datakällor och LLM. Detta tillvägagångssätt har förenklat vår kod eftersom vi kan använda de befintliga LangChain-modulerna.
SQLDatabaseChain
SQLDatabaseChain är en LangChain-kedja som kan importeras från langchain_experimental. SLDatabaseChain gör det enkelt att skapa, implementera och köra SQL-frågor, med hjälp av dess effektiva text-till-SQL-konverteringar och implementeringar.
I vårt användningsfall använder vi SQLDatabaseChain i SQL-genereringen, vilket förenklar och orkestrerar interaktioner mellan databasen och LLM.
Datauppsättningen
Vår strukturerade datauppsättning kan finnas i en SQL-databas, datasjö eller datalager så länge vi har stöd för SQL. I vår lösning kan vi använda vilken datauppsättningstyp som helst med SQL-stöd; detta bör abstraheras från lösningen och bör inte ändra lösningen på något sätt.
Implementeringsdetaljer
Nu när vi har utforskat lösningssättet, lösningskomponenterna, valet av teknik och verktyg kan vi sätta ihop bitarna. Följande diagram belyser helhetslösningen.
Låt oss gå igenom implementeringsdetaljerna och processflödet.
Generera SQL-frågan
För att förenkla kodningen använder vi befintliga ramverk. Vi använder LangChain som ett orkestreringsramverk. Vi börjar med inmatningssteget, där vi får användarfrågan på naturligt språk.
I detta första steg tar vi denna ingång och genererar en motsvarande SQL som vi kan köra mot databasen för kontextextraktion. För att generera SQL använder vi SQLDatabaseChain, som förlitar sig på Amazon Bedrock för tillgång till vår önskade LLM. Med Amazon Bedrock, med ett enda API, får vi tillgång till ett antal underliggande LLM:er och kan välja rätt för varje LLM-resa vi gör. Vi upprättar först en anslutning till databasen och hämtar det nödvändiga tabellschemat tillsammans med några exempelrader från de tabeller vi tänker använda.
I vår testning fann vi att 2–5 rader med tabelldata var tillräckliga för att ge tillräckligt med information till modellen utan att lägga till för mycket onödig overhead. Tre rader var precis tillräckligt för att ge sammanhang, utan att överväldiga modellen med för mycket input. I vårt användningsfall började vi med Anthropic Claude V2. Modellen är känd för sina avancerade resonemang och artikulera kontextuella svar när den är försedd med rätt sammanhang och instruktioner. Som en del av instruktionerna kan vi inkludera mer förtydligande detaljer till LLM. Till exempel kan vi beskriva den kolumnen Comp_NAME
står för företagets namn. Vi kan nu konstruera prompten genom att kombinera användarfrågan som den är, databasschemat, tre exempelrader från tabellen vi tänker använda och en uppsättning instruktioner för att generera den nödvändiga SQL-koden i rent SQL-format utan kommentarer eller tillägg.
Alla kombinerade inmatningselement betraktas som modellinmatningsprompten. En välkonstruerad ingångsuppmaning som är skräddarsydd för modellens föredragna syntax påverkar i hög grad både kvaliteten och prestandan på resultatet. Valet av modell att använda för en specifik uppgift är också viktigt, inte bara för att det påverkar utskriftskvaliteten, utan också för att det har konsekvenser för kostnader och prestanda.
Vi diskuterar modellval och snabb konstruktion och optimering senare i det här inlägget, men det är värt att notera att för frågegenereringsstadiet märkte vi att Claude Instant kunde producera jämförbara resultat, särskilt när användarfrågan är välformulerad och inte lika sofistikerad. Claude V2 gav dock bättre resultat även med mer komplex och indirekt användarinput. Vi lärde oss att även om det i vissa fall Claude Instant kan ge tillräcklig noggrannhet till en bättre fördröjning och pris, var vårt fall för frågegenerering bättre lämpat för Claude V2.
Verifiera SQL-frågan
Vårt nästa steg är att verifiera att LLM framgångsrikt har genererat rätt frågesyntax och att frågan är kontextuell med tanke på databasscheman och exempelraderna. För detta verifieringssteg kan vi återgå till inbyggd frågevalidering inom SQLDatabaseChain, eller så kan vi köra en andra resa till LLM inklusive frågan som genereras tillsammans med valideringsinstruktioner.
Om vi använder en LLM för valideringssteget kan vi använda samma LLM som tidigare (Claude V2) eller en mindre, mer presterande LLM för en enklare uppgift, som Claude Instant. Eftersom vi använder Amazon Bedrock bör detta vara en väldigt enkel justering. Med samma API kan vi ändra modellnamnet i vårt API-anrop, som tar hand om förändringen. Det är viktigt att notera att i de flesta fall kan en mindre LLM ge bättre effektivitet i både kostnad och latens och bör övervägas – så länge du får den önskade noggrannheten. I vårt fall visade testning att den genererade frågan var konsekvent korrekt och med rätt syntax. Eftersom vi visste det kunde vi hoppa över det här valideringssteget och spara på latens och kostnad.
Kör SQL-frågan
Nu när vi har den verifierade SQL-frågan kan vi köra SQL-frågan mot databasen och hämta den relevanta kontexten. Detta borde vara ett enkelt steg.
Vi tar det genererade sammanhanget, ger det till den LLM som vi väljer med den första användarfrågan och lite instruktioner, och ber modellen att generera en kontextuell och artikulerad sammanfattning. Vi presenterar sedan den genererade sammanfattningen för användaren som ett svar på den initiala frågan, allt i linje med sammanhanget som extraherats från vår datauppsättning.
För den LLM som är involverad i sammanfattningssteget kan vi använda antingen Titan Text Express eller Claude Instant. De skulle båda presentera bra alternativ för sammanfattningsuppgiften.
Applikationsintegration
Fråge- och svar-chatbot-möjligheten är en av Q4:s AI-tjänster. För att säkerställa modularitet och skalbarhet bygger Q4 AI-tjänster som mikrotjänster som är tillgängliga för Q4-applikationer via API:er. Detta API-baserade tillvägagångssätt möjliggör sömlös integration med Q4 Platform-ekosystemet och underlättar att exponera AI-tjänsternas kapacitet för hela paketet av plattformsapplikationer.
Huvudsyftet med AI-tjänsterna är att tillhandahålla enkla möjligheter för att hämta data från alla offentliga eller proprietära datakällor med naturligt språk som indata. Dessutom tillhandahåller AI-tjänsterna ytterligare lager av abstraktion för att säkerställa att funktionella och icke-funktionella krav, såsom datasekretess och säkerhet uppfylls. Följande diagram visar integrationskonceptet.
Implementeringsutmaningar
Utöver de utmaningar som karaktären av den strukturerade, numeriska datamängden som vi diskuterade tidigare, ställdes Q4 inför ett antal andra implementeringsutmaningar som behövde åtgärdas.
LLM val och prestanda
Att välja rätt LLM för uppgiften är avgörande eftersom det direkt påverkar kvaliteten på produktionen såväl som prestandan (tur och retur latens). Här är några faktorer som spelar in i urvalsprocessen för LLM:
- Typ av LLM – Sättet som FM:erna är uppbyggda på och de initiala data som modellen har förtränats på avgör vilka typer av uppgifter som LLM skulle vara bra på och hur bra den kommer att bli. Till exempel skulle en text LLM vara bra på textgenerering och sammanfattning, medan en text-till-bild- eller bild-till-text-modell skulle vara mer inriktad på bildanalys och genereringsuppgifter.
- LLM storlek – FM-storlekar mäts av antalet modellparametrar en viss modell har, vanligtvis i miljarder för moderna LLM. Vanligtvis, ju större modell, desto dyrare att initialt träna eller efterhand finjustera. Å andra sidan, i allmänhet, för samma modellarkitektur, ju större modellen är, desto smartare förväntar vi oss att den ska vara i att utföra den typ av uppgift den är inriktad på.
- LLM prestanda – Ju större modellen är, desto mer tid tar det att generera utdata, förutsatt att du använder samma beräknings- och I/O-parametrar (prompt och utdatastorlek). Dessutom, för samma modellstorlek, påverkas prestandan i hög grad av hur optimerad din prompt är, storleken på I/O-tokens och tydligheten och syntaxen för prompten. En välkonstruerad prompt, tillsammans med en optimerad I/O-tokenstorlek, kan förbättra modellens svarstid.
Tänk därför på följande bästa praxis när du optimerar din uppgift:
- Välj en modell som är lämplig för uppgiften
- Välj den minsta modellstorleken som kan ge den noggrannhet du letar efter
- Optimera din promptstruktur och var så specifik som möjligt med instruktionerna på ett sätt som är lätt för modellen att förstå
- Använd den minsta inmatningsuppmaningen som kan ge tillräckligt med instruktioner och sammanhang för att producera den noggrannhetsnivå du letar efter
- Begränsa utskriftsstorleken till den minsta storleken som kan vara meningsfull för dig och tillfredsställa dina utskriftskrav
Med hänsyn till modellvalet och prestandaoptimeringsfaktorerna gick vi igång med att optimera vårt användningsfall för SQL-generering. Efter lite testning märkte vi att, förutsatt att vi har rätt sammanhang och instruktioner, skulle Claude Instant, med samma snabba data, producera jämförbar kvalitet på SQL som Claude V2 till en mycket bättre prestanda och pris. Detta gäller när användarinmatningen är mer direkt och enklare till sin natur. För mer sofistikerad input var Claude V2 nödvändig för att producera önskad noggrannhet.
Att tillämpa samma logik på sammanfattningsuppgiften fick oss att dra slutsatsen att användning av Claude Instant eller Titan Text Express skulle ge den noggrannhet som krävs vid en mycket bättre prestandapunkt än om vi använder en större modell som Claude V2. Titan Text Expressed erbjöd också bättre pris-prestanda, som vi diskuterade tidigare.
Orkestreringsutmaningen
Vi insåg att det är mycket att orkestrera innan vi kan få ett meningsfullt outputsvar för användarfrågan. Som framgår av lösningsöversikten involverade processen flera databasresor och flera LLM-resor som är sammanflätade. Om vi skulle bygga från grunden hade vi behövt göra en betydande investering i de odifferentierade tunga lyften bara för att få grundkoden klar. Vi gick snabbt över till att använda LangChain som ett orkestreringsramverk, dra nytta av kraften i open source-gemenskapen och återanvända befintliga moduler utan att återuppfinna hjulet.
SQL-utmaningen
Vi insåg också att generering av SQL inte är så enkelt som kontextextraktionsmekanismer som semantisk sökning eller att använda inbäddningar. Vi måste först få databasschemat och några exempelrader att inkludera i vår prompt till LLM. Det finns också SQL-valideringsstadiet, där vi behövde interagera med både databasen och LLM. SQLDatabaseChain var det självklara valet av verktyg. Eftersom det är en del av LangChain var det enkelt att anpassa, och nu kan vi hantera SQL-genereringen och verifieringen med hjälp av kedjan, vilket minimerar mängden arbete vi behövde göra.
Prestandautmaningar
Med användning av Claude V2, och efter korrekt prompt ingenjörskonst (som vi diskuterar i nästa avsnitt), kunde vi producera högkvalitativ SQL. Med tanke på kvaliteten på den genererade SQL-koden började vi titta på hur mycket värde valideringssteget faktiskt tillför. Efter att ha analyserat resultaten ytterligare stod det klart att kvaliteten på den genererade SQL-koden var konsekvent korrekt på ett sätt som gjorde kostnaden/nyttan av att lägga till ett SQL-valideringssteg ogynnsamt. Det slutade med att vi eliminerade SQL-valideringssteget utan att negativt påverka kvaliteten på vår produktion och rakade bort SQL-valideringens tur och retur.
Förutom att optimera för en mer kostnads- och prestandaeffektiv LLM för summeringssteget kunde vi använda Titan Text Express för att få bättre prestanda och kostnadseffektivitet.
Ytterligare prestandaoptimering involverade finjustering av frågegenereringsprocessen med hjälp av effektiva snabba ingenjörstekniker. Istället för att tillhandahålla ett överflöd av tokens låg fokus på att tillhandahålla minsta möjliga mängd indatatokens, i rätt syntax som modellen är tränad att förstå, och med den minimala men ändå optimala uppsättningen instruktioner. Vi diskuterar detta mer i nästa avsnitt – det är ett viktigt ämne som är tillämpligt inte bara här utan även i andra användningsfall.
Snabb konstruktion och optimering
Du kan anpassa Claude på Amazon Bedrock för olika affärsanvändningsfall om rätt snabba ingenjörstekniker används. Claude agerar huvudsakligen som en samtalsassistent som använder ett mänskligt/assistentformat. Claude är utbildad att fylla i text för assistentrollen. Med de instruktioner och snabba kompletteringar som önskas kan vi optimera våra uppmaningar för Claude med hjälp av flera tekniker.
Vi börjar med en korrekt formaterad promptmall som ger en giltig komplettering, sedan kan vi optimera svaren ytterligare genom att experimentera med prompter med olika uppsättningar indata som är representativa för verkliga data. Det rekommenderas att få många input när du utvecklar en snabbmall. Du kan också använda separata uppsättningar av snabb utvecklingsdata och testdata.
Ett annat sätt att optimera Claude-svaret är att experimentera och iterera genom att lägga till regler, instruktioner och användbara optimeringar. Från dessa optimeringar kan du se olika typer av kompletteringar genom att till exempel säga till Claude att nämna "jag vet inte" för att förhindra hallucinationer, tänka steg för steg, använda snabb kedja, ge utrymme att "tänka" när det genererar svar , och dubbelkolla för förståelse och noggrannhet.
Låt oss använda vår frågegenereringsuppgift och diskutera några av de tekniker vi använde för att optimera vår prompt. Det fanns några kärnelement som gynnade våra ansträngningar för att generera frågor:
- Använder rätt syntax för människa/assistent
- Använda XML-taggar (Claude respekterar och förstår XML-taggar)
- Lägger till tydliga instruktioner för modellen för att förhindra hallucinationer
Följande generiska exempel visar hur vi använde human/assistent-syntaxen, tillämpade XML-taggar och lade till instruktioner för att begränsa utdata till SQL och instruera modellen att säga "förlåt, jag kan inte hjälpa" om den inte kan producera relevant SQL . XML-taggarna användes för att rama in instruktionerna, ytterligare tips, databasschema, ytterligare tabellförklaringar och exempelrader.
Den slutliga fungerande lösningen
Efter att vi hade tagit itu med alla utmaningar som identifierats under proof of concept, hade vi uppfyllt alla lösningskrav. Q4 var nöjd med kvaliteten på SQL som genererades av LLM. Detta gäller för enkla uppgifter som bara krävde en WHERE-sats för att filtrera data, och även för mer komplexa uppgifter som krävde kontextbaserade aggregationer med GROUP BY och matematiska funktioner. Slut-till-änd-latensen för den övergripande lösningen kom inom vad som definierades som acceptabelt för användningsfallet - ensiffriga sekunder. Detta var allt tack vare valet av en optimal LLM i varje steg, korrekt prompt ingenjörskonst, eliminering av SQL-verifieringssteget och användning av en effektiv LLM för summeringssteget (Titan Text Express eller Claude Instant).
Det är värt att notera att användningen av Amazon Bedrock som en fullständigt hanterad tjänst och möjligheten att ha tillgång till en svit av LLM:er via samma API möjliggjorde experiment och sömlös växling mellan LLM:er genom att ändra modellnamnet i API-anropet. Med denna flexibilitetsnivå kunde Q4 välja den mest presterande LLM för varje LLM-samtal baserat på uppgiftens natur, vare sig det var frågagenerering, verifiering eller sammanfattning.
Slutsats
Det finns ingen lösning som passar alla användningsfall. I ett RAG-tillvägagångssätt beror kvaliteten på resultatet i hög grad på att tillhandahålla rätt sammanhang. Att extrahera rätt sammanhang är nyckeln, och varje datauppsättning är annorlunda med sina unika egenskaper.
I det här inlägget visade vi att för numeriska och strukturerade datamängder kan användning av SQL för att extrahera sammanhanget som används för förstärkning leda till mer gynnsamma resultat. Vi visade också att ramverk som LangChain kan minimera kodningsarbetet. Dessutom diskuterade vi behovet av att kunna växla mellan LLM inom samma användningsfall för att uppnå den mest optimala noggrannheten, prestanda och kostnad. Slutligen lyfte vi fram hur Amazon Bedrock, som är serverlös och med en mängd olika LLM:er under huven, ger den flexibilitet som behövs för att bygga säkra, presterande och kostnadsoptimerade applikationer med minsta möjliga tunga lyft.
Börja din resa mot att bygga generativa AI-aktiverade applikationer genom att identifiera ett användningsfall av värde för ditt företag. SQL-generering, som Q4-teamet lärde sig, kan vara en game changer när det gäller att bygga smarta applikationer som integreras med dina datalager, vilket frigör intäktspotential.
Om författarna
Tamer Soliman är Senior Solutions Architect på AWS. Han hjälper Independent Software Vendor-kunder (ISV) att förnya, bygga och skala på AWS. Han har över två decennier av branscherfarenhet av rådgivning, utbildning och professionella tjänster. Han är en multipatentuppfinnare med tre beviljade patent och hans erfarenhet spänner över flera teknikdomäner inklusive telekom, nätverk, applikationsintegration, AI/ML och molninstallationer. Han är specialiserad på AWS-nätverk och har en djup passion för maskinlutning, AI och Generativ AI.
Mani Khanuja är en teknisk ledare – Generativa AI-specialister, författare till boken – Applied Machine Learning and High Performance Computing on AWS, och medlem i styrelsen för Women in Manufacturing Education Foundation Board. Hon leder maskininlärningsprojekt (ML) inom olika domäner som datorseende, naturlig språkbehandling och generativ AI. Hon hjälper kunder att bygga, träna och implementera stora maskininlärningsmodeller i stor skala. Hon talar i interna och externa konferenser som re:Invent, Women in Manufacturing West, YouTube webinars och GHC 23. På fritiden gillar hon att gå långa löpturer längs stranden.
Stanislav Jesjtjenko är en mjukvaruarkitekt på Q4 Inc.. Han har över ett decennium av branscherfarenhet av mjukvaruutveckling och systemarkitektur. Hans mångsidiga bakgrund som spänner över roller som teknisk ledare och Senior Full Stack-utvecklare, driver hans bidrag till att främja innovationen av Q4-plattformen. Stanislav är dedikerad till att driva teknisk innovation och forma strategiska lösningar på området.
- SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
- PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
- PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
- Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
- PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
- Källa: https://aws.amazon.com/blogs/machine-learning/how-q4-inc-used-amazon-bedrock-rag-and-sqldatabasechain-to-address-numerical-and-structured-dataset-challenges-building-their-qa-chatbot/
- : har
- :är
- :inte
- :var
- $UPP
- 100
- 118
- 125
- 15%
- 23
- 7
- a
- förmågor
- förmåga
- Able
- abstraktion
- överflöd
- godtagbart
- tillgång
- tillgänglig
- Konto
- noggrannhet
- exakt
- Uppnå
- tvärs
- handlingar
- faktiskt
- anpassa
- lagt till
- tillsats
- Dessutom
- Annat
- Dessutom
- tillsatser
- adress
- adresserad
- Justering
- avancerat
- Vidare
- Fördel
- Efter
- mot
- medel
- aggregat
- AI
- AI-tjänster
- ai användningsfall
- AI / ML
- syftar
- rikta
- Justerat
- Alla
- tillåter
- tillåts
- längs
- också
- Även
- am
- amason
- Amazon Web Services
- mängd
- mängder
- an
- analys
- analytiker
- analytics
- analysera
- analys
- och
- Annan
- svara
- svar
- Antropisk
- vilken som helst
- något
- api
- API: er
- tillämplig
- Ansökan
- tillämpningar
- tillämpas
- tillvägagångssätt
- arkitektur
- ÄR
- AS
- be
- Tillgångar
- Assistent
- assisterad
- sortiment
- At
- förstärka
- augmented
- Författaren
- tillgänglig
- medveten
- AWS
- tillbaka
- bakgrund
- baserat
- grundläggande
- BE
- Beach
- blev
- därför att
- varit
- innan
- Börjar
- beteende
- Där vi får lov att vara utan att konstant prestera,
- tros
- fördelaktigt
- BÄST
- bästa praxis
- Bättre
- mellan
- miljarder
- Blockera
- Block
- ombord
- styrelse
- boken
- Bot
- båda
- bredd
- Ha sönder
- bred
- SLUTRESULTAT
- Byggnad
- bygger
- byggt
- företag
- men
- by
- Ring
- kom
- KAN
- Kan få
- kapacitet
- kapacitet
- kapital
- Kapitalmarknader
- vilken
- Vid
- fall
- kedja
- kedjor
- utmanar
- utmaningar
- utmanar byggandet
- byta
- Växlare
- byte
- egenskaper
- chatbot
- chatbots
- val
- Välja
- välja
- klarhet
- rena
- klar
- närmare
- cloud
- koda
- Kodning
- Kolumn
- kombinerad
- kombinera
- komma
- kommentarer
- kommersiellt
- kommunicera
- Kommunikation
- samfundet
- Företag
- företag
- jämförbar
- fullbordan
- komplex
- Komplexiteten
- Efterlevnad
- komponenter
- förstå
- Compute
- dator
- Datorsyn
- databehandling
- begrepp
- avslutar
- ingås
- slutsats
- genomfördes
- konferenser
- Kontakta
- Anslutning
- anslutning
- Tänk
- anses
- med tanke på
- konsekvent
- Bestående
- består
- konstruera
- rådgivning
- innehåll
- sammanhang
- kontextuella
- fortsätta
- kontinuerligt
- bidrag
- konventionell
- konversera
- omvandlingar
- konverterad
- samordnande
- Kärna
- korrekt
- Pris
- kunde
- skapa
- kritisk
- CRM
- avgörande
- kund
- Kunder
- dagligen
- datum
- datasjö
- datapunkter
- dataintegritet
- Datas integritet och säkerhet
- datavetenskap
- data driven
- Databas
- datauppsättningar
- Datum
- årtionde
- årtionden
- beslutade
- Avgörande
- dedicerad
- anses
- definierade
- Efterfrågan
- demonstreras
- demonstrerar
- beror
- distribuera
- distributioner
- beskriva
- beskriver
- önskas
- detaljerad
- detaljer
- bestämd
- Utvecklare
- utveckla
- Utveckling
- olika
- rikta
- direkt
- Direktörer
- diskutera
- diskuteras
- Dyk
- flera
- do
- domän
- domäner
- inte
- dubbelkolla
- ner
- drivande
- grund
- under
- dynamisk
- varje
- Tidigare
- lätt
- ekosystemet
- Utbildning
- Effektiv
- effektivitet
- effektiv
- effektivt
- ansträngning
- ansträngningar
- antingen
- element
- berättigande
- eliminera
- smärgel
- anställd
- möjliggör
- änden
- början till slut
- avslutades
- engagera
- ingrepp
- Teknik
- tillräckligt
- säkerställa
- utrustad
- Motsvarande
- ESG
- speciellt
- etablera
- utvärdering
- utvärdering
- Även
- händelser
- Varje
- exempel
- exempel
- befintliga
- förvänta
- förväntat
- dyra
- erfarenhet
- experimentera
- experiment
- expert
- expertis
- utforskas
- uttrycker
- uttryckt
- sträcker
- extern
- extrahera
- extraktion
- inför
- underlättar
- faktorer
- snabb
- gynnsam
- möjlig
- få
- fält
- Fält
- fylla
- filtrera
- slutlig
- Slutligen
- finansiella
- finansiella data
- Förnamn
- Flexibilitet
- flöda
- Fokus
- följer
- efter
- För
- format
- Framåt
- främja
- hittade
- fundament
- RAM
- Ramverk
- ramar
- Fri
- från
- full
- Full stack
- fullständigt
- funktionella
- funktioner
- ytterligare
- lek
- spel-växlare
- GDPR
- GDPR-överensstämmelse
- utrustad
- Allmänt
- generera
- genereras
- genererar
- generera
- generering
- generativ
- Generativ AI
- skaffa sig
- få
- Ge
- ges
- ger
- Ge
- Go
- Målet
- Mål
- god
- beviljats
- stor
- Grupp
- Odling
- hade
- sidan
- lyckligt
- Har
- har
- he
- huvudkontor
- tung
- tunga lyft
- hjälpa
- hjälper
- här
- här.
- Hög
- högpresterande
- hög kvalitet
- högre
- högsta
- Markerad
- höjdpunkter
- höggradigt
- tips
- hans
- historia
- huva
- Hur ser din drömresa ut
- Men
- HTTPS
- humant
- läsbar
- i
- Tanken
- identifierade
- identifiera
- if
- bild
- Inverkan
- påverkade
- slag
- Konsekvenser
- genomföra
- genomförande
- implementeringar
- genomföras
- implikationer
- med Esport
- förbättra
- in
- I andra
- Inc.
- innefattar
- Inklusive
- Öka
- steg
- oberoende
- individer
- industrin
- informationen
- Infrastruktur
- inledande
- initialt
- förnya
- Innovation
- ingång
- ingångar
- omedelbar
- institutioner
- instruktioner
- integrera
- integrering
- avser
- interagera
- interaktioner
- inre
- sammanflätade
- in
- intuitiv
- investering
- investerare
- För Investerare
- involverade
- utfärdare
- ISV
- IT
- DESS
- resa
- jpg
- bara
- Ha kvar
- Nyckel
- Menande
- kunskap
- känd
- Labs
- sjö
- liggande
- språk
- Large
- större
- Efternamn
- slutligen
- Latens
- senare
- skikt
- leda
- ledande
- Leads
- lärt
- inlärning
- t minst
- Led
- Lärdomar
- Lärdomar
- Nivå
- lyft
- tycka om
- gillar
- LLM
- Logiken
- london
- Lång
- se
- du letar
- Lot
- Maskinen
- maskininlärning
- gjord
- Huvudsida
- huvudsakligen
- Vanliga
- bibehålla
- upprätthålla
- göra
- GÖR
- hantera
- förvaltade
- ledning
- Produktion
- många
- marknad
- Marknadsanalys
- Market Data
- Marknader
- matchas
- matematisk
- Maj..
- meningsfull
- menas
- mekanismer
- Möt
- medlem
- träffade
- meta
- metadata
- metod
- Metodik
- microservices
- minimum
- minimerande
- Blanda
- ML
- modell
- modeller
- Modern Konst
- Moduler
- mer
- mest
- för det mesta
- rörliga
- mycket
- flera
- multipel
- namn
- nativ
- Natural
- Naturlig språkbehandling
- Natur
- nödvändigt för
- Behöver
- behövs
- negativt
- nätverk
- Nya
- New York
- Nästa
- Nej
- Notera
- notera
- nu
- antal
- nummer
- mål
- Uppenbara
- of
- sänkt
- erbjuds
- Erbjudanden
- officerare
- kontor
- Ofta
- on
- ONE
- endast
- öppet
- öppen källkod
- optimala
- optimering
- Optimera
- optimerad
- optimera
- Tillbehör
- or
- orkestrerar
- orkestrering
- beställa
- ursprungliga
- Övriga
- vår
- produktion
- över
- övergripande
- Översikt
- överväldigande
- egen
- ägd
- ägande
- parametrar
- del
- särskilt
- Godkänd
- brinner
- patent
- Patent
- bana
- Utföra
- prestanda
- utför
- plocka
- bitar
- plattform
- plato
- Platon Data Intelligence
- PlatonData
- Spela
- Punkt
- poäng
- positiv
- möjlig
- Inlägg
- potentiell
- kraft
- befogenheter
- praxis
- föredragen
- presentera
- presenteras
- förhindra
- pris
- Principerna
- privatpolicy
- Integritet och säkerhet
- process
- bearbetning
- producera
- producerad
- Produkter
- professionell
- djupgående
- projektet
- projekt
- prompter
- bevis
- bevis på koncept
- rätt
- proprietary
- visat
- ge
- förutsatt
- ger
- tillhandahålla
- allmän
- offentliga företag
- publicly
- Syftet
- sätta
- Frågor och svar
- kvalitet
- sökfrågor
- fråga
- snabbt
- citat
- Rankning
- snarare
- RE
- redo
- verkliga världen
- insåg
- motta
- rekommenderas
- register
- erat
- reglerad
- relationer
- relation
- relevanta
- Rapport
- representativ
- representerar
- representerar
- kräver
- Obligatorisk
- Krav
- resurs
- respekterad
- respekterar
- respons
- svar
- begränsa
- Resultat
- intäkter
- återgå
- reviewing
- höger
- risker
- Roll
- roller
- Rum
- rund
- regler
- Körning
- kör
- Samma
- nöjd
- nöjd med
- Save
- säga
- skalbarhet
- Skala
- Vetenskap
- repa
- sömlös
- sömlöst
- Sök
- Andra
- sekunder
- §
- säkra
- säkerhet
- se
- Val
- Säljare
- sända
- senior
- känsla
- separat
- Serier
- Server
- service
- Tjänster
- in
- uppsättningar
- flera
- formning
- aktieägare
- aktieägare
- hon
- skall
- visade
- visas
- Visar
- signifikant
- Enkelt
- enklare
- förenklade
- förenkla
- förenkla
- enda
- Storlek
- storlekar
- mindre
- smarta
- smartare
- Mjukvara
- mjukvaruutveckling
- lösning
- Lösningar
- några
- sofistikerade
- Källa
- Källor
- spänning
- spann
- talar
- specialister
- specialiserat
- specifik
- specifikt
- Stabilitet
- stapel
- Etapp
- stakes
- stå
- står
- starta
- igång
- Starta
- .
- bo
- Steg
- Steg
- lager
- aktiemarknaden
- lagras
- lagrar
- okomplicerad
- Strategisk
- struktur
- strukturerade
- Senare
- framgång
- Framgångsrikt
- sådana
- tillräcklig
- lämplig
- svit
- sammanfatta
- SAMMANFATTNING
- stödja
- Stöder
- övervakning
- Växla
- syntax
- system
- bord
- skräddarsydd
- Ta
- tagen
- tar
- tar
- uppgift
- uppgifter
- grupp
- tech
- Teknisk
- tekniker
- Teknologi
- telecom
- tala
- mall
- testa
- Testning
- tester
- text
- än
- Tack
- den där
- Smakämnen
- Huvudstaden
- deras
- sedan
- Där.
- Dessa
- de
- Tänkande
- detta
- tre
- Genom
- hela
- tid
- Tidsföljder
- gånger
- titan
- till
- dagens
- tillsammans
- token
- tokens
- alltför
- verktyg
- verktyg
- ämne
- toronto
- mot
- Tåg
- tränad
- Utbildning
- transaktion
- Transaktioner
- omvandla
- tur
- sann
- Litar
- SVÄNG
- två
- Typ
- typer
- typiskt
- oförmögen
- under
- underliggande
- förstå
- förståelse
- förstår
- förstått
- unika
- upplåsning
- onödig
- us
- användning
- användningsfall
- Begagnade
- Användare
- användarvänligt
- med hjälp av
- Återvinnare
- giltigt
- godkännande
- värde
- mängd
- olika
- leverantör
- Verifiering
- verifierade
- verifiera
- mycket
- genomförbar, livskraftig
- utsikt
- Virtuell
- syn
- gå
- ville
- var
- Sätt..
- we
- webb
- webbservice
- Webbseminarier
- Webbplats
- VÄL
- begav sig
- były
- väster
- Vad
- Hjul
- när
- medan
- som
- medan
- kommer
- med
- inom
- utan
- Kvinnor
- ord
- Arbete
- arbetade
- arbetsflöde
- arbetssätt
- värt
- skulle
- skriva
- skriva kod
- XML
- ännu
- york
- Om er
- Din
- Youtube
- zephyrnet