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.

Starte kostenlosDer passende Storage-Typ
Retrieval-Dokumentation lesen

Retrieval

24 entries · 3 namespaces
Search…
SourceEntry 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]:
    """Find approved policy passages for a support question."""
    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
SourceNamespace
  • 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-sol
system_prompt: |
  You are a helpful support agent.
  Use the conversation history for context.

# Persist conversation history per chat
session:
  key: context.chat_id
  ttl: 86400  # expire after 24h of inactivity

Mit session: true teilen alle Runs des Agenten eine Session. Der optionale key trennt Sessions über context. (gesetzt in der Before Middleware) oder input. (aus der ursprünglichen Payload). history und browser sind standardmäßig true. Optional ist ttl in Sekunden möglich (mindestens 60); ohne ttl laufen Sessions nicht ab. Dokumentation ansehen

user
I want a refund for order ORD-184.
user: refund for ORD-184
assistant: Looked it up, refund issued.

Conversation history kept across runs. TTL configurable.

user
When will it arrive?
# Agent already knows the order context.

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
# No setup needed - the collection "invoices" is created
# automatically the first time db_insert runs.
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"] -> auto-generated UUID
tools/list_invoices.py
# Query with filter operators - no SQL, no migrations
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.

Entdecke weitere Features

Composer SDK

Agenten in YAML definieren.

Tools

Vordefiniert, eigenes Python oder MCP.

Retrieval

Quellen synchronisieren und mit begrenzten Tools durchsuchen.

Verbindungen

Agenten mit den realen Systemen verbinden.

Bridges

Private Services ohne eingehende Ports erreichen.

Observability

Jeden Schritt und jedes Token nachvollziehen.

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 session: true teilen alle Runs des Agenten eine Session. Ein optionaler session.key mit context.* oder input.* trennt Sessions nach dem aufgelösten Wert. History und Browserzustand werden standardmäßig gespeichert und lassen sich unabhängig deaktivieren. False, null oder das Weglassen von session deaktiviert die dauerhafte Speicherung. Mit ttl laufen inaktive Sessions ab; verwalte sie unter Storage > Sessions.

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.