Denna artikel bygger på
Detta är en följeslagare bit till Det brutna löftet om den semantiska lagren, som täcker varför det traditionella tillvägagångssättet för att bygga semantiska lager faller kort och hur kontinuerlig semantisk utvinning erbjuder en bättre väg. Denna artikel går djupare in i den arkitektoniska frågan: vad kommer efter det semantiska lagret?
Det semantiska lagret förändrade datateamens arbete. AI behöver ta nästa steg.
Det semantiska lagret var en av de viktigaste idéerna inom modern datainfrastruktur. Innan det fanns, varje dashboard, varje rapport, hade varje analytiker sin egen version av "intäkter". Finans beräknade det på ett sätt. Marknadsföring en annan. Styrelsedäcket var en förhandling, inte en utläsning.
Cube, dbt MetricFlow och Looker's LookML ändrade det. De gav datateam en enda plats för att definiera affärslogik: vad MRR betyder, hur churn beräknas, vilka filter som gäller. De frikopplade det från något specifikt BI-verktyg. Definiera en gång, använd överallt. Det var ett genuint genombrott: konsekventa mått över team, en enda källa till sanning för beräkningar och affärslogik som kan vara versionsstyrd och granskad som kod. Det semantiska lagret vände "mitt nummer skiljer sig från ditt nummer" till ett lösligt problem. Det spelar ingen roll. Mycket hårt arbete gick in i att göra den kategorin verklig.
Men det semantiska skiktet var utformat för en specifik värld: en där människor skriver SQL, dashboards gör resultat, och semantiska skiktet sitter mellan dem för att säkerställa konsistens. Som ett semantiskt lager för AI, där agenter autonomt fråga dataDet byggdes aldrig för att hantera den bredd av sammanhang som krävs. I den ursprungliga världen fungerar den vackert.
Varje organisation har två lager av semantik. Det finns de explicit semantik: mått definitioner, formler och hierarkier som någon formellt skrev ner i Kuba, dbt eller LookML. Och det finns implicit semantik: hur organisationen faktiskt talar om och använder data. CFO:s mentala modell av vad "intäkter" betyder i ett styrelsesammanhang. Det faktum att marknadsföring betyder "gross" när de säger "intäkter" medan finans betyder "netto". Korrigeringen som någon gjorde i Slack förra torsdagen. Detta implicita skikt är kulturellt inbäddat, ständigt skiftande och nästan aldrig nedskrivet.
Innan AI var klyftan mellan explicit och implicit semantik hanterbar. En dataanalytiker vet att fråga "vilket intäkter menar du?" innan du kör en fråga. De fyller i det implicita sammanhanget naturligt, genom erfarenhet, konversationer och domänkunskap. Men en AI-agent har inte denna instinkt. Det tar den explicita definitionen till nominellt värde och tjänar ett självsäkert svar. Det semantiska lagret fångar det explicita. Ingen fångar implicit. Det är på väg att spela mycket mer.
Vi flyttar in i en annan värld. En där AI-agenter svarar på frågor, bygger rörledningar och ytrekommendationer. Och i den världen är det semantiska lagret nödvändigt, men det räcker inte.
Ett företag har ett väl underhållet semantiskt lager. Intäkter definieras som en mått. Churn definieras. Datateamet gjorde sitt jobb. En AI-agent frågas "Vad är våra intäkter i kvartalet?" Den använder intäktsmätningen från det semantiska lagret, frågar intäktsbordet och returnerar ett nummer. CFO ser på det och säger Det är fel. Vi rapporterar erkända intäkter till styrelsen, inte fakturerade intäkter.
Kan datateamet ha kodat den regeln i det semantiska lagret? Absolut. Cube och dbt MetricFlow stöder komplex affärslogik. Men ingen sa till dem. Skillnaden mellan fakturerade och erkända intäkter levde i en Confluence-sida och CFO:s huvud. Det semantiska lagret innehåller bara vad någon uttryckligen definierar, och det har inget sätt att upptäcka vad som saknas. För varje mått som intäkter finns det dussintals kontextuella regler, lagspecifika tolkningar och kantfall som inget datateam kan förutse och förutse. Det semantiska lagret var korrekt. Det var bara inte komplett. Och i skala kommer det aldrig att bli.
Gapet är inte ett dåligt semantiskt lager. Det är att den verkliga världen har mer sammanhang än någon manuellt kan formalisera uppåt. För att ge korrekta, pålitliga svar behöver en AI-agent:
- Semantiska definitioner (Vad saker betyder). mått formler, KPI beräkningar, affärs term ordlistor, dimensionella hierarkier, skattekalendrar. Detta är vad traditionella semantiska lager ger. Grunden.
- Affärsregler och logik (Hur saker fungerar). Villkorlig logik, undantag, domänspecifika spelböcker. "Styrelsen använder ASC 606 erkända intäkter med en månadsfördröjning." "EMEA inkluderar Turkiet för försäljningsrapportering men inte för GDPR-efterlevnad." Dessa lever i Confluence, Notion, folks huvuden. Inget semantiskt lager fångar dem.
- Data Landskap (Vad som finns och hur den ansluter). Tabellbeskrivningar, gå till vägar, entitetsupplösning över system, källa-of-sanning kartläggningar, spårbarhet, ägande. Datakataloger täcker delar av detta, men inget enda verktyg täcker allt.
- Kvalitet och förtroende signaler (Vad man kan lita på och vad man tvivlar på). Färskhet, fullständighet, anomali upptäckt, certifieringsstatus, kända frågor, förväntat värde varierar.
- Institutionell kunskap (vad organisationen har lärt sig). Korrigeringar från samtal, historiska sammanhang, lagspecifika konventioner, användningsmönster, personaspecifika tolkningar. Den kunskap som får dig från 85% till 99% noggrannhet.
- Operativa regler och AI-datastyrning (Hur agenten ska bete sig). Presentationspreferenser, analytiska konventioner, hårda gränser, varumärkesterminologi. "Alltid presentera intäkter i EUR för verkställande publik." "Flagga vilket resultat där provstorleken är under 30." Det handlar inte om vad data betyder. De handlar om hur agenten ska agera och hur AI-datastyrning verkställs i praktiken.
Ett traditionellt semantiskt lager ger det första objektet på denna lista. En AI-agent behöver alla sex. Lägg märke till att de sista fem inte ens handlar om datasemantik. De handlar om affärslogik, förtroende, organisatoriskt minne och beteenderegler. Därför är svaret inte ett bättre semantiskt lager. Det är ett bredare kontextskikt.
Bröd är bara hälften av problemet. Den andra hälften är att traditionella semantiska lager är statiska. Ett datateam bygger definitioner i förväg, sedan uppdaterar dem reaktivt när någon filer en biljett. Denna kadens fungerade när dashboards var den primära konsumenten. Men när AI-agenter ger varje anställd direkt tillgång till data exploderar prospekteringshastigheten. Nya mått kommer från hur människor faktiskt använder data. Nya frågor dyker upp som ingen förväntade sig. Kontextskiktet kan inte vara en fil som granskas kvartalsvis. Det måste vara en levande artefakt som utvecklas med verksamheten.
Fällan med två parallella sanningskällor
Här är fällan som varje AI-analysplattform faller in i: de inser att agenter behöver institutionella sammanhang, så att de bygger sitt eget semantiska lager. Nu har du två.
Finance definierar "intäkter" i dbt MetricFlow. AI-plattformen har också en "intäkt" definition i sin egen kunskapsbutik. Vilken vinner?
Värre: definitionen dbt uppdateras nästa kvartal eftersom CFO ändrar hur intäktsigenkänning fungerar. Vet AI-plattformen? Dröjer det tyst? Vem är ansvarig för att hålla dem synkroniserade? Datateamet upprätthåller nu definitioner på två ställen, vilket är strikt värre än att behålla dem på ett.
Ingen vill ha två sanningskällor. Och att berätta ett datateam "bara behålla dina definitioner i vårt verktyg i stället" är en icke-starter när de har år av arbete investerat i dbt, Cube eller LookML.
Detta problem försvinner när du tänker på det annorlunda.
Google är inte värd för webbplatser. Den indexerar webben. Det samlar in information från miljontals källor, gör det fint och ytor när två källor säger motsägelsefulla saker. Googles värde lagrar inte innehåll. Det är att federera tillgång till innehåll som lever överallt.
En dataplattform bör inte försöka vara det semantiska lagret. Det bör läsas från alla semantiska lager, ordlistor, dokumentation och metadata som redan finns och lägga till intelligensen ovanpå.
Vad detta innebär för ditt befintliga semantiska lager
Det blir mer värdefullt, inte mindre. Idag tjänar dina Cube eller dbt MetricFlow-definitioner dina dashboards. Med ett federerat kontextlager som läser av dem tjänar samma definitioner nu varje AI-agent, varje Slack-fråga, varje API-anrop, berikad med kvalitetssignaler, affärsregler och institutionellt minne som Kuba ensam inte kan bära. Du investerade i ditt semantiska lager. Nu fungerar investeringen hårdare.
Vad ett federerat kontextlager faktiskt är
Ett Federerat kontextskikt aggregat, avstämning och berikar institutionella sammanhang från var den än lever. Det är bredare än ett semantiskt lager (det innehåller allt som en AI-agent behöver, inte bara mått definitioner) och det är federerat (det läser från befintliga verktyg snarare än att ersätta dem).
Fem förmågor definierar det:
Aggregat
Ansluter till varhelst sammanhanget lever idag: dbt YAML-filer, kub semantiska modeller, Looker LookML, Confluence-sidor, Notion-databaser, CSV-dataordböcker, lager information_schemaoch direkta användarsamtal. Kontext är aldrig på ett ställe. Det federerade kontextskiktet möter det där det är.
Rekonciler
Dataförsoning över källor är ett av de svåraste olösta problemen i företagsdata. När två källor definierar samma term på olika sätt upptäcker systemet avvikelsen och ytbehandlar den med bevis. Inte en vag varning, det ger konkreta data: som använder vilken definition, hur ofta, i vilket sammanhang och var de skiljer sig. Exakta matcher slås samman. Semantiska överlappningar är kopplade. Motsättningar flaggas för mänsklig upplösning.
Rekommenderar
Proaktivt föreslår vad som saknas: mått definitioner som refereras men aldrig formellt definierade, härledda tabeller som återanvänds över många frågor, datakällor som skulle fylla ett gap, går med i att företagsanvändare ofta begär. Systemet föreslår. Människor bestämmer.
Butiker
Det federerade kontextskiktet innehåller en infödd butik så att du aldrig behöver anta ett separat verktyg bara för att komma igång. För team utan befintliga semantiska verktyg är det primära kontextskiktet från dag ett. För team med kub eller dbt, läser den från dessa verktyg och den inhemska butiken fångar bara vad de inte kan: korrigeringar från konversationer, affärsregler som uppstod genom användning, kvalitetssignaler från övervakning. Detta är inte en konkurrerande källa till sanning. Det är lagret som håller allt ditt semantiska lager var aldrig utformat för att hålla.
Lärdomar
Varje konversation, korrigering, godkännande och uppsägning berikar sammanhanget kontinuerligt. När AI-agenter ger varje anställd självbetjäning tillgång till data exploderar hastigheten på nya frågor. Kontexten lager publik källor dessa analystrender: vad mått får ställs om de flesta, vilka definitioner får korrigeras, vilka tabeller blir anslutna upprepade gånger, vilka frågor kan inte besvaras. Det yttrar dessa mönster till datateamet som användbara rekommendationer. Istället för att vänta på biljetter formaliserar datateamet proaktivt vad verksamheten redan gör.
Spektrumet
Det federerade kontextskiktet tjänar alla team, oavsett mognad:
För alla tre är resultatet detsamma: ett enhetligt sammanhang som är bredare än någon enda källa, aktivt avstämda och kontinuerligt lärande.
Så fungerar det i praktiken
När definitionerna redan finns i flera verktyg
Ett företag har mått definitioner i dbt, en data ordlista i Confluence och affärsregler som lever i människors huvuden.
Det federerade kontextskiktet ansluter till alla tre och driver dataförsoning över dem. Den importerar 47 definitioner från dbt, 23 från Confluence. Det korsar dem och finner 8 motsägelser som teamet aldrig visste om. "Revenue" i dbt utesluter återbetalningar; "Revenue" i Confluence inkluderar dem. Båda har använts i två år. Varken teamet visste att den andras definition var annorlunda.
När företagsanvändare börjar ställa frågor genom agenter, observerar systemet vad som ställs och hur data används. Från dessa användningsmönster föreslår det 12 nya definitioner som ingen hade formaliserat ännu och flaggar 5 dataluckor där en mått definieras men inga data existerar för att beräkna den.
Allt flyter genom en enda granskningsyta. Datateamet löser motsägelser, antingen genom att uppdatera källan (tryck fixen till dbt) eller genom att lagra resolutionen direkt. De accepterar, ändrar eller avfärdar varje rekommendation. Systemet lär sig av varje beslut.
När du börjar från grunden
Ett företag utan semantiskt lager, ingen ordlista, inga formaliserade definitioner.
Datateamet avslöjar sina lagertabeller till plattformen. Företagsanvändare börjar ställa frågor genom agenter. Varje korrigering blir permanent institutionell kunskap. "Det numret ser fel, exkludera provkonton från MRR" är inte bara en engångsfix. Det blir en ihållande regel som gäller för varje framtida MRR-fråga, från varje användare, via varje kanal.
Inom några veckor har datateamet ett arbetskontextskikt med dussintals definitioner, kvalitetsbaslinjer och rekommendationer. Det är något som skulle ha tagit månader att bygga manuellt i dbt eller kub. Om de senare antar dbt kan de exportera dessa definitioner för att fröa den. Inget lås-in.
När en extern agent behöver data
En Claude Code-session, en anpassad automation eller en intern agent kallar plattformens API: "hitta kundens livstidsdata."
De federerade kontextskiktsrutterna genom alla tillgängliga sammanhang: den godkända CLV-definitionen (ursprungligen importerad från dbt), kundtabelldokumentationen från dbt-projektet, kvalitetssignalen som bekräftar betalningsbordet är färsk, affärsregeln att CLV ska använda ett 24-månaders bakåtblicksfönster (fångad från en konversationskorrigering förra månaden).
Agenten får ett fullständigt, kontextuellt svar med full kontroll. Inte bara en tabell namn och kolumn lista, men vad data betyder, hur tillförlitlig det är, och var definitionen kom från. Detta är skillnaden mellan en agent som ger korrekta svar och en som ger rimliga gissningar.
Varför detta är viktigt nu
Det semantiska datalagret för AI hade sitt breakout-ögonblick 2024-2025. Varje större dataleverantör konvergerade på samma insikt: AI-agenter behöver institutionella sammanhang för att ge korrekta svar. Kuba samlade in finansiering. dbt skickade MetricFlow. Snowflake lanserade Cortex med semantiskt modellstöd. Analytiker började skriva om "semantiskt lager imperativ." Branschen gick med på: du kan inte bara peka en LLM på ett lager och hoppas på det bästa. Du behöver ett lager av affärsmässig betydelse mellan data och agent.
De hade rätt. Och resultaten visade det: företag som investerade i ett semantiskt lager såg mätbart bättre AI-noggrannhet än de som inte gjorde det.
Men ett mönster uppstod. Även företag med väl underhållna semantiska lager träffade ett tak. Agenten kan få mått definitioner rätt, men det missade fortfarande affärsregler som levde i Confluence. Dessa är symptom på tre strukturella hinder för självbetjäning analys, kostnad, noggrannhet och styrning, som förenas i stor skala. Det visste fortfarande inte om datakvalitetsfrågan från förra tisdagen. Det kunde fortfarande inte förena det faktum att marknadsföring och finans använder "intäkter" annorlunda, eftersom båda definitionerna var tekniskt korrekta i sina respektive sammanhang, och det semantiska lagret hade bara plats för ett.
Det semantiska lagret löste det mått konsistensproblemet. Men agenter behöver inte bara mått konsistens. De behöver hela bilden: mått plus affärsregler plus kvalitetssignaler plus stamkunskap plus dataförsoning över källor. Och upprätthålla allt detta i separata verktyg (ett semantiskt lager här, en datakatalog där, en kvalitetsövervakning någon annanstans) är inte realistiskt för ett team av 1-3 data personer. AI-datastyrning, styrning av vilka agenter som kan komma åt, hur de beter sig, och vilka regler de följer, kan inte bultas på efter det faktum. Det måste byggas in i själva kontextskiktet.
Det framväxande behovet är ett enda lager som federerar hela ett företags institutionella sammanhang, från vilka verktyg som redan håller det, till en försonad, kontinuerligt lärande yta som agenter kan fråga.
Varför det måste federeras: Eftersom inget verktyg någonsin kommer att hålla alla sammanhang. dbt har mått definitioner. Datakataloger som Databricks Unity Catalog, Alation eller Atlan håller spårbarhet, ägande och certifieringar. Confluence håller affärsprocesser. Slack håller korrigeringar och tribal kunskap. Datalagret innehåller strukturella metadata. En plattform som försöker ersätta alla dessa kommer att misslyckas; det finns för mycket yta, för mycket organisatorisk tröghet. Ett Data discovery plattform som läser av dem alla och stämmer av dem lyckas just eftersom det inte ber någon att ändra hur de fungerar.
Varför detta kräver vertikal integration
Att bygga ett federerat kontextskikt är inte en funktion som du bultar på ett befintligt verktyg. Det kräver tre saker som arbetar tillsammans:
Ett avrättningsskikt som ser varje fråga
Om du inte äger frågan utförande, kan du inte lära av användning. Du vet inte vilka definitioner som används, vilka korrigeringar görs, vilka frågor som inte kan besvaras. Ett semantiskt lager som kub definierar mått, men det ser inte frågorna. Ett lager som Snowflake driver SQL, men det ser inte verksamheten avsikt bakom det.
En kunskapsgraf som lagrar och relaterar sammanhang
mått definitioner, affärsregler, kvalitetssignaler, korrigeringar och stamkunskaper är inte platta filer. De relaterar till varandra: detta mått beror på den tabellen, som korrigerades av denna användare och motsäger den importerade definitionen. Du behöver en grafstruktur för att fånga dessa relationer, inte en annan YAML-fil.
Ett intagsskikt som ansluter till källor
Federation betyder att läsa från dbt, Confluence, Notion, lagermetadata och samtal. Det kräver inhemska kontakter och en försoningsmotor som kan analysera strukturerade definitioner, jämföra dem mot befintlig kunskap och ytmotsättningar intelligent.
Inget enskilt ändamål verktyg har alla tre. Ett semantiskt lager har definitioner men inte utförande. Ett lager har utförande men inte kunskap. En datakatalog har metadata men inte frågor. Det federerade kontextskiktet sitter vid korsningen, och den korsningen kräver en vertikalt integrerad plattform.
Ronja byggdes så här från början. Den äger AvrättningsskiktSå det ser varje fråga och varje korrigering. Den har en ihållande Kunskapsgraf där varje definition, regel och korrigering lagras med relationer till tabeller, användare och andra definitioner. Och den har Infödda kontakter och en Försoningsmotor import från dbt, Looker, Confluence och alla strukturerade format.
Dessa är inte funktioner som läggs till efter faktum. Det federerade kontextskiktet är arkitekturen.
Det här förändras
Sluta bibehålla definitioner på sex ställen och hoppas att de är synkroniserade. Det federerade kontextskiktet stämmer av dem för dig, ytor där de avviker och rekommenderar vad som saknas. Ännu viktigare, det visar dig vad verksamheten faktiskt behöver baserat på verklig användning, så du arbetar med det som är mest viktigt. Dina befintliga verktyg fortsätter att fungera, och de blir mer värdefulla.
AI-analys är faktiskt ett kontextproblem, och AI-datahantering är ett kontextproblem också. Kontexten federeras av naturen; den lever i dbt, i Confluence, i människors huvuden, i Slack trådar. Plattformen med det rikaste och mest avstämda sammanhanget blir standarddatabackend för varje agent i företaget.
Det semantiska lagret var steg ett. Den löste mått konsistens för dashboards. Det federerade kontextskiktet är steg två. Det löser agentens noggrannhet i skalan, bredden och hastigheten som AI-första analys kräver. Inte genom att ersätta det som existerar, utan genom att göra allt arbete tillsammans.
Viktigaste slutsatserna
- Det semantiska lagret löser mått konsistens, men AI-agenter behöver sex kategorier av sammanhang, inte bara mått definitioner.
- Att bygga ett andra semantiskt lager i din AI-plattform skapar ett två-källor-av-sanningsproblem som blir värre över tiden
- Ett federerat kontextskikt läser från befintliga verktyg (dbt, Cube, Confluence, lagermetadata) i stället för att ersätta dem.
- Fem funktioner definierar det: aggregat, avstämning, rekommenderar, butiker och lärdomar
- Detta kräver vertikal integration, ett utförandeskikt, en kunskapsgraf och ett intagsskikt som arbetar tillsammans
Vanliga frågor
Vad är ett federerat kontextskikt?
Ett federerat kontextskikt aggregerar, stämmer av och berikar institutionellt sammanhang från varhelst det redan bor, dbt definitioner, kubmodeller, Confluence-sidor, lagermetadata och användarsamtal. Det är bredare än ett semantiskt lager (som täcker affärsregler, kvalitetssignaler och institutionell kunskap, inte bara mått) och federerad (det läser från befintliga verktyg snarare än att ersätta dem).
Hur skiljer sig ett federerat kontextskikt från ett semantiskt lager?
Ett semantiskt lager definierar mått formler och affärsvillkor. Ett federerat kontextskikt innehåller mått definitioner men också affärsregler, kvalitetssignaler, institutionell kunskap och regler för operativ styrning, det fullständiga sammanhanget en AI-agent måste ge korrekta svar. Det federerar också över flera verktyg snarare än att kräva alla definitioner på ett ställe.
Ersätter ett federerat kontextskikt dbt eller kub?
Nej. Den läser från dem. Dina dbt- eller kubdefinitioner fortsätter att tjäna dina dashboards. Det federerade kontextskiktet importerar dessa definitioner, berikar dem med sammanhang som dessa verktyg inte kan bära (kvalitetssignaler, affärsregler, stamkunskaper) och gör dem tillgängliga för varje AI-agent och varje yta. Dina befintliga verktyg blir mer värdefulla, inte mindre.
Vad är "två källor till sanning" problemet?
När en AI-analysplattform bygger sitt eget semantiska lager tillsammans med en befintlig (som dbt), slutar datateamet att upprätthålla definitioner på två ställen. När man blir uppdaterad och den andra inte, de tyst glider isär. Ett federerat tillvägagångssätt undviker detta genom att läsa från befintliga verktyg i stället för att duplicera dem.
Varför kräver ett federerat kontextskikt vertikal integration?
Det kräver tre saker som arbetar tillsammans: ett avrättningsskikt som ser varje fråga (för att lära av användning), en kunskapsgraf som lagrar och relaterar sammanhang och ett intagsskikt som ansluter till externa källor. Inget enskilt syfte verktyg, oavsett om ett semantiskt lager, ett lager eller en datakatalog, har alla tre.
Vad är AI datastyrning i detta sammanhang?
AI-datastyrning hänvisar till de regler som styr hur AI-agenter får tillgång till och presenterar data: vad de kan se, hur de ska bete sig, vilka gränser som gäller. I ett federerat kontextskikt är dessa regler en del av själva kontexten, verkställd arkitektoniskt, inte genom snabba instruktioner, så de tillämpar konsekvent oavsett vilken agent eller kanal som används.
