Tablestore:Common objects

Scope

Le champ Scope définit la hiérarchie de propriété des données de mémoire et comprend quatre champs.

Les règles régissant les champs Scope obligatoires et la prise en charge du caractère générique * varient selon l'API.

Si un niveau utilise *, les niveaux suivants doivent également utiliser * ou être omis. Par exemple, app-001/user-001/*/* est valide, tandis que app-001/*/assistant/* est invalide.

{
  "appId": "app-001",
  "tenantId": "user-001",
  "agentId": "assistant",
  "runId": "session-001"
}

Agent Scope

Wiki utilise un Agent Scope à trois segments contenant uniquement appId, tenantId et agentId. Ces trois champs sont obligatoires, leur longueur maximale est de 128 octets chacun, et ils ne peuvent pas contenir / ni utiliser *. Les requêtes Wiki ne peuvent pas inclure runId.

Chaque Agent Scope possède un seul Wiki dans un magasin de mémoire, et les sessions avec différentes valeurs de runId partagent ce Wiki.

Scope Filter

SearchMemories, ListMemories et ListMemoryStoreScopes permettent d'utiliser filter pour filtrer le Scope de manière structurée. Si scope et filter sont tous deux fournis, ils s'appliquent conjointement (relation ET). filter correspond uniquement au Scope, et non au corps du texte de la mémoire ni aux Metadata.

Les champs filtrables incluent scopeType, scopeKey, appId, tenantId, agentId, runId, wikiId et le champ virtuel text. Le Scope de conversation utilise agentId et runId, tandis que le Scope Wiki utilise wikiId. Les champs standards n'acceptent que la correspondance exacte ; les opérateurs prefix, wildcard et range ne sont pas pris en charge.

text effectue une correspondance sur des segments courts des valeurs de champ du Scope et n'accepte que op: "eq". Sa value peut utiliser * pour correspondre à une séquence de caractères de n'importe quelle longueur, et ? pour correspondre à un seul caractère Unicode, par exemple *abc*. Le motif ne peut pas être vide et peut comporter jusqu'à 32 caractères Unicode ; le nombre total de caractères autres que * ne peut pas dépasser 4.

{
  "op": "and",
  "conditions": [
    { "op": "eq", "field": "appId", "value": "app-001" },
    { "op": "eq", "field": "text", "value": "*abc*" }
  ]
}

filter peut être imbriqué jusqu'à 8 niveaux et contenir jusqu'à 64 conditions feuilles. Les requêtes paginées doivent conserver scope et filter inchangés ; le même nextToken ne peut pas servir à d'autres conditions de requête.

filter dépend des capacités de requête Scope du magasin de mémoire cible. Certains magasins de mémoire existants ne prennent pas en charge filter ni le champ virtuel text. En cas de renvoi de INVALID_PARAMETER, utilisez un Scope exact ou avec caractère générique. En cas de renvoi de SERVICE_UNAVAILABLE, réessayez d'abord avec un backoff ; si la condition text reste indisponible, utilisez plutôt les conditions eq, in ou exists sur les champs standards.

Message

Le champ messages de l'API AddMemories utilise la structure suivante.

Metadata

Les Metadata se composent de paires clé-valeur de type chaîne utilisées pour associer des tags métier. Dans SearchMemories, les Metadata servent à la correspondance exacte de chaîne complète et au filtrage ; lorsque plusieurs paires clé-valeur sont fournies, les résultats doivent satisfaire simultanément toutes les conditions. Des caractères tels que *, ?, la virgule et le signe égal sont traités comme des caractères ordinaires et ne représentent pas des caractères génériques.

Les metadata de premier niveau de AddMemories, ainsi que les Metadata au niveau du message obtenues en fusionnant les metadata de premier niveau avec les metadata de chaque message, doivent chacune respecter les limites précédentes. Une valeur écrite unique n'a pas de limite distincte de 1024 caractères ; cependant, chaque valeur de requête dans SearchMemories.metadata peut comporter jusqu'à 1024 caractères Unicode. Les valeurs stockées dépassant cette longueur peuvent être lues, mais ne peuvent pas servir de conditions de requête Metadata.

{
  "source": "chat",
  "topic": "preference"
}

Les magasins de mémoire dont outputTypes inclut structured prennent en charge la correspondance exacte complète décrite ci-dessus, ce qui convient à la récupération de valeurs longues telles que les UUID et les ID de trace.