Varför vi byggde vårt eget promptbibliotek istället för LangChain
Vi använde LangChain en period. Sen byggde vi vårt eget. Här är de pragmatiska skälen och vad vi tjänade på det.
Alexander Galldin
Kapaciti
LangChain har gjort mycket bra för AI-utveckling. Det har sänkt tröskeln för många och gjort det möjligt att komma igång snabbt. Men vi använder det inte längre. Det här är inte en kritik mot ramverket utan ett resonemang om varför vi landade på en egen lösning.
Abstraktioner som inte passade vår verklighet
LangChain bygger på begrepp som chains, agents och memory. De abstraktionerna är generella nog att täcka mycket men inte specifika nog att exakt passa hur vi tänker om systemen vi bygger. Vi spenderade ofta tid på att förstå hur LangChain ville att vi skulle göra något istället för att bygga det vi behövde.
När du börjar omfaktorera ramverket istället för att använda det är det ett tecken på att du växt ifrån det.
Versionsfrekvensen var krävande
I en period bröt LangChain bakåtkompatibilitet ofta. Vi spenderade utvecklartid på att uppdatera kunder som bara körde paket istället för att bygga nytt värde. För varje ny LangChain-version behövde vi testa om våra agenter, läsa migrationsguider och fixa edge cases.
Det är värt det om man får mycket tillbaka. Vi tyckte inte vi gjorde det.
Vårt eget bibliotek är litet och fokuserat
Det vi byggde är inte ambitiöst. Det är runt två tusen rader Python som hanterar prompt-rendering, modell-anrop med retries, structured output, verktygsanrop, kostnadsspårning och loggning. Det räcker för 90 procent av det vi gör.
När vi behöver något specialiserat skriver vi det specifikt. Ingen prematur generalisering, ingen abstraktion för abstraktionens skull.
Vad ni borde tänka om val av ramverk
Om ni är i tidig fas och behöver komma igång snabbt är det rationellt att börja med ett etablerat ramverk. Det sänker risken och ger er fungerande mönster att lära av.
När ni börjat förstå vad ni egentligen bygger och märker att ramverket sätter käppar i hjulet är det dags att överväga eget. Inte för att vara cool utan för att äga sin egen produktionsstabilitet.
Den övergripande lärdomen
Den största kostnaden för ett komplext beroende är inte själva integrationen. Det är att din mentala modell över systemet blir svårare att hålla. Eget kod ni förstår fullt ut är värt mer än elegantt ramverkskod ni delvis förstår. Det gäller särskilt i AI-byggande där felmeddelanden ofta är svaga och du behöver kunna gräva snabbt.