OpenAI File Search: Interne dokumenter kræver governance, før du kan stole på dem

OpenAI har fået filbaseret retrieval til at se næsten for let ud. Opret en vector store, upload filer, og lad platformen håndtere chunking, embeddings og indeksering. Det er glimrende, når man hurtigt vil have en demo op at køre. Men det er ikke det samme som at have en vidensassistent, man vil stole på i en rigtig virksomhed. Den samme dokumentation, der får opsætningen til at se enkel ud, gør også udfordringen ved produktion tydelig: Retrieval holder op med primært at være et API-problem og bliver i stedet et governance-problem. File search kan returnere svar med filhenvisninger, og man kan også vælge at få de underliggende søgeresultater med. Det er nok til at vise, at noget virker. Det er ikke nok til at bevise, at svaret kom fra den rigtige version af det rigtige dokument til den rigtige målgruppe.

Det er den reelle forandring, når et team bevæger sig videre fra proof of concept. Kvaliteten af retrieval afhænger mindre af prompts til modellen og mere af kildematerialets tilstand. OpenAIs guide til retrieval forklarer, at vector stores ligger bag semantic search, og at filer automatisk opdeles i chunks, konverteres til embeddings og indekseres, når de tilføjes. Semantic search er nyttigt, fordi det kan finde relevante tekstpassager, selv når formuleringerne i forespørgslen og dokumentet ikke matcher præcist. Men den samme styrke bliver en svaghed, hvis samlingen er fuld af dubletter, forældede politikker, forskellige jurisdiktioner eller kladder uden tydelig status. En tekstpassage kan ligge semantisk tæt på forespørgslen og stadig være operationelt forkert.

Derfor bliver file search et governance-projekt

OpenAIs værktøjer til file search stiller de kontroller til rådighed, som er afgørende i produktion. Svar kan indeholde kildehenvisninger, men de rå søgeresultater returneres kun, hvis man specifikt beder om dem. Guiden til retrieval oplyser, at en søgning som standard returnerer op til 10 resultater, hvilket kan konfigureres til op til 50. Den understøtter også omskrivning af forespørgsler, filtrering efter attributter og styring af ranking, eksempelvis valg af ranker og tærskelværdier for score. Det er ikke uvæsentlige muligheder for finjustering. De afgør, hvilke dokumenter der overhovedet kan komme i betragtning, hvad modellen tilskyndes til at stole på, og hvor meget løst relateret kontekst man vil acceptere, at den blander ind i et svar.

Det praktiske spørgsmål er ikke, om OpenAI kan søge i filer. Det kan platformen. Det praktiske spørgsmål er, om organisationen kan forklare, hvorfor et bestemt svar blev vist, hvilke dokumenter der indgik i søgningen, hvordan forældet indhold blev frasorteret, og hvordan retrieval undersøges, når nogen anfægter et svar. Hvis det ikke kan forklares, er systemet endnu ikke reelt underlagt governance. Så er det stadig et indekseringseksperiment.

Kildesamlingen kræver som regel arbejde, før den kan indekseres forsvarligt

OpenAI understøtter en lang række filtyper til file search, herunder PDF, HTML, almindelige Office-dokumenter, kode, Markdown, JSON og ren tekst samt tekstkodninger som UTF-8, UTF-16 og ASCII. Fleksibiliteten er nyttig, men den gør det også let at uploade alt, hvad der tilfældigvis findes. De fleste interne dokumentationer er mere rodede, end teamet forventer: gentagne eksporter, forældede versioner, mødenoter placeret ved siden af godkendte politikker, sprogvarianter og filer, der ganske vist understøttes teknisk, men har en struktur, som fungerer dårligt til retrieval. Vector stores kan kun indeksere det materiale, de får. Oprydning er ikke valgfrit. Navngivning, deduplikering, versionsregler, sproglig normalisering og grundlæggende dokumenthygiejne har alt sammen betydning for, hvad modellen senere kan henvise til med sikkerhed.

Der er også en grundlæggende operationel detalje, som teams ofte overser i begyndelsen. Filoperationer foregår asynkront. Referencen til en fil i en vector store viser behandlingsstatus, seneste fejl og forbrugte bytes, så en uploadet fil er ikke automatisk klar til brug. Hvis nogle dokumenter stadig behandles, andre er fejlet, og endnu andre er blevet indekseret via et ældre workflow med ukendt chunking-adfærd, er vidensbasen allerede inkonsistent, før den første bruger stiller et spørgsmål.

Metadata gør retrieval styrbar

OpenAI stiller attributter til rådighed på filer i en vector store og understøtter filtrering i både retrieval-API'et og værktøjet til file search. Dokumentationen viser enkle filtre og sammensat logik med operatorer som eq, in, and og or. Det er her, en samling tilfældige dokumenter bliver til et anvendeligt retrieval-lag. Hvis filer mærkes efter region, forretningsenhed, fortrolighed, dokumenttype, ikrafttrædelsesdato, sprog eller indholdsstatus, kan mængden af kandidater indsnævres, før semantic search begynder at rangere tekstpassager. Springer man det trin over, kan modellen ende med at vælge mellem dokumenter, der aldrig burde have konkurreret med hinanden.

Gode metadata afspejler beslutningsgrænser, ikke kun mappenavne.
De mest nyttige attributter er dem, der afgrænser omfanget, før syntesen begynder.
Filtre bør afspejle reelle forretningsspørgsmål som jurisdiktion, målgruppe, aktualitet og følsomhed.

Referencen til vector stores giver også mulighed for metadata på selve den enkelte store samt navne, beskrivelser, status, registrering af forbrug og udløbspolitikker. Det er vigtigt, fordi governance foregår på to niveauer: den enkelte fil og den samling, filen indgår i. I mange tilfælde er én stor samling med navnet interne dokumenter den forkerte løsning. Forskellige afdelinger, sprog, fortrolighedsniveauer eller livscyklusregler kan tale for separate stores.

Valg af chunking er ikke neutralt

OpenAIs reference til vector stores oplyser, at standardstrategien for automatisk chunking i øjeblikket bruger en maksimal chunk-størrelse på 800 tokens med et overlap på 400 tokens. Den understøtter også en statisk strategi med konfigurerbart overlap og en maksimal chunk-størrelse på mellem 100 og 4096 tokens, hvor overlappet ikke må overstige halvdelen af chunk-størrelsen. Det er ikke blot en teknisk fodnote. Chunk-størrelsen påvirker, hvor meget kontekst der holdes samlet, hvordan tekstpassager konkurrerer i rangeringen, og hvor tydeligt et hentet uddrag kan føres tilbage til et sammenhængende afsnit i kildedokumentet.

En politikmanual, en teknisk runbook og en eksport af en præsentation fungerer ikke ens ved retrieval. Mindre chunks kan forbedre præcisionen, men de kan også adskille en instruktion fra dens forbehold. Større chunks bevarer konteksten, men kan svække rangeringen. Overlap reducerer problemer ved afgrænsninger, men øger samtidig redundansen. Den rigtige indstilling afhænger først og fremmest af dokumentklassen og først derefter af parameterværdien.

Styr på livscyklussen er afgørende, fordi lagerplads koster penge, og sletning ikke sker øjeblikkeligt

OpenAIs priser gør sjusket ingestion dyrt. Lagerplads til file search faktureres med $0.10 per GB per day efter den første gratis gigabyte, og værktøjskald faktureres separat. Objektet for en vector store registrerer forbrugte bytes, og filer i en vector store har også deres egne forbrugstal i bytes, som ikke nødvendigvis svarer til den oprindelige filstørrelse. Når lagerplads bliver målt og faktureret, bliver hver dublet, hvert forældet arkiv og hver glemt eksport både et kvalitetsproblem og et budgetproblem.

Kontrollen med livscyklussen er mindst lige så vigtig. Vector stores understøtter politikker for expires_after, som tager udgangspunkt i last_active_at og har et konfigurerbart antal dage. Guiden til retrieval oplyser, at de tilknyttede filer slettes, og faktureringen stopper, når en vector store udløber. Den bemærker også, at fjernelse af filer er eventually consistent, så fjernet indhold stadig kan optræde i søgeresultater i et kort tidsrum. Det er netop derfor, en produktionsløsning kræver regler for vedligeholdelse, procedurer for udskiftning og klare forventninger til, hvor hurtigt opdateringer slår igennem.

Sådan ser en kompetent implementering ud

En solid opsætning begynder som regel med en audit, ikke med en chatbot. Afgør først, hvad der overhovedet skal kunne søges i. Normalisér derefter filnavne, fjern dubletter, fastlæg versionsregler, og beslut, hvilke dokumenter der skal placeres i hvilke vector stores. Design herefter attributterne efter, hvordan virksomheden reelt har behov for at afgrænse svar. Tilpas chunking efter dokumentklasse, ikke efter vane. Vis kildehenvisninger til slutbrugerne, medtag rå søgeresultater under test og QA, og gennemgå tærskelværdierne for ranking, når assistentens svar begynder at lyde plausible, men upræcise.

Det er den type arbejde, Greg hos GrN kan hjælpe med uden at gøre teknologistakken til et forskningsprojekt: gennemgå kildesamlingen, normalisere filer, designe struktur og metadata til vector stores, finjustere indstillingerne for retrieval, tilføje kontrol af kildehenvisninger og forbinde workflowet med et CMS eller internt driftssystem ved hjælp af regler, som et team selv kan vedligeholde. Den underliggende teknologi kan allerede løse opgaven. Værdien opstår ved at gøre den pålidelig.

OpenAI har gjort retrieval langt lettere at lancere. Tilbage står den del, virksomheder ikke kan springe over: at beslutte, hvilken viden der kommer ind i systemet, hvordan den opdeles, hvordan den udløber, hvordan den filtreres, og hvordan organisationen kontrollerer, at et svar bygger på det rigtige materiale. På det tidspunkt er det ikke bare teknisk RAG-infrastruktur. Det er retrieval governance.

Har du brug for hjælp til denne type opgave?

Planlæg din opsætning til retrieval governance Kontakt Greg.

Kilder

Sidst ændret

2026-08-18