Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Mémoire sémantique à long terme pour les agents LangGraph

LangGraph sépare deux types d'état d'agent. Short-term state est le fil de conversation lui-même, qu'un pointeur de contrôle persiste pour qu'un fil de discussion puisse reprendre, rejouer et récupérer (voirUtilisation de DynamoDB comme magasin de points de contrôle pour les agents LangGraph). Long-term la mémoire est ce que l'agent connaît à travers les threads et la LangGraph modélise comme un magasin : une surface clé-valeur avec espace de noms sur laquelle l'agent écrit délibérément et relit plus tard.

La DynamoDBStore classe, dans le package langgraph-checkpoint-aws, est l'implémentation DynamoDB de ce magasin. Il gère le côté clé-valeur avec des espaces de noms hiérarchiques, Time to Live pour les mémoires périmées qui expirent et un filtrage de base. Avec un index vectoriel configuré (voirUtilisation d'index vectoriels dans DynamoDB), sa search() méthode effectue une recherche sémantique : les mémoires sont intégrées à l'écriture, indexées de manière asynchrone et rappelées par signification, classées par similarité, à partir de la même table qui les contient. Il n'existe pas de base de données vectorielles distincte à approvisionner et aucun pipeline n'y copiant les données.

Conditions préalables

Installez les bibliothèques à l'aide de pip :

pip install langgraph langgraph-checkpoint-aws langchain-aws

Configurer la boutique

Configurez le magasin avec un index bloc et appelez setup() :

from langchain_aws import BedrockEmbeddings
from langgraph_checkpoint_aws import DynamoDBStore

store = DynamoDBStore(
    table_name="support-agent-memory",
    region_name="us-east-1",
    index={
        "embed": BedrockEmbeddings(model_id="amazon.titan-embed-text-v2:0"),
        "dims": 1024,
        "fields": ["text"],
        "distance_function": "COSINE",
    },
)

store.setup()

Quatre paramètres du index bloc méritent d'être compris :

setup()crée la table si elle est absente, joint l'index vectoriel et active Time to Live si vous l'avez configuré. À un tableau existant, il ajoute uniquement ce qui manque, afin que les DynamoDBStore déploiements existants puissent adopter la recherche sémantique sans recréer le tableau ni migrer des éléments. Gardez à l'esprit qu'il setup() ne revient pas tant que l'index n'est pas renvoyé ACTIVE et qu'il n'est plus remplacé : un index qui génère des rapports ACTIVE tout en continuant à remplir rejette SearchVectors les appels. Sur une nouvelle table vide, l'attente est courte. Le réaménagement d'une table avec des objets existants prend autant de temps que le remblayage.

Écrivez des souvenirs

L'écriture est une chose ordinaireput(). L'intégration se fait pour vous :

namespace = ("memories", "acme-corp", "user-8812")

store.put(namespace, "mem-1", {
    "text": "Account runs a proxy that closes idle sockets after 60 seconds",
    "source": "ticket-4471",
})
store.put(namespace, "mem-2", {
    "text": "Customer prefers email, asked not to be called by phone",
    "source": "ticket-4471",
})
store.put(namespace, "mem-3", {
    "text": "Uses a custom build of the SDK pinned to version 2.14",
    "source": "ticket-4502",
})

Rappeler par le sens

Le client ouvre une nouvelle conversation et indique que sa connexion ne cesse de s'arrêter au bout d'une minute environ :

results = store.search(
    namespace,
    query="connection drops after a minute of inactivity",
    limit=3,
)

for item in results:
    print(round(item.score, 3), item.value["text"])

Sortie :

0.324 Account runs a proxy that closes idle sockets after 60 seconds
0.039 Customer prefers email, asked not to be called by phone
0.031 Uses a custom build of the SDK pinned to version 2.14

La mémoire concernée occupe la première place et aucune clé de la requête ne correspond à quoi que ce soit. SearchItem.scoresuit la LangGraph convention selon laquelle le niveau le plus élevé est le plus pertinent. DynamoDB renvoie une distance, où la valeur la plus faible est la plus proche, de sorte que le magasin convertit : COSINE car le score est1 - distance, car EUCLIDEAN il est1 / (1 + distance), et les DOT_PRODUCT scores sont transmis inchangés. Si vous vous basez sur un score absolu pour décider si une mémoire est suffisamment pertinente pour être injectée dans une invite, calibrez ce seuil par rapport à vos propres données et à la fonction de distance que vous avez choisie.

Étendue de la mémoire avec le schéma de recherche

Lors de DynamoDBStore la création de l'index vectoriel, il déclare la clé de partition de la table en tant qu'HASHélément du schéma de recherche d'index. Comme cet élément existe, chaque recherche doit fournir une condition, et le magasin fournit l'espace de noms : le tuple d'espace de noms est joint pour former la valeur de la clé de partition, de sorte que chaque recherche sémantique est épinglée à exactement un espace de noms. Trois conséquences s'ensuivent :

Le tableau suivant explique comment choisir une forme d'espace de noms.

Évitez de placer chaque mémoire dans un seul espace de noms et de filtrer en fonction des métadonnées : les filtres sont appliqués une fois que DynamoDB a déjà sélectionné les correspondances les plus proches dans l'ensemble de l'espace de noms, et une seule recherche renvoie au maximum les 100 meilleures réponses. Ainsi, lorsqu'un locataire occupé remplit le top 100 pour une requête courante, la recherche d'un locataire plus silencieux renvoie moins de résultats que ceux demandés, même si ses mémoires sont présentes. Préférez la portée de l'espace de noms aux filtres pour tout ce qui détermine l'exactitude. Aller au-delà de votre limite de rappel est également une conception légitime : un agent qui a besoin d'un contexte à la fois spécifique à l'utilisateur et à l'échelle du compte recherche les deux espaces de noms et fusionne les résultats.

Considérations

Ressources supplémentaires