Strukturierte Entitäten geben coreAI die Möglichkeit, ein Produkt von einem PDF, einer Stellenanzeige oder einer Kontaktperson zu unterscheiden — was ein flacher Textimport nicht leisten kann. Wenn das Quellsystem den richtigen Typ liefert, kann der Assistent mit dem passenden Kontext antworten, und dieselben Felder lassen sich später als Filter verwenden.
#Warum strukturierte Entitäten einen flachen Textimport schlagen
Landet alles als Rohtext in der Wissensdatenbank, muss das Modell raten, ob ein Abschnitt ein Produkt, einen Hilfeartikel oder eine Person beschreibt. Das Raten trifft oft gut genug, um näherungsweise zu antworten, aber nicht gut genug, um ein Produktbild, einen Preis oder die richtigen Kontaktdaten zu zeigen, wenn der Nutzer genau danach fragt.
Wenn die Daten als typisierte Entitäten eingespielt werden, weiß coreAI, was jede Zeile darstellt. Eine Produktkarte lässt sich mit Preis und Lagerbestand zeigen, eine Stellenanzeige bleibt aus einer allgemeinen FAQ-Antwort heraus, und ein PDF lässt sich als Dokumentation referenzieren statt als Marketing-Text. Das Ergebnis sind Antworten, die zur Frage passen – inhaltlich und in der Form.
#Die sieben Entitätstypen, die coreAI versteht
API v2 unterstützt sieben Entitätstypen, und jeder Typ hat eigene Pflichtfelder:
products— Produktkatalog mit Name, Produktnummer, Preis, Lagerbestand und Bildern. ErfordertnameundproductNumber.contents— Artikel, Hilfetexte und redaktionelle Marketing-Copy. ErfordertnameundlongDescription.documents— PDFs und andere formelle Dokumentation.events— zeitgesteuerte Einträge wie Veranstaltungen, Webinare und Tage der offenen Tür.educations— Kurse, Studiengänge und Schulungspfade.job_postings— ausgeschriebene Stellen.contacts— Personen und Rollen, mit E-Mail, Telefon und Arbeitsort.
Alle Typen nutzen denselben Upsert-Pfad gegen /assistants/{assistantId}/sources/{contentImporterId}, aber der attributes-Block und das Set der Pflichtfelder unterscheiden sich. Das type-Feld entscheidet, wie coreAI die Entität speichert, indexiert und in einer Antwort darstellt.
#Properties machen Entitäten filterbar
Jede Entität kann einen properties-Block mit kurzen, strukturierten Werten haben — categoryName, publishedAt, market und Ähnliches. Verwenden Sie camelCase-Namen und einen von vier Typen: string, number, boolean oder date. Properties sind nicht für Langtext gedacht; es sind Metadaten, die die Entität auf vergleichbare und sortierbare Weise beschreiben.
Dieselben Schlüssel werden in Chat- und Suchaufrufen zu Filterfeldern. coreAI unterstützt diese Operatoren:
$eq— exakte Gleichheit, etwamarket = "no"$gt,$gte,$lt,$lte— Vergleiche auf Zahlen und Datumsangaben, etwapublishedAt >= "2026-01-01"$in— der Wert ist einer aus einer gegebenen Liste, etwacategoryName in ["jacken", "hosen"]
Filter werden im filters-Feld eines Chat- oder Suchaufrufs mitgegeben, und coreAI nutzt sie, um die Kandidaten für die Antwort einzugrenzen. Das heißt: Sie können die Wissensdatenbank breit befüllen — alle Märkte, alle Kategorien, alle Veröffentlichungsstufen — und trotzdem einen bestimmten Aufruf bitten, nur aus einer Auswahl zu antworten.
#Wann ein gefilterter Assistent die richtige Antwort ist
Ein typisches Beispiel: Ein Unternehmen betreibt Onlineshops in mehreren Ländern mit gemeinsamem Produktkatalog, aber jeder Shop soll nur seine eigenen Produkte und Preise zeigen. Statt einen Assistenten pro Markt zu bauen, schicken Sie alle Produkte mit einer market-Property ("no", "se", "dk") ein und lassen das Widget jedes Shops { "market": { "$eq": "no" } } im Chat-Aufruf mitgeben. Dasselbe Muster funktioniert, um veröffentlichte von internen Dokumenten zu trennen, oder um eine Suche nur auf noch nicht stattgefundene Veranstaltungen zu beschränken (startDate mit $gte auf das heutige Datum).
Die robuste Integration: Entitäten von Anfang an richtig typisieren, ein kleines, durchdachtes Set von Properties pflegen, und Filter einsetzen statt Assistenten zu duplizieren, wenn eine logische Wissensdatenbank mehrere Kontexte bedienen soll.