Strukturerte entiteter gir coreAI muligheten til å skille et produkt fra en PDF, en stillingsannonse eller en kontaktperson — noe en flat tekstimport ikke klarer. Når kildesystemet sender riktig type, kan assistenten svare med riktig kontekst, og de samme feltene kan brukes som filtre senere.
#Hvorfor strukturerte entiteter slår en flat tekstimport
Hvis alt som havner i kunnskapsbasen er rå tekst, må modellen gjette om en passasje beskriver et produkt, en hjelpeartikkel eller en person. Gjettingen treffer ofte godt nok til å svare omtrentlig, men ikke godt nok til å vise et produktbilde, en pris eller riktige kontaktopplysninger når brukeren faktisk spør om akkurat det.
Når dataene sendes inn som typede entiteter, vet coreAI hva hver rad representerer. Et produktkort kan presenteres med pris og lagerstatus, en stillingsannonse kan holdes utenfor et generelt FAQ-svar, og en PDF kan refereres som dokumentasjon i stedet for marketing-tekst. Resultatet er svar som matcher spørsmålet både i innhold og form.
#De syv entitetstypene coreAI forstår
API v2 støtter syv entitetstyper, og hver type har sine egne påkrevde felter:
products— produktkatalog med navn, produktnummer, pris, lagerstatus og bilder. KrevernameogproductNumber.contents— artikler, hjelpetekster og redaksjonell marketing-copy. KrevernameoglongDescription.documents— PDF-er og annen formell dokumentasjon.events— tidsstyrte oppføringer som arrangementer, webinarer og åpne dager.educations— kurs, studieprogrammer og opplæringsløp.job_postings— utlyste stillinger.contacts— personer og roller, med e-post, telefon og arbeidssted.
Alle typene bruker samme upsert-løype mot /assistants/{assistantId}/sources/{contentImporterId}, men attributes-blokken og settet med påkrevde felter varierer. Det er type-feltet som avgjør hvordan coreAI lagrer, indekserer og presenterer entiteten i et svar.
#Properties gjør entitetene filtrerbare
Hver entitet kan ha en properties-blokk med korte, strukturerte verdier — categoryName, publishedAt, market og lignende. Bruk camelCase-navn og en av fire typer: string, number, boolean eller date. Properties er ikke ment for langtekst; de er metadata som beskriver entiteten på en måte som kan sammenlignes og sorteres.
De samme nøklene blir filterfelt i chat- og søkekall. coreAI støtter disse operatorene:
$eq— eksakt likhet, for eksempelmarket = "no"$gt,$gte,$lt,$lte— sammenligninger på tall og datoer, for eksempelpublishedAt >= "2026-01-01"$in— verdien er én av en gitt liste, for eksempelcategoryName in ["jakker", "bukser"]
Filtrene legges på filters-feltet i et chat- eller søkekall, og coreAI bruker dem til å begrense hvilke entiteter som er kandidater for svar. Det betyr at du kan fylle kunnskapsbasen bredt — alle markeder, alle kategorier, alle publiseringsnivåer — og likevel be ett bestemt kall om å svare fra bare ett utvalg.
#Når en filtrert assistent er riktig svar
Et typisk eksempel: en bedrift driver nettbutikker i flere land med felles produktkatalog, men hver butikk skal bare vise sine egne produkter og priser. I stedet for å bygge én assistent per marked sender du alle produktene inn med en market-property ("no", "se", "dk") og lar widgeten på hver butikk passere { "market": { "$eq": "no" } } i chat-kallet. Samme mønster fungerer for å skille publiserte fra interne dokumenter, eller for å la et søk vise bare arrangementer som ennå ikke har funnet sted (startDate med $gte på dagens dato).
Den robuste integrasjonen er å typebestemme entitetene riktig fra start, holde et lite og gjennomtenkt sett med properties, og bruke filtre i stedet for å duplisere assistenter når én logisk kunnskapsbase skal serveres til flere kontekster.