Den naiva drömmen om realtids-AI
På papperet låter det enkelt: Skicka ljudet från mötet till en tal-till-text-motor, skicka texten till en LLM (Large Language Model) och be den ge smarta råd.
Verkligheten? Det är ett tekniskt minfält. Att bygga en AI-coach som fungerar i realtid - utan att störa, utan att hallucinera och utan att vara för långsam - kräver att man löser några av de svåraste problemen inom modern mjukvaruarkitektur.
Här är en djupdykning i varför realtids-AI är så mycket svårare än det ser ut.
Problemet djupt förklarat
För att en AI-coach ska kännas magisk måste fyra kritiska komponenter fungera felfritt på under en sekund.
1. Den skoningslösa latensen
I en konversation är fönstret för en relevant insikt minimalt. Om din kollega nämner en konkurrent, och AI:n tar fyra sekunder på sig att hämta konkurrentanalysen, har konversationen redan gått vidare. Din coach gick från "briljant" till "distraherande" på ett par sekunder. Att orkestrera ljudupptagning, transkribering, semantisk sökning (RAG) och LLM-generering inom 500-800 millisekunder kräver en extremt optimerad pipeline.
2. Att analysera ofullständiga meningar (Partial Transcripts)
Människor pratar inte i snyggt formaterade meningar. Vi pausar, vi ångrar oss, vi byter riktning mitt i en mening. En transkriberingsmotor spottar ut ofullständiga meningar ("partial transcripts") medan du pratar. Att låta en AI bedöma avsikten i en halv mening är extremt svårt. Väntar man på att meningen är klar förlorar man värdefull tid. Agerar man för tidigt riskerar man att missförstå kontexten totalt.
3. Dilemmat med kontextfönstret (Context Window)
En bra coach behöver hela kontexten. Den måste veta vad som sagts tidigare i mötet, vad ni pratade om förra veckan, och vem som är vem. Att skicka in 45 minuters transkribering och historisk data i ett stort kontextfönster varje gång en ny mening sägs är inte bara orimligt dyrt - det är framförallt för långsamt.
4. Avbrottshantering (Interruption Handling)
Vad händer om AI:n är mitt i att generera ett strategiskt råd, men kunden plötsligt byter ämne? Systemet måste ha förmågan att i realtid avbryta sin egen process, kasta bort det den höll på att tänka, och omedelbart anpassa sig till det nya ämnet.
Varför naiva lösningar misslyckas
När vi började bygga ReVoice testade vi (och förkastade) alla de klassiska metoderna. Det är tydligt varför många produkter aldrig tar sig förbi prototypstadiet:
Det misslyckade försöket 1: Polling (Skicka allt var femte sekund)
Tanken: Skicka hela transkriptet till en LLM var femte sekund och fråga "Finns det något viktigt att säga?". Verkligheten: Det blir exponentiellt långsammare, kostar en förmögenhet i API-anrop, och resulterar i att AI:n upprepar samma råd om och om igen. Dessutom tappar LLM:en fokus när den ständigt måste läsa om samma irrelevanta kallprat.
Det misslyckade försöket 2: Nyckelordsmatchning
Tanken: Lyssna efter specifika ord (t.ex. "pris" eller en konkurrents namn) och trigga förskrivna svar eller en specifik prompt. Verkligheten: Mänskligt språk är kontextuellt. Att kunden säger "Vi har fått ett bra pris från [Konkurrent]" kräver ett helt annat råd än när kunden säger "Vi valde bort [Konkurrent] på grund av deras pris". Nyckelord är blinda för kontext och leder snabbt till att användaren stänger av systemet på grund av irrelevanta "smarta tips".
Det misslyckade försöket 3: Tystnadsdetektering (Silence Detection)
Tanken: Vänta tills någon slutar prata i två sekunder, analysera sedan det senaste blocket. Verkligheten: Människor pausar för att andas eller tänka. Om systemet triggas varje gång någon tar ett djupt andetag blir det fragmenterat. Om tidsgränsen sätts för högt missar man fönstret för coachning helt och hållet, eftersom motparten redan har börjat svara.
Ett nytt paradigm
Att lösa detta krävde att vi övergav de traditionella chatbot-arkitekturerna. Vi var tvungna att bygga en asynkron, händelsestyrd pipeline där state management, blixtsnabb RAG och deterministiska tillståndsmaskiner (state machines) samverkar. Det handlar om att behandla AI som en reaktiv ström snarare än en fråga-svar-loop.
Vi löste det - boka en demo.