En ny Colab-notebook til RAG-Anything samler tekst, tabeller, ligninger og billeder i én retrieval-arbejdsgang og viser, hvordan multimodal RAG kan sættes op uden tung forberedelse. Notebooken går fra dependency-install og syntetisk datasæt til søgning på tværs af modaliteter. Pointen er ikke kun, at det kører i Colab, men at opskriften kan løftes videre med overskuelige beslutninger – og nogle få uundgåelige valg om drift.
Hvad tutorialen konkret demonstrerer
Notebooken starter med miljøet: opsætning af mapper, logdir og cache-variabler samt en helper til shell-kommandoer, så celler kan genkøres stabilt. Dependencies installeres med pip, inklusive openai i version >=1.0.0 og en reinstall af pillow==11.3.0 for at sikre ensartet billedhåndtering. Reproducerbarheden er eksplicit med versionsudskrifter og oprydning.
Derefter konstrueres et syntetisk multimodalt rapportmateriale. Der genereres et diagram, laves en PDF og skrives indhold med tekst, tabeller og ligninger, så retrieval kan testes realistisk. Materialet omsættes til RAG-Anything’s content_list-format, som fjerner et lag implicit parsing og gør indsættelsen i retrieval-systemet gennemsigtig. Det gør det nemmere at forklare, hvorfor en given chunk medvirker i svaret.
Til sidst indsættes indholdet i retrieval-laget, og notebooken kører forespørgsler på tværs af modaliteter: enkle tekstspørgsmål, visuelle hints og opslag, der kræver tabelforståelse. Ikke en benchmark, men en ren funktionsprøve.
Komponenterne under hjelmen
Kernen består af tre OpenAI-baserede funktioner: en chat-funktion til generering, en vision-funktion til billedforståelse og en embedding-funktion til indeksering og semantisk søgbarhed. RAG-Anything initialiseres med klar konfiguration, så modeller og parametre kan byttes uden at røre resten af kæden.
Retrieval testes i fire modes: naive, local, global og hybrid. Naive er baseline. Local fokuserer på nærmeste kontekst eller dokumentdel og kan give hastighed ved fornuftig segmentering. Global udvider søgetrækket for højere recall, men koster flere embeddings og tokens. Hybrid kombinerer lokale signaler med et globalt sweep for at undgå tunnelsyn på én chunk. Forskellene kan aflæses i både tid og kroner.
Sikkerhed og reproducérbarhed i Colab
Notebooken beder om OpenAI API-nøglen ved runtime i stedet for at gemme den i koden. Det er fornuftigt, når notesbøger deles. Til drift kræves dog mere: secrets management, kortlevet token-rotation, begrænsede roller og audit logs.
Reproducerbarheden er bedre end typisk for Colab: miljøet ryddes, versioner vises, og pillow pin’es. Den sidste mil mangler: Dockerfile, requirements/constraints og en CI-pipeline, der bygger og tester indeksering deterministisk, så et minor-bump i pillow eller openai SDK ikke vælter kæden.
Hvor multimodaliteten gør en forskel
Brugsscenarierne er tydelige. Teknisk dokumentation med diagrammer, kodeuddrag og formler. Forskning og RFP-svar, hvor tabeltal og tekstresuméer skal samles hurtigt. Finansielle analyser, hvor footnotes i PDF’en og regnearket skal læses sammen. Multimodal retrieval løser cases, hvor man ellers skifter mellem flere værktøjer og mister kontekst.
Et vigtigt hjørne er konflikter mellem modaliteter. Når tabellen siger 7, og teksten siger “omtrent otte”, hvad vejer tungest? Tutorialen viser, at kilderne kan findes, men lader konfliktløsning være et applikationsansvar. I produktion bør der fastsættes regler eller vægte – for eksempel at tal fra tabeller prioriteres over tekst i samme dokument.
Drift og arkitekturvalg man ikke slipper uden om
Første valg: ét samlet vektorindeks for alle modaliteter eller separate indeks per modalitet. Ét indeks forenkler routing, men kan mudre semantik og kræver skarp metadata-design. Separate indeks gør optimering per modality lettere og finjusterer recall, men kræver bro for cross-modal hentning og fusion.
Andet valg: opdateringsstrategi. Skal embeddings regenereres løbende eller i batches? Ved høj “freshness” – fx supportartikler – vinder inkrementelle opdateringer. Ved tunge PDF’er og grafer kan batch styre omkostninger bedre. Latency påvirkes af chunkstørrelse og overlap; tutorialen viser CHUNK_SIZE 900 og OVERLAP 120 som startpunkter, der bør tunes til domænet.
Tredje valg: omkostninger. Vision-opslag er dyrere end tekst, da billedinput kræver tungere modelkald. Embeddings koster ved første indeksering og ved re-embed. Hybrid retrieval øger recall, men kan fordoble kald. Et simpelt cost-per-query-dashboard gør diskussionen faktuel.
Infrastruktur spiller også ind. CPU rækker til meget forarbejde, men tung vision-batch og PDF-parsing kan have gavn af GPU og IO-tuning ved større ingestion-jobs. Colab skalerer ikke til produktion; næste skridt er en administreret vectorstore (fx Pinecone, Milvus, Weaviate) eller Postgres med pgvector. Connector-koden er ikke i tutorialen – det hul bør lukkes tidligt.
Hvad man bør måle, før man forelsker sig
Tutorialen er en funktionsdemo, ikke en eval-suite. I praksis bør teams måle retrieval-precision og recall på et sæt ground-truth-spørgsmål, hallucination-rate i svarlaget, end-to-end latency og cost-per-query. Se også på fejltyper: forkerte modalitetsvalg, forkerte sidehenvisninger eller tal der afviger fra tabeller.
Der mangler en plan for modal-fusion-fejl. Når både tekst og billede returneres, hvilken vægt skal hver kilde have? Og hvornår skal vision overhovedet kaldes? En enkel heuristik – kald vision ved billede-links eller eksplicit cue i prompten – kan spare tid og tokens. Notebooken peger på behovet, men formaliserer det ikke.
Et sidespring til værktøjsrouting
VentureBeat beskriver Alibaba-forskningen SkillWeaver, der bygger en eksekveringsgraf og bruger en iterativ fetch-and-vet-tilgang til værktøjsvalg. I modsætning til one-shot routing loades ikke hele værktøjsbiblioteket, og rapporten fremhæver kraftigt reduceret tokenforbrug – op mod 99 procent i deres framing. Tal bør læses kritisk, men idéen er praktisk relevant.
For multimodale RAG-pipelines med mange eksterne værktøjer og indekser peger det mod mere selektiv routing og mindre default-bredde. Især når vision-kald er dyre, kan en iterativ udvælgelse – “er der behov for billede?” – skære tokens og tid markant. Tutorialen går ikke i dybden med routing, men arkitekturen kan udvides i den retning.
Næste skridt for teams der vil prøve det af
Start med en lille pilot i Colab med egne PDF’er, billeder og tabeller. Lås versionsnumre som i notebooken – openai>=1.0.0 og pillow==11.3.0 – og dokumentér miljøvariabler, chunking og parservalg. Mål allerede her latency og precision på et lille sæt spørgsmål.
Løft derefter til containere. Byg en Dockerfile, læg dependencies i en constraints.txt, og kør et CI-job, der reindekserer et lille korpus ved build for at fange knækkede parsere. Tilføj secrets via en vault eller GCP/AWS secrets manager med mindst mulige rettigheder. Først derefter giver staging og A/B-tests for retrieval mening.
I uge 4–6 bør logging og cost-monitoring være på plads, samt valg af vectorstore og migrationsstrategi for re-embeds. Afslut i uge 7–8 med brugeraccepttests, en enkel eval-suite og en compliance-gennemgang: PII-detektion, retention-politik for embeddings og audit af API-adgang.
Huller, der kræver opfølgning
Notebooken viser ikke systematiske benchmarks. Der er ingen tal for throughput, memory-forbrug ved stort billedkorpus eller cost-estimater ved skala. Funktionaliteten er klar, men næste skridt er målinger i eget domæne, så retrieval-mode og indeksstrategi kan vælges med ro.
Licens- og dependency-spørgsmål står åbne. Hvorfor er pillow fastlåst til 11.3.0, og er der kendte problemer med nyere? Hvad hvis openai-SDK’et ændrer response-objekter i en ny version? Det bør afklares i et CHANGELOG-notat og sikres med en lille compat-test i CI.
Konklusion
Tutorialen viser, at multimodal RAG kan samles i én pipeline med tekst, tabeller, ligninger og billeder, installerer nøgleværktøjer som openai>=1.0.0 og pillow==11.3.0 og demonstrerer brugbare retrieval-modes. Der mangler benchmarks, containertrinene og enterprise-sikkerheden, men strukturen er stærk nok til at bygge videre på. Næste gang notebooken åbnes, bør måleskema og Docker ligge klar ved siden af.
