Zum Hauptinhalt springen
Connic

Speichere Daten für KI-Agenten
ohne eigene Infrastruktur

Nutze Retrieval, Sessions und Datenbank direkt in Connic. So können deine Agenten Dokumente durchsuchen, Gesprächsverläufe fortsetzen und strukturierte Daten verwalten. Die Daten bleiben nach Umgebung getrennt.

Retrieval-Dokumentation lesen

Retrieval

24 Einträge · 3 Namespaces
Suchen…
QuelleEntry IDNamespace
  • invoice-template.pdf
    inv_a1b2c3
    policies.finance
  • tax-rules-2026.md
    tax_d4e5f6
    policies.finance
  • refund-faq.txt
    faq_g7h8i9
    support.faq
  • product-catalog.png
    cat_j0k1l2
    products
  • shipping-policy.md
    shp_m3n4o5
    support.shipping
  • vendor-contract.pdf
    vnd_p6q7r8
    policies.legal

Ergänze Antworten mit Wissen aus Dokumenten

Stelle deinen KI-Agenten Texte, PDFs und Bilder für die Suche bereit. Connic übernimmt die Aufbereitung. Im Code legst du fest, welche Inhalte das Suchtool durchsuchen kann; es liefert passende Textstellen samt Quellenangaben.

tools/support_policy.py
from connic.tools import retrieval_query

async def search_support_policy(question: str) -> list[dict]:
    """Freigegebene Richtlinienpassagen für eine Supportfrage finden."""
    result = await retrieval_query(
        query=question,
        namespace="support.approved",
        min_score=0.35,
        max_results=5,
    )

    matches = []
    for item in result["results"]:
        citation = {"entry_id": item["entry_id"]}
        if item.get("page_number") is not None:
            citation["page_number"] = item["page_number"]
        matches.append({
            "passage": item["content"],
            "citation": citation,
        })
    return matches
QuelleNamespace
  • refund-faq.txt· 27 Chunks
    support.faq
  • shipping-policy.md· 12 Chunks
    support.faq
  • tax-rules-2026.md· 42 Chunks
    policies.finance
  • vendor-contract.pdf· 31 Chunks
    policies.legal
  • product-shot.png· 8 Chunks
    products
Viele Formate

Text, Markdown, CSV, JSON, YAML, Logs, PDF und Bilder.

Asynchrone Ingestion

Dateien werden im Hintergrund verarbeitet: Connic teilt sie in Abschnitte auf und erstellt Embeddings. Jeder Auftrag ist im Dashboard sichtbar.

Bewertete Ergebnisse

Liefert Inhalt, Eintrags-ID, Namespace und einen Relevanzwert. Retrieval-Dokumentation lesen

Gib KI-Agenten Zugriff auf den Gesprächskontext

Lass Connic frühere Gesprächsbeiträge speichern und bei weiteren Anfragen wieder bereitstellen, auch nach einem Neustart. Mit einem Sitzungsschlüssel aus der Middleware oder den Eingabedaten legst du fest, welche Anfragen zusammengehören.

agents/support-bot.yaml
name: support-bot
type: llm
model: connic/gpt-5.6-terra
system_prompt: |
  Du bist ein hilfreicher Support Agent.
  Nutze den Gesprächsverlauf als Kontext.

# Gesprächsverlauf je Chat speichern
session:
  key: context.chat_id
  ttl: 86400  # nach 24 Stunden Inaktivität ablaufen lassen

key ist ein durch Punkte getrennter Pfad, der mit context. (gesetzt in der Before Middleware) oder input. (aus dem Roh-Payload gelesen) beginnen muss. Optional kann ttl in Sekunden angegeben werden (mindestens 60). Ohne ttl laufen Sessions nicht ab. Ohne Session Block beginnt jeder Request neu. Dokumentation ansehen

Nutzer
Ich möchte eine Erstattung für die Bestellung ORD-184.
Nutzer: Erstattung für ORD-184
Assistent: Nachgeschlagen, Erstattung veranlasst.

Der Gesprächsverlauf bleibt über Runs hinweg erhalten. TTL ist konfigurierbar.

Nutzer
Wann wird sie gutgeschrieben?
# Der Agent kennt den Bestellkontext bereits.

Nutze eine Datenbank für KI-Agenten. Bereits eingerichtet.

Nutze in jeder Connic-Umgebung eine eigene Datenbank. Lass deine Agenten Daten speichern und mit Filtern abfragen. Collections entstehen automatisch beim ersten Schreibzugriff; ein festes Schema musst du nicht vorgeben.

tools/save_invoice.py
# Kein Setup erforderlich - die Collection "invoices" wird
# beim ersten Aufruf von db_insert automatisch erstellt.
result = await db_insert("invoices", {
    "vendor":       "Acme Corp",
    "total":        4920,
    "currency":     "EUR",
    "processed_at": "2026-04-12T10:30:00Z",
    "raw_event":    {"id": "evt_123", "type": "invoice.paid"},
})
# result["inserted"][0]["_id"] -> automatisch erzeugte UUID
tools/list_invoices.py
# Abfrage mit Filteroperatoren – kein SQL, keine Migrationen
result = await db_find(
    "invoices",
    filter={
        "vendor": "Acme Corp",
        "processed_at": {"$gt": "2026-04-01"},
    },
    sort={"processed_at": -1},
    limit=20,
)
documents = result["documents"]
Automatisch angelegte Collections

Ein Schema muss nicht eingerichtet werden. Der erste Aufruf von db_insert legt die Collection an. Jedes Dokument erhält _id, _created_at und _updated_at automatisch.

Ausdrucksstarke Filter

$eq, $ne, $gt/$gte/$lt/$lte, $in/$nin, $and/$or/$not, $exists, $contains, $elemMatch, $regex. Ergebnisse lassen sich sortieren und seitenweise abrufen. Außerdem können einzelne Felder ausgewählt und eindeutige Werte aufgelistet werden.

Sieben vordefinierte Tools

db_find, db_insert, db_update, db_upsert, db_delete, db_count, db_list_collections. Daten und abgeleitete Schemas stehen im Dashboard unter Storage → Database. Dokumentation ansehen

Trenne Daten. Begrenze den Zugriff. Sieh Inhalte ein.

Halte Daten nach Umgebung getrennt und lege mit API-Schlüsseln gezielte Berechtigungen fest. Im Dashboard behältst du die Übersicht.

Isolation je Environment

Retrieval-Einträge, persistente Sessions und Datenbank-Collections sind jeweils auf ein Environment begrenzt. Produktivumgebung und Staging desselben Projekts halten ihre Daten standardmäßig getrennt.

Begrenzte API Keys

REST API Keys lassen sich mit granularen Berechtigungen ausstatten, darunter Lese- und Schreibzugriff auf Retrieval. Diese Keys unterstützen automatisierte Ingestion Pipelines und die Synchronisierung von Inhalten aus externen Systemen.

Verwaltung im Dashboard

Alle drei Speicherfunktionen sind an einem Ort sichtbar: Retrieval zeigt Ingestion Jobs und Namespaces, unter Storage > Sessions lassen sich aktive Sessions auflisten und löschen, unter Storage > Database Collections, Dokumente und abgeleitete Schemas durchsuchen.

Häufig gestellte Fragen

Klartext und Markdown (.txt, .md, .markdown), CSV, JSON / JSONL, YAML, Logdateien, PDFs und Bilder (.png, .jpg, .jpeg, .gif, .webp). Connic teilt Textformate in Abschnitte auf und erstellt Embeddings. Bei PDFs bleiben die Seitenzahlen erhalten. Bei Bildern werden die Inhalte mit einem bildverarbeitenden KI-Modell ausgelesen, bevor Embeddings entstehen.

Uploads werden sofort angenommen und asynchron als Ingestion Jobs indexiert, deren Status im Dashboard sichtbar ist. Für Agenten im Produktivbetrieb kapselt ein zweckgebundenes Custom Tool retrieval_query, legt Namespace und Suchparameter fest und gibt nur die benötigten Passagen und Quellenangaben zurück. Das Agent YAML kann schreibgeschützten Zugriff auf die erlaubten Namespaces erzwingen.

Namespaces sind durch Punkte getrennte Pfade wie policies.hr.leave und können bis zu 10 Ebenen tief sein. Eine Abfrage auf einem übergeordneten Namespace durchsucht auch alle untergeordneten Namespaces. Entry IDs sind innerhalb eines Namespaces eindeutig; mit dem Tool retrieval_list_namespaces können Agenten die Hierarchie zur Laufzeit ermitteln.

Mit Sessions behält ein LLM-Agent seinen Gesprächsverlauf über mehrere Requests hinweg. Das Agent YAML aktiviert sie mit session.key, der aus Middleware context.* oder input.* aufgelöst wird, und optional mit ttl in Sekunden (mindestens 60). Ohne Session Block beginnt jeder Request neu. Aktive Sessions werden im Dashboard unter Storage > Sessions verwaltet.

Die Datenbank speichert strukturierte Dokumente in benannten Collections und fragt Feldwerte mit Filteroperatoren wie $eq, $gt, $in oder $and ab. Retrieval indexiert unstrukturierte Inhalte und findet passende Textstellen nach Bedeutung. Die Datenbank eignet sich für Bestellungen, Nutzer und Ereignisse; Retrieval für FAQs, Dokumentation und Notizen.

Nein. Dokumente sind frei strukturiert, und Collections werden beim ersten Aufruf von db_insert automatisch angelegt. Jedes Dokument erhält neben eigenen Feldern automatisch die Systemfelder _id (eine UUID), _created_at und _updated_at.

Retrieval, Sessions und Datenbank sind jeweils auf ein Environment begrenzt. Produktivumgebung und Staging desselben Projekts verwenden getrennte Daten.