Hoe u uw AI-app sneller en interactiever kunt maken met responsstreaming

In mijn laatste berichten heb ik veel gesproken over snelle caching en caching in het algemeen, en hoe dit uw AI-app kan verbeteren in termen van kosten en latentie. Maar zelfs voor een volledig geoptimaliseerde AI-app duurt het soms enige tijd voordat de reacties worden gegenereerd, en we kunnen er eenvoudigweg niets aan doen. Wanneer we grote output van het model vragen of redeneren of diep nadenken vereisen, zal het model uiteraard langer nodig hebben om te reageren. Hoe redelijk dit ook is, langer wachten op een antwoord kan frustrerend zijn voor de gebruiker en de algehele gebruikerservaring met een AI-app verslechteren. Gelukkig is er een eenvoudige en ongecompliceerde manier om dit probleem te verbeteren reactiestreaming.

Streaming betekent dat de respons van het model stapsgewijs, beetje bij beetje, wordt gegenereerd zoals gegenereerd, in plaats van te wachten tot de volledige respons is gegenereerd en deze vervolgens aan de gebruiker weer te geven. Normaal gesproken (zonder streaming) sturen we een verzoek naar de API van het model, wachten we tot het model het antwoord genereert, en zodra het antwoord is voltooid, krijgen we het in één stap terug van de API. Bij streaming stuurt de API echter gedeeltelijke uitvoer terug terwijl het antwoord wordt gegenereerd. Dit is een vrij bekend concept omdat de meeste gebruikersgerichte AI-apps zoals ChatGPT vanaf het moment dat ze voor het eerst verschenen streaming gebruikten om hun reacties aan hun gebruikers te tonen. Maar naast ChatGPT en LLM’s wordt streaming in wezen overal op internet en in moderne toepassingen gebruikt, zoals bijvoorbeeld in livemeldingen, multiplayer-games of live nieuwsfeeds. In dit bericht gaan we verder onderzoeken hoe we streaming kunnen integreren in onze eigen verzoeken om API’s te modelleren en een soortgelijk effect te bereiken op aangepaste AI-apps.

Er zijn verschillende mechanismen om het concept van streaming in een applicatie te implementeren. Niettemin zijn er voor AI-toepassingen twee veelgebruikte vormen van streaming. Meer specifiek zijn dat:

• HTTP-streaming via door de server verzonden gebeurtenissen (SSE): Dat is een relatief eenvoudige eenrichtingsstreaming, waarbij alleen livecommunicatie van server naar client mogelijk is.
• Streamen met WebSockets: Dat is een geavanceerder en complexer type streaming, waardoor live tweerichtingscommunicatie tussen server en client mogelijk is.

In de context van AI-toepassingen kan HTTP-streaming via SSE eenvoudige AI-toepassingen ondersteunen waarbij we alleen de reactie van het model hoeven te streamen vanwege latentie en UX-redenen. Niettemin worden WebSockets, nu we verder gaan dan eenvoudige verzoek-antwoordpatronen naar meer geavanceerde instellingen, bijzonder nuttig omdat ze live, bidirectionele communicatie tussen onze applicatie en de API van het model mogelijk maken. In code-assistenten, multi-agentsystemen of workflows voor het aanroepen van tools kan het bijvoorbeeld nodig zijn dat de client tussentijdse updates, gebruikersinteracties of feedback terugstuurt naar de server terwijl het model nog steeds een antwoord genereert. Voor de meeste eenvoudige AI-apps waarbij we alleen het model nodig hebben om een ​​antwoord te bieden, zijn WebSockets echter meestal overdreven en is SSE voldoende.

In de rest van dit bericht gaan we dieper in op streaming voor eenvoudige AI-apps met behulp van HTTP-streaming via SSE.

. . .

Hoe zit het met HTTP-streaming via SSE?

HTTP-streaming via door de server verzonden gebeurtenissen (SSE) is gebaseerd op HTTP-streaming.

. . .

HTTP-streaming betekent dat de server alles wat hij moet verzenden in delen kan verzenden, in plaats van alles in één keer. Dit wordt bereikt doordat de server de verbinding met de client niet beëindigt na het verzenden van een antwoord, maar deze open laat en de client welke aanvullende gebeurtenis dan ook onmiddellijk verzendt.

In plaats van het antwoord bijvoorbeeld in één stuk te krijgen:

Hello world!

we zouden het in delen kunnen krijgen met behulp van onbewerkte HTTP-streaming:

Hello

World

!

Als we HTTP-streaming helemaal opnieuw zouden implementeren, zouden we alles zelf moeten afhandelen, inclusief het parseren van de gestreamde tekst, het beheren van eventuele fouten en het opnieuw verbinden met de server. In ons voorbeeld, met behulp van onbewerkte HTTP-streaming, zouden we op de een of andere manier aan de klant moeten uitleggen dat ‘Hallo wereld!’ is conceptueel gezien één gebeurtenis, en alles daarna zou een afzonderlijke gebeurtenis zijn. Gelukkig zijn er verschillende frameworks en wrappers die HTTP-streaming vereenvoudigen, waarvan er één dat is HTTP-streaming via door de server verzonden gebeurtenissen (SSE).

. . .

Server-Sent Events (SSE) bieden dus een gestandaardiseerde manier om HTTP-streaming te implementeren door serveruitvoer te structureren in duidelijk gedefinieerde gebeurtenissen. Deze structuur maakt het veel eenvoudiger om gestreamde reacties aan de clientzijde te parseren en verwerken.

Elk evenement omvat doorgaans:

• een id
• een event type
• A data lading

of beter gezegd..

id: 
event: 
data: 

Ons voorbeeld met behulp van SSE zou er ongeveer zo uit kunnen zien:

id: 1
event: message
data: Hello world!

Maar wat is een evenement? Alles kan in aanmerking komen als een gebeurtenis: een enkel woord, een zin of duizenden woorden. Wat in onze specifieke implementatie feitelijk als een gebeurtenis kwalificeert, wordt gedefinieerd door de configuratie van de API of de server waarmee we verbonden zijn.

Bovendien biedt SSE nog diverse andere gemakken, zoals het automatisch opnieuw verbinden met de server als de verbinding wordt verbroken. Een ander ding is dat inkomende stroomberichten duidelijk worden getagd als text/event-streamwaardoor de klant deze op de juiste manier kan afhandelen en fouten kan voorkomen.

. . .

Rol je mouwen op

Frontier LLM API’s zoals OpenAI’s API of Claude API ondersteunen native HTTP-streaming via SSE. Op deze manier wordt het integreren van streaming in uw verzoeken relatief eenvoudig, omdat dit kan worden bereikt door een parameter in het verzoek te wijzigen (bijvoorbeeld door een stream=true parameter).

Zodra streaming is ingeschakeld, wacht de API niet langer op het volledige antwoord voordat hij antwoordt. In plaats daarvan stuurt het kleine delen van de uitvoer van het model terug zodra deze worden gegenereerd. Aan de clientzijde kunnen we deze stukjes herhalen en ze geleidelijk aan de gebruiker weergeven, waardoor het bekende ChatGPT-type-effect ontstaat.

Maar laten we hier een minimaal voorbeeld van maken met behulp van, zoals gewoonlijk, de API van OpenAI:

import time
from openai import OpenAI

client = OpenAI(api_key="your_api_key")

stream = client.responses.create(
    model="gpt-4.1-mini",
    input="Explain response streaming in 3 short paragraphs.",
    stream=True,
)

full_text = ""

for event in stream:
    # only print text delta as text parts arrive
    if event.type == "response.output_text.delta":
        print(event.delta, end="", flush=True)
        full_text += event.delta

print("nnFinal collected response:")
print(full_text)

In dit voorbeeld herhalen we, in plaats van één voltooid antwoord, een reeks gebeurtenissen en drukken we elk tekstfragment af zodra het binnenkomt. Tegelijkertijd slaan we de brokken ook op in een volledig antwoord full_text om later te gebruiken als we dat willen.

. . .

Moet ik dus gewoon streaming = True op elk verzoek plaatsen?

Het korte antwoord is nee. Hoe nuttig het ook is, met een groot potentieel om de gebruikerservaring aanzienlijk te verbeteren, streaming is geen one-size-fits-all oplossing voor AI-apps, en we moeten onze discretie gebruiken om te evalueren waar het moet worden geïmplementeerd en waar niet.

Meer specifiek is het toevoegen van streaming in een AI-app zeer effectief in configuraties waarin we lange reacties verwachten, en we vooral de gebruikerservaring en het reactievermogen van de app waarderen. In een dergelijk geval zouden consumentengerichte chatbots het geval zijn.

Aan de andere kant, voor eenvoudige apps waarvan we verwachten dat de aangeboden reacties kort zullen zijn, zal het toevoegen van streaming waarschijnlijk geen significante winst opleveren voor de gebruikerservaring en heeft het niet veel zin. Bovendien heeft streaming alleen zin in gevallen waarin de uitvoer van het model vrije tekst is en geen gestructureerde uitvoer (bijvoorbeeld json-bestanden).

Het belangrijkste nadeel van streaming is dat we niet het volledige antwoord kunnen beoordelen voordat we het aan de gebruiker tonen. Houd er rekening mee dat LLM’s de tokens één voor één genereren, en dat de betekenis van het antwoord wordt gevormd naarmate het antwoord wordt gegenereerd, en niet vooraf. Als we 100 verzoeken indienen bij een LLM met exact dezelfde invoer, krijgen we 100 verschillende antwoorden. Dat wil zeggen: voordat de antwoorden zijn voltooid, weet niemand wat er gaat worden gezegd. Als gevolg hiervan is het veel moeilijker om, als streaming is geactiveerd, de uitvoer van het model te bekijken voordat deze aan de gebruiker wordt weergegeven, en om eventuele garanties op de geproduceerde inhoud toe te passen. We kunnen altijd proberen gedeeltelijke voltooiingen te evalueren, maar nogmaals, gedeeltelijke voltooiingen zijn moeilijker te evalueren, omdat we moeten raden waar het model hiermee naartoe gaat. Door toe te voegen dat deze evaluatie in realtime moet worden uitgevoerd en niet slechts één keer, maar recursief op verschillende deelreacties van het model, wordt dit proces nog uitdagender. In de praktijk wordt in dergelijke gevallen de validatie uitgevoerd op de gehele uitvoer nadat het antwoord is voltooid. Het probleem hiermee is echter dat het op dit moment misschien al te laat is, omdat we de gebruiker mogelijk al ongepaste inhoud hebben getoond die niet aan onze validaties voldoet.

. . .

In mijn gedachten

Streaming is een functie die geen daadwerkelijke impact heeft op de mogelijkheden van de AI-app, of de bijbehorende kosten en latentie. Niettemin kan het een grote impact hebben op de manier waarop de gebruiker een AI-app waarneemt en ervaart. Door streaming voelen AI-systemen sneller, responsiever en interactiever aan, zelfs als de tijd voor het genereren van de volledige respons precies hetzelfde blijft. Dat gezegd hebbende, streaming is geen wondermiddel. Verschillende toepassingen en contexten kunnen min of meer profiteren van de introductie van streaming. Zoals bij veel beslissingen in AI-engineering gaat het minder om wat mogelijk is, maar meer om wat zinvol is voor uw specifieke gebruikscasus.

. . .

Als je zo ver bent gekomen, Misschien vindt u pialgoritmen nuttig – een platform dat we hebben gebouwd waarmee teams de kennis van de organisatie veilig op één plek kunnen beheren.

. . .

Vond je dit bericht leuk? Ga met mij mee 💌Substapel en 💼LinkedIn

. . .

Alle afbeeldingen zijn van de auteur, tenzij anders vermeld.