Sådan skaleres LLM-apps uden at eksplodere din cloud-regning

"Hjælp! vores AI model omkostninger er gennem taget!" Mens ChatGPT og dets kusiner har udløst en guldrush af AI-drevne applikationer, er virkeligheden af at opbygge applikationer baseret på LLM'er mere kompleks end at slå et API-opkald på en webgrænseflade. Every day, my LinkedIn feed overflows with new "AI-powered" products. Some analyze legal documents, others write marketing copy, and a brave few even attempt to automate software development. These "wrapper companies" (as they're sometimes dismissively called) may not be training their own models, but many are solving real problems for customers and finding genuine product-market fit based on the current demands from the enterprises. The secret? They're laser-focused on making AI technology actually useful for specific groups of users. Men her er sagen: Selv når du ikke træner modeller fra bunden, skalerer en AI-applikation fra bevis på koncept til produktion, er det som at navigere i en labyrint blindfoldet. For at forstå det bedre, lad os bryde det ned med et eksempel i den virkelige verden. Forestil dig, at vi bygger "ResearchIt" (ikke et rigtigt produkt, men bære med mig), en applikation, der hjælper forskere med at fordøje akademiske papirer. Vil du have en hurtig sammenfatning af den tætte metodologi sektion? Har du brug for at udtrække nøgleresultater fra et 50-siders papir? Version 1.0: The Naive Approach Version 1.0: Den naive tilgang Vi kører højt på OpenAI hype toget - Vores første version er smukt enkel: Researcher uploads chunks of a paper (specific, relevant sections) Vores backend videresender teksten til GPT-5 med en prompt som "Du er en hjælpsom forskningsassistent. Analyse følgende tekst og levere indsigter strengt fra afsnittet leveret af brugeren......" Magien sker, og vores brugere får deres indsigt Det er en smuk løsning. – Det koster ikke så meget. Problemet er, at vi sender hver forespørgsel til GPT-5, Rolls-Royce af sprogmodeller, hvor en Toyota Corolla ofte ville gøre det bare fint. Ja, GPT-5 er kraftfuld, med sin 128k kontekstvindue og stærke begrundelsesevner, men ved $ 1,25 pr. 1M input tokens og $ 10 pr. 1M output tokens, koster omkostningerne hurtigt op. For enklere opgaver som opsummering eller klassificering leverer mindre modeller som GPT-5 mini (omkring 20% af omkostningerne), GPT-5 nano (omkring 4%), eller Gemini 2.5 Flash-Lite (omkring 5%) store resultater til en brøkdel af prisen. Open-source-modeller som Meta's LLaMA (3 eller 4 serie) eller forskellige modeller fra Mistral eller også tilbyde fleksible og omkostningseffektive muligheder for generelle eller domænespecifikke opgaver, selv om finjustering af dem ofte er unødvendigt for lettere arbejdsbyrder. Valget afhænger virkelig af følgende: Udgangskvalitet: Kan modellen konsekvent levere den nøjagtighed, som din applikation har brug for? understøtter modellen det sprog, du vil arbejde med? Reaktionshastighed: Vil dine brugere vente på de ekstra millisekunder for bedre resultater? Den typiske responstid for enhver app skal være inden for 10-sekundersmærket for brugerne ikke at miste interesse, så hastighed absolut betyder noget. Dataintegritet: Hvor følsomme er dine data, og hvad er dine krav til privatlivets fred? Ressource begrænsninger: Hvad er dit budget, både for omkostninger og engineering tid? For vores forskningspapiranalysator har vi ikke brug for poesi om kvantefysik; vi har brug for pålidelig, omkostningseffektiv opsummering. Bottom Line: Kend dine ansøgningsbehov Bottom Line: Kend dine ansøgningsbehov Vælg din LLM baseret på dine faktiske krav, ikke ren kraft.Hvis du har brug for en hurtig opsætning, kan proprietære modeller retfærdiggøre omkostningerne.Hvis overkommelighed og fleksibilitet betyder mere, er open-source-modeller et stærkt valg, især når små kvalitetskompromiser er acceptable (selvom der kan være nogle infrastruktur overhead). Forskere elsker, hvordan det opsummerer tætte akademiske papirer, og vores brugerbase vokser hurtigt. Men nu vil de mere; i stedet for bare at opsummere de sektioner, de uploader, vil de have fleksibiliteten til at stille målrettede spørgsmål over hele papiret på en effektiv måde. Lyder simpelt, ikke? Ikke så hurtigt. Akademiske papirer er lange. Selv med GPT-5's generøse 128K tokengrænse er det dyrt at sende fuldstændige dokumenter pr. forespørgsel. Det er vigtigt, når man udfører banebrydende forskning. Degradering Degradering Så hvad er løsningen? Version 2.0: Smarter chunking and retrieval Version 2.0: Smartere chunking og retrieval Det centrale spørgsmål her er, hvordan skalerer vi for at opfylde dette krav uden at sætte vores API-regning på ild og også opretholde nøjagtighed i systemet? **Answer is: \ (RAG). Instead of dumping the entire document into the LLM, we intelligently retrieve the most relevant sections before querying. This way we don’t need to send the whole document each time to the LLM to conserve the tokens but also make sure that relevant chunks are retrieved as context for the LLM to answer using it. This is where Retrieval-Augmented Generation (RAG) comes in. Retrieval-forstørret generation Retrieval-forstørret generation There are 3 important aspects to consider here: Chunking Opbevaring og chunk retrieval Rensning ved hjælp af avancerede retrieval teknikker. Trin 1: Chunking – Opdeling af dokumentet intelligent Før vi kan hente relevante sektioner, er vi nødt til at bryde papiret i håndterbare stykker. En naiv tilgang kan opdele tekst i faste segmenter (sige, hver 500 ord), men dette risikerer at miste kontekst midt i tanken. Forestil dig, hvis en stykke ender med: "Eksperimentet viste en 98% succesrate i..." ...og den næste stykke begynder med: "...reduktion af falske positive i tidlig stadium lungekræft detektion." Sektionsbaseret chunking: Brug dokumentstrukturen (titler, abstrakter, metodologi osv.) til at oprette logiske splitter. Sliding window chunking: Overlap stykker lidt (f.eks. 200-token overlap) for at bevare kontekst på tværs af grænser. Adaptiv chunking: Dynamisk justering af stykstørrelser baseret på sætningsgrænser og centrale emner. Sektionsbaseret chunking Sliding vindue chunking Adaptiv chunking Step 2: Intelligent storage and retrieval Når dine dokumentstykker er klar, er den næste udfordring at gemme og hente dem effektivt. Med moderne LLM-applikationer, der håndterer millioner af stykker, påvirker dit opbevaringsvalg direkte ydeevnen. Traditionelle tilgange, der adskiller opbevaring og hentning, falder ofte for kort. I stedet skal lagringsarkitekturen designes med hentning i tankerne, da forskellige mønstre tilbyder forskellige kompromisser for hastighed, skalerbarhed og fleksibilitet. The conventional distinction of using relational databases for structured data and NoSQL for unstructured data still applies, but with a twist: LLM applications store not just text but semantic representations (embeddings). I en traditionel opsætning kan dokumentstykker og deres indlejringer gemmes i PostgreSQL eller MongoDB. Dette fungerer for små til mellemstore applikationer, men har klare begrænsninger, da data og forespørgselsvolumen vokser. De traditionelle databaser udmærker sig ved præcise matches og rækkeforespørgsler, men de blev ikke bygget til semantiske lighedssøgninger. for at muliggøre vektorlignende søgninger. Dette er, hvor vektordatabaser virkelig skinner - de er målrettet bygget til det lager-og-retrieve mønster, som LLM-applikationer kræver - behandler indlejringer som det primære attribut til forespørgsel, optimering specifikt til nærmeste nabo søgninger. Den virkelige magi ligger i, hvordan de håndterer lighed beregninger. Mens traditionelle databaser ofte kræver komplekse matematiske operationer på forespørgselstidspunktet, bruger vektordatabaser specialiserede indekseringsstrukturer såsom (Hierarkisk navigabel lille verden) eller Inverted File Index) to make similarity searches blazingly fast. PgVektor HNSV af IVF PgVektor HNSV af IVF De understøtter typisk to primære lighedsmålinger: Euclidean Distance: Bedre egnet, når de absolutte forskelle mellem vektorer betyder noget, især nyttigt, når indlejringer koder hierarkiske relationer. Cosine Similarity: Standardvalg for semantisk søgning - det fokuserer på vektorens retning snarere end størrelsen. Dette betyder, at to dokumenter med lignende betydninger, men forskellige længder stadig kan matches effektivt. Valg af den rigtige vektordatabase er afgørende for optimering af hentning i LLM-applikationer, da det påvirker skalerbarhed, forespørgselseffektivitet og operationel kompleksitet. og offer fast ANN search with efficient recall - they handle scaling automatically making them ideal for dynamic workloads with minimal operational overhead. Self-hosted options like (IVF-baseret) tilbyder mere kontrol og omkostningseffektivitet på skalaen, men kræver omhyggelig tuning. pgvector integreret med Postgres muliggør hybrid søgning, selv om det kan ramme grænser under højt gennemstrømningsarbejdsbelastninger. Pinecone Weaviate af Milvus Pinecone Tørklæde af Milvus Step 3: Advanced Retrieval Strategies Mens tætte indlejringer giver mulighed for stærk semantisk matchning, kræver real-world-applikationer ofte yderligere lag af raffinering for at forbedre nøjagtighed, relevans og effektivitet.Ved at kombinere flere hentningsmetoder og udnytte Large Language Models (LLM'er) til intelligent efterbehandling, kan vi markant forbedre hentningskvaliteten. Nøgleordbaseret søgning (f.eks. BM25, TF-IDF) er fremragende til at finde nøjagtige termmatch, men kæmper med semantisk forståelse. På den anden side udmærker vektor søgning (f.eks. FAISS, HNSW eller IVFFlat) sig ved at indfange semantiske relationer, men kan undertiden returnere løst relaterede resultater, der savner afgørende søgeord. For at overvinde dette kombinerer en hybrid retrieval-strategi styrken af begge metoder. Dette involverer: Retrieving kandidater – kører både et søgeord og en vektorlignende søgning parallelt. Sammenlægningsresultater – styring af indflydelsen af hver indhentningsmetode baseret på forespørgselstypen og applikationsbehovet. Reranking for optimal ordering – ensuring the most relevant information appears at the top based on semantic requirements. En anden udfordring er, at traditionel vektorsøgning henter top-K-nærmeste indlejringer. LLM'er er afhængige af kontekstvinduer, hvilket betyder, at blindt valg af top-K-resultater kan indføre irrelevante oplysninger eller gå glip af afgørende detaljer. En løsning på dette problem er at bruge LLM selv til raffinering. Mere specifikt sender vi de hentede kandidater til en LLM for at verificere sammenhæng og relevans baseret på brugerens spørgsmål. Nogle teknikker, der anvendes til LLM raffinement er som følger: : Instead of feeding raw top-K results, the LLM evaluates whether the retrieved documents follow a logical progression related to the query. By ranking passages for semantic cohesion, only the most contextually relevant information is used. Semantisk sammenhæng Filtrering Relevance-Based Reranking: Modeller som Cohere Rerank, BGE eller MonoT5 kan re-evaluere hentede dokumenter, fange fine-grained relevans mønstre og forbedre resultater ud over rå lighed score. Kontekstudvidelse med iterativ retrieval: Statisk retrieval kan gå glip af indirekte relevante oplysninger. LLM'er kan identificere huller, generere opfølgningsforespørgsler og justere retrievalstrategien dynamisk for at indsamle manglende kontekst. Semantisk sammenhæng Filtrering Relevansbaseret omrangering Kontekstudvidelse med iterativ retrieval Nu, med disse opdateringer, er vores system bedre rustet til at håndtere komplekse spørgsmål på tværs af flere sektioner af et papir, samtidig med at man opretholder nøjagtigheden ved at grundlægge svar strengt i det angivne indhold. Men hvad sker der, når en enkelt kilde ikke er nok? Version 3.0 - Building a Comprehensive and Reliable System Version 3.0 - Opbygning af et omfattende og pålideligt system Ved dette tidspunkt er "ResearchIt" vokset fra et simpelt spørgsmålssvarssystem til en dygtig forskning assistent, der udtrækker nøgleafsnit fra uploadede papirer, fremhæver metoder og opsummerer teknisk indhold med præcision. Det, der begyndte som et system designet til at opsummere eller fortolke et enkelt papir, er nu blevet et værktøj, som forskere ønsker at bruge til dyb, tværdomæne begrundelse. Den nye bølge af spørgsmål ser ud som: "Hvilke optimeringsteknikker til transformatorer demonstrerer de bedste effektivitetsforbedringer, når man kombinerer indsigter fra benchmarks, open-source implementeringer og seneste forskningspapirer?" "Hvordan er modelkompression resultater rapporteret i dette papir i overensstemmelse med ydeevne rapporteret i andre papirer eller benchmark datasæt?" These are no longer simple retrieval tasks. They demand - evnen til at integrere og fortolke komplekse oplysninger, planlægge og tilpasse, bruge værktøjer effektivt, komme sig fra fejl og producere grundig, evidensbaseret syntese. multi-source reasoning På trods af sine stærke forståelsesevner kæmper "ResearchIt" 2.0 med to store begrænsninger, når man argumenterer på tværs af forskellige informationskilder: Cross-Sectional Analysis: Når svar kræver både fortolkning og beregning (f.eks. udtrækning af FLOP'er eller nøjagtighed fra tabeller og sammenligning af dem på tværs af betingelser). Cross-Source Synthesis: When relevant data lives across multiple systems - PDFs, experiment logs, GitHub repos, or structured CSVs - and the model must coordinate retrieval, merge conflicting findings, and produce one coherent explanation. Disse spørgsmål er ikke kun teoretiske. De afspejler virkelige udfordringer i AI skalerbarhed.Da dataøkosystemer bliver mere komplekse, skal organisationer bevæge sig ud over grundlæggende indhentning mod rationel orkestrering - systemer, der kan planlægge, handle, evaluere og kontinuerligt tilpasse sig. Lad os tage det første spørgsmål omkring analyse af transformatoroptimeringsteknikker - hvordan ville vi løse dette problem som mennesker? A group of researchers or students would work on “literature review, i.e, collating papers on the topics, researching open source github repos, and identifying benchmark datasets. They would then extract data and metrics like FLOPs, latency, accuracy from these resources, normalize and compute aggregations and validate the results produced. This is not a one-shot process; it’s iterative, involving multiple rounds of refinement, data validation, and synthesis, after which an aggregated summary of verified results would be generated. So, what exactly did we do here? Opdel det overordnede spørgsmål i mindre, fokuserede underproblemer - hvilke kilder man skal søge efter, hvilke målinger man skal analysere, og hvordan sammenligninger skal udføres. Rådfør dig med domæneeksperter eller pålidelige kilder for at udfylde vidensgap, krydstjekke målinger og fortolke kompromisser. Endelig syntetiserer indsigterne til en sammenhængende, evidensbaseret konklusion, sammenligner resultaterne og fremhæver konsekvente eller indflydelsesrige resultater gennem iterationer. This is, in essence, reasoned orchestration - the coordinated process of planning, gathering, analyzing, and synthesizing information across multiple systems and perspectives. It would be great if our system could also do something like this, right? This feels like a natural next step to question answering. Trin 1: Kæde af tænkning / planlægning For at tage fat på det første aspekt, evnen til at begrunde gennem flere trin før besvarelse, begrebet (CoT) blev indført. CoT tillader modeller at planlægge før udførelse, hvilket fremkalder struktureret ræsonnement, der forbedrer deres fortolkbarhed og konsistens. For eksempel, når man analyserer transformatoroptimeringsteknikker, vil en CoT-model først skitsere sin ræsonnementslinje - definere omfanget (træning effektivitet / model ydeevne / skalerbarhed), identificere relevante kilder, vælge evalueringskriterier og metoden til sammenligning og etablere en eksekveringssekvens. Kæden af tanke Kæden af tanke This structured reasoning approach became the foundation for LangChain-based orchestrations. As questions grew more complex, a single “chain” of reasoning evolved into Tree of Thought (ToT) or Graph of Thought (GoT) approaches - enabling branched reasoning and “thinking ahead” behaviors, where models explore multiple possible solution paths before converging on the best one. These techniques underpin today’s “thinking models,” trained on CoT datasets to generate interpretable reasoning tokens that reveal how the model arrived at a conclusion. Selvfølgelig indfører vedtagelsen af disse ræsonnementskrævende modeller praktiske overvejelser - primært omkostninger. Closed-source models like OpenAI’s o3 and o4-mini, which offer high reasoning quality and strong orchestration capabilities. Open-source alternatives such as DeepSeek-R1, which provide transparent reasoning with more flexibility/ engineering effort for customization. Mens ikke-tænkende LLM'er (som LLaMA 3) stadig kan efterligne ræsonnement gennem CoT-indkaldelse, udfører sande CoT- eller ToT-modeller iboende struktureret ræsonnement nativt. Trin 2: Arbejdsprocesser med flere kilder - Funktion Opkald til agenter Breaking down complex problems into logical steps is only half the battle. The system must then coordinate across different specialized tools - each acting as an "expert" - to answer sub-questions, execute tasks, gather data, and refine its understanding through iterative interaction with its environment. Åbent introduceret som det første skridt til at løse denne situation. Funktionsopkald / værktøjer gav LLM'erne deres første reelle evne til at i stedet for blot at forudsige tekst. Du giver modellen et værktøjskit - for eksempel funktioner som eller and the model decides which one to call, when to call it, and in what order. Let’s take a simple example: Funktionen kalder Tag handling search_papers(), extract_table(), Tilbage til statistikken() Funktionen kalder Task: “Compute the average reported accuracy for BERT fine-tuning.” En model, der bruger funktionsopkald, kan reagere ved at udføre en lineær kæde som denne: search_papers("BERT fine-tuning accuracy") extract_table() for hvert papir calculate_statistics() to compute the mean Dette dumme eksempel på en simpel deterministisk rørledning, hvor en LLM og et sæt værktøjer er orkestreret gennem foruddefinerede kodeveje, er enkel og effektiv og kan ofte tjene formålet for en række brugssager. og Når der er mere kompleksitet, er der en Det kan være den bedre løsning, når der er behov for fleksibilitet, bedre opgaveydelse og modeldrevet beslutningstagning på skalaen (med kompromis mellem forsinkelse og omkostninger). linear non-adaptive agentic workflow Agentisk arbejdsproces Iterative agentiske arbejdsprocesser er systemer, der ikke kun udfører én gang, men Ligesom en menneskelig forsker lærer modellen at tjekke sine trin, finpudse sine forespørgsler og forene modstridende data, før man drager konklusioner. reflect, revise, and re-run Tænk på det som et velkoordineret forskningslaboratorium, hvor hvert medlem spiller en særskilt rolle: Retrieval Agent: The information scout. It expands the initial query, runs both semantic and keyword searches across research papers, APIs, github repos, and structured datasets, ensuring that no relevant source is overlooked. Det analyserer PDF'er, tabeller og JSON-udgange, og standardiserer derefter de udvundne data - normaliserer målinger, forliger enheder og forbereder rene input til downstream-analyse. Computation Agent: The analyst. It performs the necessary calculations, statistical tests, and consistency checks to quantify trends and verify that the extracted data makes sense. Valideringsagent: Kvalitetsgatekeeper. Det identificerer anomalier, manglende poster eller modstridende resultater, og hvis noget ser ud, udløser det automatisk genstart eller yderligere søgninger for at udfylde hullerne. Det samler alle verificerede indsigter og komponerer den endelige evidensbaserede sammenfatning eller rapport. Hver enkelt kan anmode om præciseringer, genoptage analyser eller udløse nye søgninger, når konteksten er ufuldstændig, hvilket i det væsentlige danner en selvkorrigerende loop - en udviklende dialog mellem specialiserede ræsonnementssystemer, der afspejler, hvordan reelle forskningsgrupper arbejder. For at oversætte dette til et mere konkret eksempel på, hvordan disse agenter ville komme i spil for vores transformer effektivitet spørgsmål: Initial Planning (Reasoning LLM): The orchestrator begins by breaking the task into sub-objectives discussed before. First Retrieval Loop: The Retrieval Agent executes the plan by gathering candidate materials — academic papers, MLPerf benchmark results, and open-source repositories related to transformer optimization. During this step, it detects that two benchmark results reference outdated datasets and flags them for review, prompting the orchestrator to mark those as lower confidence. Extraction & Computation Loop: Next, the Extraction Agent processes the retrieved documents, parsing FLOPs and latency metrics from tables and converting inconsistent units (e.g., TFLOPs vs GFLOPs) into a standardized format. The cleaned dataset is then passed to the Computation Agent, which calculates aggregated improvements across optimization techniques. Meanwhile, the Validation Agent identifies an anomaly - an unusually high accuracy score from one repository. It initiates a follow-up query and discovers the result was computed on a smaller test subset. This correction is fed back to the orchestrator, which dynamically revises the reasoning plan to account for the new context. Iterative Refinement: Following the Validation Agent’s discovery that the smaller test set introduced inconsistencies in the reported results - the Retrieval Agent initiates a secondary, targeted search to gather additional benchmark data and papers on quantization techniques. The goal is to fill missing entries, verify reported accuracy-loss trade-offs, and ensure comparable evaluation settings across sources. The Extraction and Computation Agents then process this newly retrieved data, recalculating averages and confidence intervals for all optimization methods. An optional Citation Agent could examine citation frequency and publication timelines to identify which techniques are gaining traction in recent research. Final Synthesis: Once all agents agree, the orchestrator compiles a verified, grounded summary like - “ ” Across 14 evaluated studies, structured pruning yields 40–60 % FLOPs reduction with < 2 % accuracy loss (Chen 2023; Liu 2024). Quantization maintains ≈ 99 % accuracy while reducing memory by 75 % (Park 2024). Efficient-attention techniques achieve linear-time scaling (Wang 2024) with only minor degradation on long-context tasks (Zhao 2024). Recent citation trends show a 3× rise in attention-based optimization research since 2023, suggesting a growing consensus toward hybrid pruning + linear-attention approaches. Hvad der er magtfuldt her, er ikke bare slutresultatet - det er . process Hver agent bidrager, udfordrer og forfiner andres arbejde, indtil der opstår en stabil, multi-source konklusion. and MCP standardiserer, hvordan modeller og værktøjer udveksler strukturerede oplysninger - såsom hentede dokumenter, analyserede tabeller eller beregnede resultater - for at sikre, at hver agent kan forstå og bygge videre på andres outputs. Ved at supplere dette giver A2A-kommunikation agenter mulighed for at koordinere direkte med hinanden - dele mellemliggende argumenter, anmode om præciseringer eller udløse opfølgende handlinger uden indgriben. Modellen af kontekstprotokollen (MCP) Agent til agent (A2A) Modellen af kontekstprotokollen (MCP) Agent til agent (A2A) Trin 3: Sikring af grundighed og pålidelighed På dette stadium har du nu et agentistisk system, der er i stand til at nedbryde relativt komplekse og abstrakte forskningsspørgsmål i logiske trin, indsamle data fra flere kilder, udføre beregninger eller transformationer, hvor det er nødvendigt, og samle resultaterne i en sammenhængende, evidensbaseret sammenfatning. fakta - de forudsiger den næste mest sandsynlige token baseret på mønstre i deres træningsdata. Mens forbedrede datasæt og uddannelsesmål hjælper, kommer den virkelige sikkerhed ved at tilføje mekanismer, der kan verificere og korrigere, hvad modellen producerer i realtid. Kender Korrekt Here are a few techniques that make this possible: Regelbaseret filtrering: Definer domænespecifikke regler eller mønstre, der fanger åbenlyse fejl, før de når brugeren.For eksempel, hvis en model producerer en umulig metrik, et manglende datafelt eller et misdannet dokument-id, kan systemet flagge og regenerere det. Cross-verifikation: Automatisk genforespørgsel på betroede API'er, strukturerede databaser eller benchmarks for at bekræfte nøgletal og fakta. Self-Consistency Checks: Generate multiple reasoning passes and compare them. Hallucinated details tend to vary between runs, while factual results remain stable - so the model keeps only the majority-consistent conclusions. Sammen udgør disse lag den endelige beskyttelse - lukning af ræsonnementsløbet.Hvert svar, systemet producerer, er ikke kun velstruktureret, men . Verificeret Og her er - hvad der begyndte som en simpel retrieval-baseret model har nu udviklet sig til en robust forskning assistent: en, der ikke kun besvarer grundlæggende Q & A, men også adresserer dybe analytiske spørgsmål ved at integrere multi-kilde data, udføre beregninger og producere jordede indsigter, alt samtidig aktivt forsvare mod hallucinationer og misinformation.