LLM-gestuurde QA-chatbot op uw data in uw Cloud

OpenAI en LangChain hebben het heel eenvoudig gemaakt om een demo te bouwen voor het beantwoorden van vragen over uw documenten. Er zijn talloze artikelen op het internet te vinden die uitleggen hoe u dit doet. We hebben ook een werkend notebook voor het geval u end-to-end met een systeem wilt experimenteren:

‍

truefoundry-examples/docs-qa-langchain/simple op main · truefoundry/truefoundry-examples

Deze repository bevat alle projecten die worden genoemd in de demo-voorbeelden. - truefoundry/truefoundry-examples

GitHub Truefoundry

‍

In dit artikel bespreken we hoe u een vraag-antwoord-bot op uw documenten in productie neemt. We gaan deze bovendien implementeren in uw eigen cloudomgeving en maken het gebruik van open-source LLMs in plaats van OpenAI mogelijk als privacy en databeveiliging tot uw kerneisen behoren.

De belangrijkste workflow voor het bouwen van het QA-systeem met RAG (Retrieval-Augmented Generation) is als volgt:

Documenten indexeren:

1. Laad de documenten.
2. Splits de documenten in chunks van een bepaalde lengte (bijv. len).
3. Zet de chunks om in embeddings met behulp van een embeddingmodel (OpenAI-embeddings of een open-source model zoals e5-large-v2).
4. Sla de embeddings op in een VectorDB zoals Milvus, Qdrant, etc.

Het antwoord op de gebruikersvraag ophalen:

1. Zet de gebruikersvraag om in een embedding met dezelfde embedder-instellingen als voor het indexeren van de documenten.
2. Zoek de meest vergelijkbare chunks voor de query in de VectorDB.
3. Stel de prompt voor de LLM samen met behulp van de chunks.
4. Ontvang het antwoord van de LLM, zoals OpenAI-modellen of open-source modellen zoals Falcon, Llama2, etc.

RAG-architectuur

Om de hierboven beschreven workflow uit te voeren, moeten we verschillende componenten samen implementeren. Hier is het architectuurdiagram voor het implementeren van RAG in uw eigen cloud.

De belangrijkste componenten in de bovenstaande architectuur zijn:

Document Store

Dit is waar de documenten worden opgeslagen. In veel gevallen is dit AWS S3, Google Storage Buckets of Azure Blob Storage. In sommige gevallen kan deze data ook afkomstig zijn van API's, bijvoorbeeld bij Confluence-documenten. 

Indexer Job

Dit wordt op dezelfde manier gemodelleerd als een trainingstaak in ML: het ontvangt de documenten als invoer, splits deze in chunks, roept het embeddingmodel aan om de chunks om te zetten en slaat de vectoren op in de database. Het embeddingmodel kan in de taak zelf worden geladen of via een API worden aangeroepen. De API-route heeft de voorkeur, omdat het embeddingmodel dan onafhankelijk kan worden opgeschaald bij grote aantallen documenten. De taken kunnen ad-hoc worden gestart of op basis van een planning bij een continue stroom van documenten. Zodra de taak is voltooid, moet deze de status als 'Successful' opslaan in een metadatastore, samen met de embedding-instellingen.

Embeddingmodel

Als we OpenAI of een extern gehost model gebruiken, hoeven we in dit geval geen model te hosten. Gebruiken we echter een open-source model, dan moeten we dit hosten in onze cloudomgeving en de embeddings via de API ophalen.

LLM-model

Als we OpenAI of gehoste model-API's zoals Cohere en Anthropic gebruiken, hoeven we niets te implementeren; anders moeten we open-source LLMs uitrollen.

Query Service

Dit kan een FastAPI-service zijn die de API biedt om alle geïndexeerde documentcollecties op te sommen en de gebruiker in staat stelt vragen te stellen over de documentcollecties. Er is ook een API om een nieuwe indexeringstaak te starten voor een nieuwe documentcollectie.

VectorDB

We kunnen hier een gehoste oplossing zoals Pinecone gebruiken of een van de open-source VectorDB's zoals Qdrant of Milvus hosten.

Metadata Store

Dit is nodig om de links op te slaan naar de documenten die zijn geïndexeerd en te registreren welke configuratie is gebruikt om de chunks in die documenten om te zetten. Dit helpt de gebruiker de set documenten te selecteren waarin gezocht moet worden en kan meerdere documentensets binnen een organisatie ondersteunen.

Deze architectuur opzetten met TrueFoundry

TrueFoundry is een platform op Kubernetes dat het zeer eenvoudig maakt om ML-trainingstaken en -services te implementeren tegen optimale kosten. Met TrueFoundry kunnen we alle componenten in de bovenstaande architectuur uitrollen — op uw eigen cloudaccount. De uiteindelijke implementatie in uw cloud ziet er ongeveer zo uit:

Dit lijkt misschien een hele configuratie, maar we hebben al een template gemaakt waarmee u in minder dan 10 minuten aan de slag kunt. We gaan ervan uit dat u al bent aangemeld bij TrueFoundry. Als dat nog niet zo is, volgt u deze gids om aan de slag te gaan. TrueFoundry werkt op alle drie de grote cloudproviders: AWS, Azure en GCP - u kunt het dus op elk van deze cloudproviders opzetten.

We hebben een voorbeeld-QA-bot voor u gemaakt met de code voor de indexer job, query service en een chat-frontend via Streamlit in deze GitHub-repository:

‍

GitHub - truefoundry/docs-qa-playground

Draag bij aan de ontwikkeling van truefoundry/docs-qa-playground door een account aan te maken op GitHub.

GitHub Truefoundry

‍

U kunt dit binnen 15 minuten op TrueFoundry in uw eigen cloud implementeren. Dit maakt een opzet op productieniveau mogelijk en geeft u ook de volledige flexibiliteit om de code aan te passen aan uw eigen use-cases.

Hoe QA implementeren met TrueFoundry?

We gaan de gehele architectuur implementeren op een Kubernetes-cluster. U vindt de volledige code en de instructies voor de implementatie in deze GitHub-repository.

TrueFoundry biedt een eenvoudig te gebruiken abstractie over Kubernetes om verschillende typen toepassingen op Kubernetes te implementeren. We lopen door de verschillende stappen om RAG in uw cloud te implementeren.

Maak een ML-repo aan en upload de documenten als artefact

TrueFoundry wordt geleverd met een metadata store in de vorm van ML-repo's. U kunt artefacten en metadata opslaan, en de mlfoundry pip-bibliotheek biedt methoden om de artefacten te uploaden en te downloaden. Elke ML-repo wordt ondersteund door cloud blob storage (AWS S3, GCS of Azure Blob Storage). We beginnen eerst met het aanmaken van een ML-repo en uploaden vervolgens onze te indexeren documenten als artefact. Volg de gids hier om een ML-repo aan te maken: https://www.truefoundry.com/docs/creating-a-ml-repo

Zodra we een artefact hebben aangemaakt, maken we een nieuwe artefactversie aan. Op deze manier kunt u elke keer dat de documentenset verandert, de nieuwe set documenten als een nieuwe versie uploaden. U kunt uw documenten uploaden in het onderstaande scherm.

Zodra de documenten zijn geüpload, ontvangen we de fqn van de artefactversie, waarmee we overal in de code naar het artefact kunnen verwijzen of het kunnen downloaden.

Implementeer het embeddingmodel

We hebben het embeddingmodel nodig om de chunks om te zetten — u kunt deze stap overslaan als u OpenAI-embeddings gebruikt. U kunt elk van de embeddingmodellen uit de modelcatalogus implementeren — in het algemeen merken we dat e5-large-v2 erg goed presteert. 

Zodra het embeddingmodel is geïmplementeerd, kunt u de API's testen met de OpenAPI playground op het TrueFoundry-dashboard.

Implementeer VectorDB: Qdrant

We gaan de Qdrant VectorDB implementeren.

Implementeer de indexer job

We gaan nu de indexer job implementeren. Een Job in TrueFoundry stelt ons in staat om een script eenmalig of op basis van een planning uit te voeren, waarna de rekenkracht wordt uitgeschakeld zodra de taak is voltooid. De code voor de indexer job vindt u hier: https://github.com/truefoundry/docs-qa-playground/tree/main/backend/train. De indexer job ondersteunt het laden van data uit lokale bestanden of uit een mlfoundry-artefact. Het rendert ook automatisch een formulier waarin u argumenten kunt opgeven om de taak te starten. U kunt de artefact-fqn die we in stap 1 hebben gekopieerd invoeren en plakken in het veld voor de bron-URI als mlfoundry://<artifact_fqn>. De reponaam kan een willekeurige reeks zijn die u helpt deze indexeringstaak te identificeren. U moet ook de naam invoeren van de ML-repo die we in stap 1 hebben aangemaakt.

Zodra de taak wordt uitgevoerd, kunt u alle taakuitvoeringen en hun logs volgen:

Metadata Store

Elke keer dat de taak wordt uitgevoerd, maken we een 'run' aan in de ML-repo die alle embedding-instellingen en de parameters van de indexer job opslaat. Deze instellingen worden later gebruikt door de query service om te bepalen welke embedding-instellingen moeten worden gebruikt voor het omzetten van de query. U kunt de details van alle indexeringstaken volgen op het tabblad met runs.

Implementeer Query Service

De query service is een FastAPI-server met een API om de query te ontvangen en de respons van de LLM op te halen. Zodra u deze hebt geïmplementeerd, kunt u query's uitvoeren via de Swagger UI van FastAPI.

Implementeer LLM-model

Dit is nodig als u van plan bent een open-source LLM te gebruiken en niet OpenAI. U kunt de LLM implementeren vanuit de modelcatalogus.

Implementeer de frontend voor indexering en chatbot

We bieden ook een Streamlit-app die kan worden gekoppeld aan uw indexerings-backend, query service en metadata store om alle geïndexeerde repositories op te sommen en er vragen aan te stellen. Een voorbeeld-demo hiervan is te vinden op https://www.truefoundry.com/docs/create-and-setup-your-account. U vindt de code in de GitHub-repo hier. Om deze frontend te laten werken, moet u deze koppelen aan uw query service en job via omgevingsvariabelen:

Nu hebben we een end-to-end systeem met een frontend dat kan worden opgeschaald naar een willekeurig aantal use-cases en documentensets binnen de organisatie. Er zijn een paar zaken die we in de toekomst willen toevoegen:

1. Incrementele indexering van nieuwe documenten in de repository
2. Het kunnen aanpassen van de frontend aan verschillende indexeringstaken en backend-API's - deze werkt momenteel slechts voor één backend en taak.

Deze architectuur maakt het ook mogelijk om een centrale documentindexeringsservice in een organisatie te hebben die vertrouwt op een centrale bibliotheek van dataloaders en parsers.