Retrieval Tools
Tools zum Speichern, Abfragen und Löschen von Retrieval-Einträgen geben Agenten ein dauerhaftes Gedächtnis.
Auf dieser Seite
Retrieval Tools vs. Database Tools
Connic bietet zwei Speichersysteme für Agenten. Sie erfüllen unterschiedliche Zwecke und werden häufig gemeinsam eingesetzt.
Speichert Text und findet ihn anhand seiner Bedeutung. Eine Suche nach „Stornierungsregeln“ kann ein Dokument mit dem Titel „Rückgabe- und Erstattungsrichtlinie“ finden.
Sortiert unstrukturierte Texte wie Dokumentation, FAQs und Notizen nach Relevanz.
Speichert strukturierte Daten und findet sie anhand exakter Feldwerte. Frage beliebige Felder in beliebigen Collections mit Operatoren wie $gt, $in oder $and ab.
Unterstützt exakte Abfragen, Feldfilter, Zählungen sowie das Erstellen, Aktualisieren und Löschen von Datensätzen.
Retrieval-Tools lassen Agenten Informationen speichern und abrufen, die über Runs hinweg erhalten bleiben. Speichere Dokumente, FAQs oder beliebige Texte und frage sie anschließend in natürlicher Sprache ab. Queries sortieren relevante Inhalte nach Bedeutung statt nach exakten Schlüsselwörtern.
Inhalte werden asynchron gespeichert. retrieval_store gibt einen Job in der Warteschlange zurück; nach dessen Abschluss ist der Inhalt durchsuchbar. Queries und Löschvorgänge mit Metadatenfilter berücksichtigen nur indexierte Einträge.
Namespaces organisieren Inhalte hierarchisch über durch Punkte getrennte Namen (z. B. „policies.hr.leave“, „products.pricing“). Eine Query auf einen übergeordneten Namespace durchsucht auch alle untergeordneten Namespaces. Entry-IDs sind innerhalb eines Namespaces eindeutig. Die maximale Tiefe beträgt 10 Ebenen.
Auf der Seite Retrieval im Projekt-Dashboard lassen sich alle indexierten Inhalte anzeigen, durchsuchen und verwalten.
Wrapper für Custom Tools
Wrapper-Funktionen können Namen wie remember und recall bereitstellen und dabei Namespaces oder Zugriffsregeln fest vorgeben. Alternativ lassen sich die vordefinierten Retrieval-Tools direkt in YAML aufführen.
from connic.tools import retrieval_store, retrieval_query, retrieval_delete
async def remember(content: str, topic: str) -> dict:
"""Store information under a topic."""
return await retrieval_store(content=content, namespace=topic)
async def recall(question: str, topic: str | None = None) -> list:
"""Search indexed content for relevant information."""
result = await retrieval_query(question, namespace=topic)
return result["results"]
async def forget(entry_id: str, topic: str) -> dict:
"""Remove an entry from a topic."""
return await retrieval_delete(entry_id=entry_id, namespace=topic)Verwende die eigenen Tools im Agent-YAML:
version: "1.0"
name: my-agent
model: connic/gpt-5.6-terra
description: "Stores and retrieves project knowledge"
system_prompt: |
Use memory tools to store, recall, and remove project knowledge.
tools:
- memory.remember
- memory.recall
- memory.forgetParameter
| Parameter | Typ | Standard | Beschreibung |
|---|---|---|---|
| query | string | erforderlich | Text für den semantischen Abgleich |
| namespace | string? | null | Zu durchsuchender Namespace einschließlich untergeordneter Namespaces. Weglassen, um alle Namespaces zu durchsuchen |
| min_score | float | 0.3 | Minimaler Relevanzwert (0,0 bis 1,0) |
| max_results | int | 3 | Gewünschte Anzahl der Ergebnisse, begrenzt auf 1–20 |
| metadata_filter | dict? | null | MongoDB-artiger Filter für die Metadaten eines Eintrags. Verwendet dieselben Operatoren wie db_find ($eq, $ne, $in, $gt, $exists, $or, …). Verschachtelte Schlüssel verwenden Punktnotation. Jede $in- oder $nin-Liste akzeptiert höchstens 1.000 Werte |
Rückgabewert
Gibt passende Ergebnisse mit folgenden Feldern zurück: content, entry_id, score (Relevanz 0–1), namespace, metadata
retrieval_query hält sich an das verbleibende Zeitlimit des Runs. Ist das Zeitlimit bereits erreicht oder verstreicht es vor der Antwort, gibt das Tool statt Treffern ein error-Feld und eine leere results-Liste zurück.
Beispiele
# Simple query
result = await retrieval_query("What is the refund policy?")
# Results contain matching content with similarity scores
for item in result["results"]:
print(f"[{item['score']:.0%}] {item['content'][:100]}...")# Filter by namespace
result = await retrieval_query(
query="How do I reset my password?",
namespace="support"
)
# Nach Metadaten filtern: dieselben Operatoren im MongoDB-Stil wie bei den Datenbank-Tools
# (\$eq, \$ne, \$gt, \$gte, \$lt, \$lte, \$in, \$nin, \$exists,
# \$regex, \$contains, \$elemMatch, \$and, \$or, \$nor, \$not).
# Werte ohne Operator stehen als Kurzform für Gleichheit.
result = await retrieval_query(
query="product availability",
namespace="products",
metadata_filter={
"product_id": "X",
"status": {"$in": ["active", "pending"]},
},
)
# Adjust score threshold and result count
result = await retrieval_query(
query="pricing information",
min_score=0.2, # Lower threshold = more results
max_results=10 # Return up to 10 results
)Parameter
| Parameter | Typ | Standard | Beschreibung |
|---|---|---|---|
| content | string | erforderlich | Zu speichernder Textinhalt, der zur asynchronen Indexierung in die Warteschlange gestellt wird |
| entry_id | string? | auto | Eigene ID für den Eintrag (wird sie weggelassen, wird eine UUID erzeugt) |
| namespace | string? | null | Kategorie zur Organisation von Inhalten |
| metadata | dict? | null | Zusätzlich zu speichernde Schlüssel-Wert-Daten |
Rückgabewert
Gibt entry_id, job_id, status, queued und success zurück. Die Speicherung erfolgt asynchron; der Eintrag ist nach Abschluss des Indexierungsjobs durchsuchbar.
Beispiele
# Simple store (auto-generated ID)
result = await retrieval_store(
content="The company refund policy allows returns within 30 days."
)
# Returns immediately with a queued job
# {"entry_id": "abc123...", "job_id": "...", "status": "pending", "queued": true, "success": true}# Store with custom ID for later updates
result = await retrieval_store(
content="Q1 sales target is $1M with focus on enterprise.",
entry_id="q1-sales-target",
namespace="planning",
metadata={"quarter": "Q1", "year": "2024"}
)
# Store user preferences
result = await retrieval_store(
content="User prefers dark mode and metric units.",
entry_id="user-preferences",
namespace="user_data"
)Parameter
| Parameter | Typ | Standard | Beschreibung |
|---|---|---|---|
| entry_id | string? | null | ID eines einzelnen zu löschenden Eintrags. Bei einer Sammellöschung nach Namespace weglassen |
| namespace | string? | null | Namespace zur Eingrenzung des Löschvorgangs. Für Löschvorgänge mit Metadatenfilter erforderlich; untergeordnete Namespaces werden einbezogen |
| metadata_filter | dict? | null | MongoDB-artiger Filter für die Metadaten eines Eintrags. Verwendet dieselben Operatoren wie db_find ($eq, $ne, $in, $or, …). Erfordert namespace. Jede $in- oder $nin-Liste akzeptiert höchstens 1.000 Werte |
Rückgabewert
Gibt ok (Erfolg) und deleted_chunks (Anzahl der entfernten indexierten Chunks) zurück. Gib entweder entry_id oder einen namespace an (optional mit metadata_filter). Entry-IDs sind pro Namespace eindeutig. Gib daher den Namespace an, wenn dieselbe ID in mehreren Namespaces vorkommt.
Beispiele
# Delete a single entry by id
result = await retrieval_delete(entry_id="old-product-info")
# Delete a single entry scoped to a namespace
result = await retrieval_delete(
entry_id="q1-sales-target",
namespace="planning",
)
# Mehrere Einträge nach Metadaten löschen: dieselbe Filtersyntax im MongoDB-Stil verwenden
# wie bei den Datenbank-Tools; Operatoren wie \$ne, \$in und \$not werden unterstützt
result = await retrieval_delete(
namespace="products",
metadata_filter={"product_id": "X"},
)
# Orphan cleanup pattern: re-ingest a source, then delete every entry
# in scope from previous runs (everything that isn't the current run_id).
# Run the delete only after the re-ingest jobs have completed: entries
# still being indexed keep their previous run_id and would be deleted.
result = await retrieval_delete(
namespace="confluence",
metadata_filter={
"root_page_id": page_id,
"run_id": {"$ne": current_run_id},
},
)
# Wipe an entire namespace subtree (sub-namespaces included)
result = await retrieval_delete(namespace="meetings")Parameter
| Parameter | Typ | Standard | Beschreibung |
|---|---|---|---|
| parent | string? | null | Übergeordneter Namespace, dessen direkte Unterelemente aufgelistet werden. Wird er weggelassen, werden Namespaces der obersten Ebene aufgeführt |
| depth | int | 1 | Anzahl aufzulistender Ebenen (1 = direkte Unterelemente, 0 = alle untergeordneten Namespaces, maximal 10) |
Rückgabewert
Ohne parent: Gibt eine Liste von Namespace-Objekten mit name, entry_count, total_entry_count und has_children zurück.
Mit parent: Gibt parent (Informationen zum übergeordneten Namespace) und namespaces (Liste der Unterelemente) zurück.
Beispiele
# List top-level namespaces
result = await retrieval_list_namespaces()
# Returns: [{"name": "policies", "entry_count": 5, "total_entry_count": 12, "has_children": true}, ...]
# Drill into a specific namespace
result = await retrieval_list_namespaces(parent="policies")
# Returns: {"parent": {...}, "namespaces": [{"name": "policies.hr", ...}, ...]}
# List all namespaces at all depths
result = await retrieval_list_namespaces(depth=0)Vollständiges Agent-Beispiel
version: "1.0"
name: retrieval-agent
model: connic/gpt-5.6-terra
description: "Agent with persistent memory"
system_prompt: |
You are an assistant with access to a retrieval.
Always search the retrieval first before answering.
tools:
- retrieval_query
- retrieval_store
- retrieval_delete
- retrieval_list_namespaces