Hur du bygger en AI-chatbot för din app utan kod

Arkitekturen

En produktions-AI-chatbot har fyra komponenter:

1. Chatt-UI: Inmatningsfält, meddelandehistorik, laddningstillstånd, felhantering 2. Konversationstillstånd: En array av meddelanden (roll + innehåll) lagrad i frontend-tillståndet 3. Backend-proxy: En Supabase Edge Function eller Xano-endpoint som anropar OpenAI 4. Systemprompt: Instruktionsuppsättningen som definierar din chatbots persona, kunskap och begränsningar

Konversationstillståndet är det viktigaste konceptet. OpenAIs API är tillståndslöst, varje förfrågan måste inkludera hela konversationshistoriken. Din frontend underhåller denna historik och skickar den med varje meddelande. För svenska B2B-appar: lagra konversationer i Supabase EU-region för GDPR-efterlevnad.

Chatbot-arkitekturval: retrieval vs generation

Innan du börjar bygga behöver du bestämma om din chatbot i första hand ska vara retrieval-baserad eller generationsbaserad. Detta val avgör arkitekturen, kostnaden och kvalitetsegenskaperna hos den färdiga produkten.

En retrieval-baserad chatbot hittar det bäst matchande svaret i en fördefinierad kunskapsbas. Användaren ställer en fråga, ditt system hittar den mest liknande frågan och svaret i databasen och presenterar det, eventuellt omformulerat av språkmodellen. Detta är snabbt, billigt (få tokens förbrukas) och mycket träffsäkert inom kunskapsdomänen. Det brister när användare ställer frågor som inte täcks av kunskapsbasen, vilket ger ohjälpsamma svar i stil med "Jag har ingen information om det".

En generationsbaserad chatbot skickar användarens fråga till en språkmodell tillsammans med kontext och låter modellen formulera ett nytt svar. Detta hanterar frågor som aldrig uttryckligen skrevs ner, kan sammanställa information från flera källor och ger naturliga, samtalsmässiga svar. Kostnaden är högre (fler tokens per meddelande), och modellen kan ibland generera information som låter trovärdig men som är felaktig. För de flesta kundvända supportchattbottar är rätt arkitektur hybrid: börja med retrieval (hämta de tre mest relevanta artiklarna från kunskapsbasen) och använd generation för att sammanställa ett sammanhängande svar utifrån dessa källor, med en hård regel om att modellen inte ska svara utanför dessa källor. Detta är RAG, Retrieval Augmented Generation, och det ger dig träffsäkerhet i kombination med flexibilitet.

Bygga chatt-UI i WeWeb

I WeWeb, skapa en sidnivåvariabel messages (array, standard tom). Lägg till två komponenter:

Meddelandelista: En Repeating Group bunden till messages. Varje element har ett villkorligt utseende, användarmeddelanden högerjusterade med primärfärg bakgrund, assistentmeddelanden vänjusterade med neutral bakgrund. Bind texten till item.content.

Inmatningsarea: En textinmatning bunden till en userInput-variabel, plus en "Skicka"-knapp. Vid knapptryck: (1) lägg till {roll: "user", content: userInput} i messages, (2) rensa userInput, (3) anropa API-åtgärden, (4) lägg till svaret som {roll: "assistant", content: response}.

Lägg till en laddningsspinner som visas medan API-anropet pågår.

Träna chatboten på din dokumentation

En chatbot som bara känner till det GPT-4o tränades på kommer inte att känna till din produkts specifika funktioner, priser, policyer eller rutiner. För att göra chatboten verkligt användbar för dina användare behöver du injicera din kunskapsbas i konversationen. Det finns två tillvägagångssätt: statisk injektion (klistra in dokumentation direkt i systemprompten) och dynamisk injektion via RAG.

Statisk injektion fungerar för små kunskapsbaser under 5 000 ord. Skriv din dokumentation som strukturerad text, lägg till den i systemprompten, och modellen använder den som sin primära referens. Nackdel: det statiska tillvägagångssättet blir kostsamt i stor skala (hela kunskapsbasen skickas med varje meddelande), och att hålla systemprompten uppdaterad när dokumentationen ändras är manuellt arbete.

För större kunskapsbaser är RAG rätt tillvägagångssätt. Bearbeta din dokumentation till segment om 200-500 ord, bädda in varje segment med OpenAIs text-embedding-3-small-modell och lagra inbäddningarna i Supabase med pgvector-tillägget. Vid frågetillfället bäddas användarens meddelande in, du hittar de tre till fem mest liknande segmenten via en cosine similarity-sökning, och injicerar bara dessa segment i systemprompten. Detta kostar dramatiskt mindre per meddelande och skalar till tusentals dokumentationssidor. När du uppdaterar dokumentationen, bädda om de ändrade segmenten och uppdatera databasen, chatboten plockar upp ändringarna automatiskt vid nästa fråga.

Supabase Edge Function

Din Edge Function tar emot meddelandearrayen och systemprompten, anropar OpenAI och returnerar svaret:

```typescript
serve(async (req) => {
  const { messages, systemPrompt } = await req.json()

  const completion = await openai.chat.completions.create({
    model: "gpt-4o",
    messages: [
      { role: "system", content: systemPrompt },
      ...messages
    ],
    max_tokens: 500,
    temperature: 0.7
  })

  return new Response(
    JSON.stringify({ content: completion.choices[0].message.content }),
    { headers: { "Content-Type": "application/json" } }
  )
})
```

systemPrompt kan skickas från frontend (användbart för appar med flera personas) eller hårdkodas i funktionen (säkrare).

Skriva en effektiv systemprompt

Systemprompten bestämmer allt om din chatbots beteende. En bra produktionssystemprompt inkluderar:

- Roll: "Du är en kundsupportagent för Acme SaaS, ett projekthanteringsverktyg." - Kunskap: "Du hjälper användare med: skapa projekt, bjuda in teammedlemmar, konfigurera integrationer och faktureringsfrågor." - Begränsningar: "Svara bara på frågor om Acme SaaS. Vid orelaterade frågor, omdirigera artigt. Nämn aldrig konkurrentprodukter. Hitta aldrig på funktioner som inte finns." - Format: "Håll svaren under 100 ord. Använd punktlistor för steg. Avsluta alltid supportsvar med: 'Säg till om detta hjälpte!' Svara på svenska som standard, om inte användaren skriver på ett annat språk." - Eskalering: "Om användaren uttrycker frustration eller nämner ett faktureringsfel, säg: 'Jag kopplar dig till vårt team' och utlös eskaleringsflödet."

För svenska appar: inkludera instruktionen att svara på svenska som standard, med möjlighet att byta språk.

Hantera eskalering till mänsklig support

Varje produktionschatbot behöver en tydlig eskaleringsväg för frågor som AI:n inte kan hantera med säkerhet, känslomässigt laddade konversationer och situationer som kräver kontonivåhandlingar som en bot inte bör utföra (utfärda återbetalningar, radera konton, göra faktureringsundantag). Bygg in detta i systemprompten och användargränssnittet från början, inte som en eftertanke.

I systemprompten, definiera eskaleringstriggrar explicit: "Om användaren nämner en faktureringstvist, ett betalningsfel eller en kontoavstängning, försök inte lösa det. Svara istället exakt med: ESCALATE: [kort anledning], och inget annat." Din Edge Function upptäcker ESCALATE-prefixet och skapar ett supportärende i din helpdesk (Intercom, Zendesk eller till och med en Supabase-tabell) istället för att visa meddelandet för användaren.

I användargränssnittet, när en eskalering upptäcks, ersätt chatbotgränssnittet med ett meddelande: "Jag kopplar dig till vårt supportteam. De återkommer inom [SLA]. Du kan också mejla support@yourcompany.com." Mejla supportteamet med hela konversationsutskriften. Detta tillvägagångssätt håller överlämningen smidig för användaren samtidigt som supportagenten får full kontext. Mät eskaleringsgraden som ett centralt chatbotmått, en andel över 20 procent tyder på att kunskapsbasen behöver utökas.

Lägga till persistent kontext

Den grundläggande chatboten glömmer allt när sidan uppdateras. För att göra den smartare:

Användarkontext-injektion: När chatbottssessionen startar, hämta användarens kontodata (plan, användning, senaste aktivitet) och lägg till den i systemprompten: "Användarens nuvarande plan är Pro. Deras senaste aktivitet var för 3 dagar sedan. De har 2 aktiva projekt."

Konversationspersistens: Spara meddelanden till en Supabase-tabell (chatbot_sessions) med user_id och session_id. Vid sidladdning, hämta de senaste N meddelandena och fyll i förväg messages-arrayen.

Kunskapsbas: För produktdokumentation, lagra artiklar i Supabase med inbäddningar (med pgvector). Innan du anropar GPT-4o, kör en likhetsökning och injicera de mest relevanta artiklarna i systemprompten. Detta kallas RAG (Retrieval Augmented Generation) och förbättrar dramatiskt svarsnoggrannheten.

Mäta chatbotens framgång

En chatbot utan mätning är en funktion utan återkopplingsloop. De mått som betyder mest för en support- eller produktchatbot: lösningsgrad (andelen konversationer där användaren inte eskalerade eller skickade in ett separat supportärende), sessionslängd (genomsnittligt antal meddelanden per konversation, för kort tyder på att boten misslyckas tidigt, för lång tyder på att den inte löser ärenden effektivt), och betyg efter chatt (en enkel tumme upp/ner efter varje konversation, lagrad i Supabase och granskningsbar i en dashboard).

Utöver dessa användarvända mått bör du instrumentera din Edge Function för att logga: vilka kunskapsbasartiklar som hämtades oftast (visar vad användarna oftast frågar om), vilka frågor som inte hade någon stark matchning i vektordatabasen (visar luckor i kunskapsbasen), samt modellens svarstid och antal tokens per session (visar din kostnad per konversation). Granska dessa mått varje vecka under den första månaden efter lansering.

Det mest handlingsbara måttet är listan över frågor utan matchning i kunskapsbasen. Exportera den varje vecka, skriv svar på de 20 mest obesvarade frågorna, lägg till dem i kunskapsbasen och bädda om. En chatbot som förbättrar sin lösningsgrad med 5 procent per vecka under den första månaden når ofta en lösningsgrad över 80 procent inom 6 veckor efter lansering, betydligt bättre än de flesta människostyrda supportarbetsflöden hos SaaS-bolag i tidig fas.

Kostnader och prestanda i produktion

För ett SaaS med 500 aktiva användare som var och en skickar 10 meddelanden per dag:

- Genomsnittligt meddelande: 50 tokens input + 100 tokens output - GPT-4o-prissättning: 2,50 USD/M input + 10 USD/M output - Daglig kostnad: 500 × 10 × 150 tokens = 750 000 tokens = ~2,50 USD/dag = ~750 SEK/månad

För att hantera kostnader: implementera ett sessions-tokenbudget (sluta lägga till historikmeddelanden när konversationen överskrider 2 000 tokens, börja sammanfatta gamla meddelanden). Använd GPT-4o mini för enkla förfrågningar (0,15 USD/M input) och reservera GPT-4o för komplexa.

Svarstid: GPT-4o svarar på 1-3 sekunder. Lägg till en skrivindikator för att sätta förväntningar. För under-sekundsupplevelse, implementera strömning.

Reglering och GDPR för AI-chatbottar

För svenska appar finns det extra hänsyn för AI-chatbottar:

Dataminimering: Lagra inte mer konversationshistorik än nödvändigt. Implementera automatisk radering av konversationer äldre än ditt behov (t.ex. 90 dagar).

Transparens: Informera användare om att de pratar med en AI. EU:s AI-förordning kräver tydlig märkning av AI-interaktioner från och med 2026.

Ingen känslig data: Konfigurera systemprompten att aktivt avvisa om användare delar känsliga personuppgifter, personnummer (personnummer), bankuppgifter eller hälsodata i chattten.

Datacentralisering i EU: Alla konversationsloggar i Supabase EU-region. Din Edge Function i EU-region. OpenAI behandlar data utanför EU, dokumentera detta i din integritetspolicy och Data Processing Agreement med OpenAI.