Forskning i lægemidler drukner i egen viden. Ikke i mangel på data, men i sammenhængen. AWS peger nu på BYOKG og GraphRAG som metoden til at binde trådene fra PubMed, interne labnotater og genomdatabaser sammen i et fælles, søgbart overblik. Det er rigtigt set – og ambitiøst, for det rører ved både faglige arbejdsgange og it‑arkitektur på samme tid.
Problemet kort og hvorfor nu
Det meste relevante materiale ligger i siloer. Offentlige artikler i PubMed, rå observationer i labnotater, variantkataloger og ekspressionsdata i genomdatabaser. AWS beskriver, at forskere kæmper med at forbinde disse kilder på tværs, og at fragmenteringen sænker tempoet og risikerer, at sporbarheden til myndighedsgodkendelser skrider (AWS blog, 2301, leverandøroplysning). Billedet passer med, hvad mange i branchen har sagt i årevis. Men det er stadig svært at løse, for datatyperne er ujævne og opdateres i forskelligt tempo.
Hvad BYOKG og GraphRAG egentlig er
BYOKG betyder i praksis, at organisationen selv bringer sit domænespecifikke knowledge graph til bordet. GraphRAG er retrieval‑delen, hvor en sprogmodel henter svar ved først at traversere grafen for relevante noder, relationer og citatstier og derefter genererer et svar forankret i den evidens. Flowet er typisk sådan: dokumenter ind, udtræk af entiteter og relationer, opbygning af graf, tilføjelse af embeddings til semantisk match – og så RAG‑spørgsmål, der udnytter grafens struktur.
Amazon Neptune Analytics i maskinrummet
Til grafdelen peger AWS på Amazon Neptune Analytics. Ifølge dokumentationen er det en hukommelsesoptimeret grafmotor til analyse, som kan holde store grafer i hukommelsen for hurtige svar, inkluderer optimerede grafalgoritmer og understøtter lav‑latente grafspørgsmål samt vektorsøg i selve traversal‑processen. Den kan desuden indlæse data fra Neptune Database eller S3 og bruges til intensiv analyse ved at loade fra en database‑graf eller snapshot (AWS docs, 2304). Det er leverandørens egne specifikationer, men de er konkrete nok til at planlægge efter.
Hvorfor betyder det noget? Teknisk handler det om interaktivitet. Hvis en forsker ikke kan hoppe mellem hypoteser og relationer i nær‑realtid, dør nysgerrigheden. En in‑memory‑motor kan give millisekund til subsekund‑svar på grafforespørgsler, afhængigt af størrelse og mønstre. Dokumentationen lover hurtige iterationer på data, algoritmer og vektorsøg på grafer, men viser ikke pharma‑specifikke benchmarks. Det efterlader et åbent spørgsmål om faktiske latenser ved store, heterogene datasæt.
Arkitekturvalg der gør ondt at overse
Det begynder med indeksering. Enten opbevarer man embeddings direkte på noder og kanter, eller også lægger man dem i et separat vektorlag og linker via id’er. Førstnævnte giver enklere kontekst i traversal, sidstnævnte giver fleksibilitet til at skifte embedding‑model. Vælg bevidst – en blanding bliver dyr at vedligeholde.
Dernæst hele den ende‑til‑ende pipeline. Fra ingestion af PubMed og interne notater over Named Entity Recognition og relationsekstraktion til validering og versionering. Batch kontra streaming er et reelt tradeoff. Batch er simpelt og stabilt, men halter ved ny viden. Streaming kræver køer, validering i fart og skarpe rollback‑mekanismer, hvis en model laver fejludtræk. For mange lander det i en daglig batch og udvalgte kilder i near‑real‑time for at balancere friskhed og ro.
Udtræk og modellering uden mirakler
Informationsudtræk er ikke plug‑and‑play. Gode NER‑modeller til biomedicin findes, men de er følsomme for domæneskift og forkortelser. Relationsekstraktion er endnu sværere. En praktisk strategi er at starte med et fokuseret skema – forbind lægemiddel, target, pathway, variant, bivirkning – og udvide senere. Et for bredt skema i første hug giver støj og konsekvensarbejde i årevis.
Embeddings bør være domænespecifikke, ellers forfladiges lighedsmål. Det er fristende at bruge en stor generel model, men bio‑specifikke embeddings giver typisk bedre klynger og mere præcise nærmeste naboer. Ulempen er forvaltning af modelopdateringer. Derfor er versionering af embeddings ikke bare en note i backloggen; det er en overlevelsesmekanisme, så man kan rulle tilbage, når en ny model skubber nabolaget rundt.
Neptune i praksis for skalerbarhed og latency
Neptune Analytics fremhæver lav latenstid i grafforespørgsler, optimerede algoritmer og mulighed for at lægge store grafer i hukommelsen for hurtige analyser (AWS docs, 2304). Den kan loades fra Neptune Database eller S3 og dermed bruges som analyse‑accelerator frem for transaktionsmotor. Det passer til GraphRAG, hvor traversal‑spørgsmål ofte er læsetunge og eksperimenterende.
Begrænsninger og risici der bør være på tavlen
Datakvalitet først. Et flot grafschema hjælper ikke, hvis kilderne indeholder modstridende definitioner eller forældede klassifikationer. AWS nævner, at fragmentering kan gøre det svært at bevise evidensstier til regulatorer, og at viden går tabt ved jobskifte (AWS blog, 2301, leverandøroplysning). Det er plausible risici, men de løses kun, hvis provenance‑metadata er tvunget igennem på alle noder og kanter. Ingen genveje.
Hallucinationer i RAG er en klassiker. GraphRAG dæmper problemet, fordi svar forankres i grafevidens, men det fjerner ikke risikoen – især ikke, hvis retriever‑delen bruger for brede knuder eller embeddings med lav præcision. Læg dertil regulatoriske krav om sporbarhed. Uden versionsstempler, citatstier og audit‑logs kan man ikke dokumentere, hvorfor en hypotese opstod. Og så er der tacit knowledge: de bittesmå, ofte uformelle erfaringer fra forsøgsopstillinger. Selv en flot knowledge graph får ikke alt med.
Implementering der faktisk rykker
Start med et kildekort. Hvilke PubMed‑samlinger, hvilke interne notesystemer, hvilke genomdatabaser, hvilke kliniske studier? Har de samme identiteter for subjekter? Kan de deles lovligt og sikkert? Det lyder banalt, men et ærligt overblik over adgangsrettigheder, licenser og compliance‑betingelser er nummer ét. Ellers stopper projektet senere i en dørlås.
Afgræns et POC‑scope. Én sygdomsindikation, et par nøgletargets, tre primære kilder. Definér målepunkter, som ikke kan fortolkes ihjel. For eksempel tid fra spørgsmål til dokumenteret hypotese, antal unikke evidensstier pr. svar og andel svar med fuld citatspor. Sæt en tidshorisont på tre til seks måneder. Kortere, hvis kilderne allerede ligger samlet. Længere, hvis interne labnotater er ustrukturerede pdf’er i en gammel filserver.
Hvad succes realistisk giver
Den primære gevinst er time‑to‑hypothesis. Hurtigere vej til “det kunne være de her tre targets” – ikke nødvendigvis hurtigere vej til et godkendt lægemiddel. Hold udbyttet jordnært. GraphRAG kan også forbedre reproducérbarhed, fordi svar knyttes til konkrete stier i grafen. En tredje effekt er mindre redundans i litteraturarbejdet: færre gentagne manuelle reviews af de samme ti papers, fordi systemet husker relationerne.
Hvad løser det ikke? Det automatiserer ikke faglig dømmekraft. Det skriver ikke protokoller for dig. Og det eliminerer ikke fejl i kildedata. Hvis forventningen er en selvkørende forskningsassistent, bliver man skuffet. Hvis målet er et fælles, søgbart videnslag, hvor hypoteser understøttes med citater og relationer, er chancen for succes markant større.
Kort om alternativer og position
Der findes andre grafbaser som Neo4j og TigerGraph og kombinationer af dokumentdatabaser med vektorlag. Valget handler om økosystem, pris og værktøjer – ikke religion. Neptune Analytics positionerer sig som analyse‑accelerator med in‑memory‑fokus og tæt bånd til AWS‑stakken, inklusive indlæsning fra Neptune Database eller S3 og understøttelse af optimerede grafalgoritmer og vektorsøg i traversal (AWS docs, 2304). For teams, der i forvejen kører tungt på AWS, er det oplagt at prøve først.
På modellaget flytter markedet sig også. MarkTechPost rapporterer, at SpaceXAI har lanceret Grok 4.5 målrettet kodning, agentiske opgaver og knowledge work, og at modellen blev trænet sammen med Cursor‑editoren. Den publicerede pris er 2 dollar pr. million inputtokens og 6 dollar pr. million outputtokens ifølge artiklen (kilde 2303). Det er perifert for selve grafdelen, men relevant for totalomkostning, hvis man bruger hosted modeller til RAG‑svar. Bemærk at kilden her er sekundær omtale og ikke relateret til pharma eller Neptune‑ydelse.
Governance og QA i øjenhøjde
Compliance‑krav bør designes ind fra starten. Versionér alt. Dokumentnoder skal have versions‑id, timestamp, kilde og licens. Relationer skal pege på, hvilken udtræksmodel der skabte dem og med hvilken score. Gem traversal‑stier ved svar, ikke bare slutcitatet. Uden den slags metadata bliver det svært at overbevise en kvalitetsansvarlig om, at systemet er mere end en pæn demovideo.
Adgangskontrol og kryptering mangler detaljer i AWS’ blogindlæg. Der er ikke konkrete beskrivelser af, hvordan PHI håndteres, eller hvordan man opsætter finmasket adgang per kilde i en samlet GraphRAG‑stack. Det kræver dybere arkitekturdokumentation eller interviews med sikkerhedsarkitekter at binde sikkert sammen. Indtil da må man gå konservativt til værks og antage, at den sikreste løsning er den, man selv kontrollerer ende til anden.
Økonomi og drift uden overraskelser
In‑memory‑analyse er ikke gratis. Størrelsen på grafen, hyppige snapshots og flere miljøer til eksperimenter kan gøre regningen ujævn. Det taler for en bevidst livscyklus for grafer og for datasanering som fast rutine. Også for et skarpt blik på, hvilke forespørgsler der kræver lav latenstid, og hvilke der kan køre i baggrunden på billigere ressourcer.
Driftsmæssigt er det klogt at adskille produktionsgrafen, som understøtter RAG i daglig brug, fra en sandkassegraf, hvor datateamet kan køre tunge community‑detection‑jobs, re‑embeddings og schema‑ændringer. Ellers risikerer man, at et eftermiddagsforsøg lammer hele organisationens spørgesvar.
Huller i dokumentationen som bør udfyldes
To ting stikker ud. For det første mangler uafhængige valideringer af påstanden om fem procents succesrate og mere end seks måneders screeningstid i tidlig drug discovery. Tallet står i AWS’ blogindlæg uden peer‑reviewet reference (2301, leverandøroplysning). Det bør kvalificeres af eksterne studier, før det bruges som styringsmål. For det andet mangler performance‑tal for Neptune Analytics på pharma‑specifikke grafer – for eksempel størrelse, latency og køreomkostning på typiske traversal‑mønstre. Det ville gøre planlægning lettere.
Derudover er tekniske detaljer om, hvordan man gemmer citatstier, versionerer dokumentnoder og logger retrieverens valg, stadig tynde i offentligt materiale. Det kan løses, men kræver tid og disciplin. Og gerne eksempler på reference‑skemaer, som flere kan samles om.
Hvad gør man i morgen
Hvis man skal være konkret, peger det her på tre næste skridt. Først et kildekort og en licensafklaring – hvad må flyttes, hvorhen, og under hvilke betingelser. Dernæst et stramt POC‑scope med klart schema og målepunkter. Til sidst et valg af grafmotor og retriever‑stack, hvor Neptune Analytics er oplagt at teste, hvis AWS allerede er fundamentet, fordi den tilbyder in‑memory‑analyse, optimerede algoritmer, lav‑latente forespørgsler og vektorsøg i traversal (AWS docs, 2304).
Det hele lyder stort, men det behøver ikke starte sådan. En enkelt indikation. Tre kilder. En håndfuld pålidelige relationstyper. Når først man kan stille et spørgsmål og få et svar med en tydelig evidenssti, opdager man forskellen. Ikke i en powerpoint, men når man sidder med det i hænderne.
