Lovable byter sökmodell för nya appfunktioner – gamla index uppgraderas inte

Det här ändrades – och det här lämnades kvar

Lovables changelog daterar ändringen till den 20 augusti 2026. När Lovable bygger semantisk sökning, rekommendationer eller retrieval-augmented generation – RAG – i en app är Gemini Embedding 2 nu standard. Modell-id:t som Lovable anger är google/gemini-embedding-2. Det gäller alltså modellen som gör innehållet sökbart efter innebörd, inte modellen som skriver kod i Lovables editor och inte nödvändigtvis språkmodellen som formulerar ett svar i en chatt.

Samma changelogpost avgränsar bytet: befintliga funktioner fortsätter att fungera, och Lovable använder fortfarande Gemini Embedding 001 för tabeller som redan lagrar vektorer från den modellen. ”Ny standard” betyder därför inte ”automatisk migrering”. Om du bara ändrar färgen på sökrutan eller lägger till ett filter framför samma tabell har du inte skapat ett nytt index.

En embedding är ett sökunderlag, inte ett svar

En embedding är en numerisk representation av innehåll. När en text läses in skapas en rad tal som beskriver dess innebörd; när någon söker skapas en ny rad tal för frågan. Appen jämför dem och hämtar det innehåll som ligger närmast. Det är därför en sökning efter ”kvittot från tågresan” kan hitta en fil där exakt de orden aldrig står.

Exempel: en returpolicy innehåller meningen ”Ångerrätten gäller i 30 dagar”, medan användaren frågar ”Hur länge kan jag lämna tillbaka köpet?”. En embedding kan placera frågan nära rätt stycke trots att orden skiljer sig. Fallgropen kommer i nästa led: om sökningen i stället hämtar ett äldre dokument med 14 dagar kan en RAG-chatt formulera ett övertygande men felaktigt svar. Prova därför frågan mot ett känt aktuellt dokument och kontrollera vilken källa som faktiskt hämtas.

Gemini Embedding 2 är enligt Google en multimodal modell: text, bilder, video, ljud och PDF kan placeras i ett gemensamt vektorrum. Google anger ett indatatak på 8 192 tokens och valbara utdatadimensioner mellan 128 och 3 072. Föregångaren Gemini Embedding 001 tar text som indata och har ett indatatak på 2 048 tokens. De siffrorna är tekniska gränser, inte ett löfte om att en hel godtyckligt stor PDF eller video kan skickas in utan uppdelning.

Det viktiga för dig är sammanhanget runt talen. Tabellen lagrar vektorerna, inläsningsflödet bestämmer vilken modell som skapade dem och sökfunktionen skapar en vektor av varje ny fråga. Lovables uttryckliga val att fortsätta använda 001 för tabeller som redan innehåller 001-vektorer betyder att du ska behandla modellen som en del av tabellens kontrakt, inte som en global projektinställning som alltid följer senaste standard.

Så identifierar du rätt tabell och modell utan att kunna koden

Börja i användarens väg genom appen, inte i databasen. Namnge funktionen konkret: ”sökrutan på kundsidan”, ”rekommendationerna under en produkt” eller ”chatten som svarar från uppladdade handböcker”. Be sedan Lovable spåra just den vägen bakåt och redovisa resultatet utan att ändra något.

Om Lovable inte kan ange tabellen är funktionen inte redo för en migration. Först när du vet var vektorerna ligger kan du skilja en ändring av gränssnittet från en ny inläsning. Den generella skillnaden mellan relationsdata, dokument och vektorer finns i guiden om vilken databas du ska välja; här är poängen snävare: samma app kan ha flera vektortabeller med olika modellhistorik.

Prova text, bild och PDF som tre separata fall

Ett enda lyckat sökord visar bara att gränssnittet svarar. Bygg i stället ett litet provpaket där facit är känt och där varje format bär en uppgift som inte finns i de andra. Då ser du om funktionen verkligen söker över flera medietyper eller om den råkar hitta en textetikett bredvid dem.

Kör proven en gång före och en gång efter ändringen och spara ordningen på resultaten. Provlistan för appar byggda utan kod förklarar varför samma prov behöver återanvändas som ett regressionstest. Här lägger du till två kolumner: tabellnamn och embeddingmodell.

Behåll det gamla eller bygg om med avsikt

Att det gamla indexet inte uppgraderas är inte i sig ett fel. En fungerande textsökning kan få fortsätta på Gemini Embedding 001, särskilt om du inte behöver fler format. Lovable säger uttryckligen att befintliga funktioner fortsätter att fungera. Att bygga om allt bara för att en ny standard finns skapar i stället en ny inläsning, nya testresultat och en möjlighet att resultatordningen förändras.

En migration är motiverad när du faktiskt behöver söka över bild, ljud, video eller PDF tillsammans med text, eller när du vill samla en ny funktion på ett gemensamt underlag. Gör den då som en egen förändring: skapa eller namnge mål-tabellen, läs in ett avgränsat provpaket, kör proven och bestäm först därefter vad som ska hända med den gamla tabellen. Changeloggen lovar att gamla funktioner fortsätter, men ger ingen automatisk migreringsväg och säger inte att gamla vektorer skrivs om i bakgrunden.

Lovable dokumenterar standardvalet och hur befintliga 001-tabeller behandlas, men inte en automatisk migreringsväg eller ett bestämt gränssnitt där alla projekts tabell- och modellkopplingar visas. Kontrollera därför de exakta namnen i ditt projekt igen när funktionen ändras.