Strukturerade entiteter ger coreAI möjligheten att skilja en produkt från en PDF, en jobbannons eller en kontaktperson — något som en platt textimport inte klarar. När källsystemet skickar rätt typ kan assistenten svara med rätt kontext, och samma fält kan användas som filter senare.
#Varför strukturerade entiteter slår en platt textimport
Om allt som hamnar i kunskapsbasen är råtext måste modellen gissa om en passage beskriver en produkt, en hjälpartikel eller en person. Gissningen träffar ofta tillräckligt bra för att svara ungefärligt, men inte tillräckligt bra för att visa en produktbild, ett pris eller rätt kontaktuppgifter när användaren faktiskt frågar om just det.
När datan skickas in som typade entiteter vet coreAI vad varje rad representerar. Ett produktkort kan presenteras med pris och lagerstatus, en jobbannons kan hållas utanför ett generellt FAQ-svar, och en PDF kan refereras som dokumentation i stället för marknadsföringstext. Resultatet är svar som matchar frågan både i innehåll och form.
#De sju entitetstyperna coreAI förstår
API v2 stöder sju entitetstyper, och varje typ har sina egna obligatoriska fält:
products— produktkatalog med namn, produktnummer, pris, lagerstatus och bilder. KrävernameochproductNumber.contents— artiklar, hjälptexter och redaktionell marknadsföringscopy. KrävernameochlongDescription.documents— PDF:er och annan formell dokumentation.events— tidsstyrda poster som evenemang, webbinarier och öppna dagar.educations— kurser, studieprogram och utbildningar.job_postings— utlysta tjänster.contacts— personer och roller, med e-post, telefon och arbetsplats.
Alla typer använder samma upsert-väg mot /assistants/{assistantId}/sources/{contentImporterId}, men attributes-blocket och uppsättningen obligatoriska fält varierar. Det är type-fältet som avgör hur coreAI lagrar, indexerar och presenterar entiteten i ett svar.
#Properties gör entiteterna filtrerbara
Varje entitet kan ha ett properties-block med korta, strukturerade värden — categoryName, publishedAt, market och liknande. Använd camelCase-namn och en av fyra typer: string, number, boolean eller date. Properties är inte tänkta för långtext; de är metadata som beskriver entiteten på ett sätt som kan jämföras och sorteras.
Samma nycklar blir filterfält i chatt- och sökanrop. coreAI stöder dessa operatorer:
$eq— exakt likhet, till exempelmarket = "se"$gt,$gte,$lt,$lte— jämförelser på tal och datum, till exempelpublishedAt >= "2026-01-01"$in— värdet är ett av en given lista, till exempelcategoryName in ["jackor", "byxor"]
Filtren läggs på filters-fältet i ett chatt- eller sökanrop, och coreAI använder dem för att begränsa vilka entiteter som är kandidater för svar. Det betyder att du kan fylla kunskapsbasen brett — alla marknader, alla kategorier, alla publiceringsnivåer — och ändå be ett enskilt anrop svara från endast ett urval.
#När en filtrerad assistent är rätt svar
Ett typiskt exempel: ett företag driver webbutiker i flera länder med gemensam produktkatalog, men varje butik ska bara visa sina egna produkter och priser. I stället för att bygga en assistent per marknad skickar du in alla produkter med en market-property ("se", "no", "dk") och låter widgeten i varje butik passera { "market": { "$eq": "se" } } i chattanropet. Samma mönster fungerar för att skilja publicerade från interna dokument, eller för att låta en sökning visa endast evenemang som ännu inte har ägt rum (startDate med $gte på dagens datum).
Den robusta integrationen är att typbestämma entiteterna rätt från start, hålla en liten och genomtänkt uppsättning properties, och använda filter i stället för att duplicera assistenter när en logisk kunskapsbas ska serveras till flera kontexter.