Memories

Memories / Documentation

Sur cette page

Recherche, plongements et génération augmentée par récupération

Memories prend en charge la recherche par mots-clés et la recherche sémantique sur les souvenirs ordinaires et les fiches de connaissances autorisés. L'ingestion de documents accepte le texte UTF-8 et Markdown et crée une fiche de connaissances chiffrée normale. L'extraction de fichiers PDF/DOCX/binaires n'est pas automatique ; convertissez-les en texte avant une ingestion explicite. Le contenu privé, les identifiants et les ressources fichiers sont exclus de la recherche.

Démarrage rapide

Utilisez le même répertoire personnel et la même configuration pour la CLI et le démon en cours d'exécution. Redémarrez le démon après une mise à niveau ou une modification de la configuration du modèle. Initialisez/déverrouillez comme d'habitude, puis :

memories rag ingest VAULT_ID notes.md --title "Research notes"
memories memory search VAULT_ID "Chinese English keywords"
memories rag search VAULT_ID "keywords" --mode bm25 --match-mode all
memories rag model-install
memories rag index VAULT_ID
memories rag search VAULT_ID "Find similar meaning" --mode vector
memories rag search VAULT_ID "Find evidence" --mode hybrid --limit 8
memories rag status VAULT_ID
memories rag ask VAULT_ID "What does the evidence say?"

rag ask nécessite une URL de génération dans la configuration du démon. Pour utiliser le RAG lexical sans modèle de plongement, ajoutez --mode bm25 ; l'URL de génération reste nécessaire. memory_search reste lexical. La recherche avancée renvoie des fragments de documents avec les identifiants de ressource/révision, empreintes stables des fragments, positions en octets UTF-8 d'origine, scores et libellés de citation. [S1] identifie une source au sein d'un résultat ; utilisez ses champs id et revision pour une lecture ordinaire memory read, et non l'empreinte du fragment.

BM25 chinois et fragments

Le texte chinois et multilingue est segmenté avec Jieba. Les titres, corps et métadonnées sûres participent au classement FTS5 BM25, avec les pondérations 5/1/2. any (par défaut) combine les mots-clés ; all exige chaque terme de la requête ; phrase exige l'expression originale. Les contraintes strictes all/phrase filtrent également les candidats vectoriels/hybrides. Les requêtes sont échappées et ne sont pas interprétées comme des opérateurs FTS arbitraires.

Le texte est découpé près des limites de phrases/paragraphes en fragments de 768 caractères Unicode maximum, avec normalement un chevauchement de 128 caractères. Les positions renvoyées désignent le corps UTF-8 d'origine. La recherche est limitée à 100 résultats demandés, 64 termes lexicaux et 1,024 octets de requête. La recherche simple memory search regroupe les fragments par document ; la recherche RAG avancée renvoie les fragments individuellement. --cards-only restreint la recherche.

Les index sont réutilisés entre les requêtes. Une modification du coffre, une synchronisation ou un changement de politique invalide son index en cache ; le verrouillage/redémarrage efface tous les index et vecteurs. Ils ne sont ni conservés en clair ni ajoutés aux charges utiles de synchronisation chiffrées. Les limites par coffre en cache sont de 10,000 fragments, 16 MiB de texte source/métadonnées et 32 MiB de vecteurs ; au maximum deux coffres sont mis en cache. Les grandes bibliothèques restent soumises aux limites sous-jacentes de persistance de l'état complet décrites dans les performances.

EmbeddingGemma dans le processus

Le moteur de plongement par défaut est EmbeddingGemma 300M Q4 de Google, via l'inférence ONNX native. Il s'exécute dans le démon Memories, sans nécessiter Ollama, Python ou un service d'inférence distinct. L'application inclut le moteur d'inférence, avec la télémétrie ONNX explicitement désactivée avant la création des sessions ; les fichiers du modèle/tokeniseur (environ 209 MiB) sont installés une fois par l'application :

memories rag model-install

L'installateur télécharge une révision épinglée de onnx-community/embeddinggemma-300m-ONNX, vérifie SHA-256, prend en charge les téléchargements par plages et les nouvelles tentatives, et ne remplace jamais un fichier existant non conforme. Les fichiers existants vérifiés sont réutilisés. Le répertoire par défaut est models/embeddinggemma sous le répertoire personnel Memories sélectionné. Fournissez un répertoire existant avec rag.local_model_dir ; il doit contenir le graphe ONNX Q4, ses données externes et les fichiers du tokeniseur/de configuration. Redémarrez le démon après modification des fichiers du modèle. Les poids sont régis séparément par les conditions d'utilisation de Gemma et sa politique d'utilisations interdites ; l'installateur écrit une notice et la fiche du modèle en amont.

[rag]
local_model_dir = "./models/embeddinggemma"
local_threads = 4
max_tokens = 2048
# Optional mirror of the exact pinned files:
# model_download_base_url = "https://your-mirror.example/embeddinggemma"

Les chemins relatifs du modèle sont résolus à côté du fichier de configuration. Réduire local_threads limite l'utilisation CPU ; max_tokens borne l'entrée du tokeniseur et peut tronquer les entrées longues si sa valeur est inférieure au nombre de jetons du fragment. Les plongements sont des vecteurs normalisés à 768 dimensions. Le modèle utilise des préfixes de tâche distincts pour les requêtes/documents. rag index prépare l'index ; la recherche vectorielle/hybride calcule aussi les plongements manquants à la demande. Un budget d'opération de cinq minutes est vérifié entre les étapes ; les lots terminés peuvent être réutilisés lors d'une nouvelle tentative tant que le coffre/modèle restent inchangés et déverrouillés.

URL de modèles fournies par le client

Gemini Embedding est une API en ligne, et non le modèle hors ligne EmbeddingGemma. Ajoutez rag.embedding pour sélectionner un fournisseur distant ; omettez-le pour conserver les plongements en local. Utilisez les URL complètes des opérations et configurez le modèle attendu par votre service :

[rag.embedding]
protocol = "gemini"
url = "https://generativelanguage.googleapis.com/v1beta/models/gemini-embedding-001:embedContent"
model = "gemini-embedding-001"
dimensions = 768
api_key_env = "GEMINI_API_KEY"

[rag.generation]
protocol = "gemini"
url = "https://generativelanguage.googleapis.com/v1beta/models/YOUR_MODEL:generateContent"
model = "YOUR_MODEL"
api_key_env = "GEMINI_API_KEY"

Définissez la variable d'environnement nommée pour la clé d'API dans l'environnement du démon. Ne placez pas de valeurs de clé dans TOML, les URL ou les arguments de commande. Gemini utilise x-goog-api-key ; protocol = "compatible" utilise l'authentification Bearer et les formats JSON courants de plongement {model,input} et de complétion de conversation. La réponse de plongement compatible doit contenir des entrées data indexées avec des tableaux embedding ; la génération renvoie choices[0].message.content. Les clés sont facultatives pour les services locaux. Les URL distantes nécessitent HTTPS ; HTTP n'est accepté que sur l'interface de bouclage. Le paramètre facultatif de plongement dimensions est envoyé comme outputDimensionality pour Gemini ou dimensions pour le protocole compatible, vérifié à réception et intégré à la clé d'espace vectoriel. Les informations d'authentification, chaînes de requête et fragments ne sont pas acceptés dans les URL d'opération.

Il n'existe aucun point d'accès public implicite aux modèles. Configurer une URL de plongement distante autorise l'envoi des fragments de documents admissibles à cette adresse. La génération envoie uniquement les fragments sélectionnés et la question ; aucun contenu stocké d'identifiant/privé/fichier n'entre dans cette chaîne. Ces paramètres de configuration appartiennent au démon et non aux appels MCP individuels. Voir la sécurité.

Recherche hybride et reclassement

Le mode vectoriel utilise la similarité cosinus. Le mode hybride fusionne les classements BM25 et vectoriels par fusion des rangs réciproques (k=60). Le reclassement léger par défaut favorise la couverture des termes et les expressions correspondantes. Il ne prétend pas être un encodeur croisé entraîné. Configurez un service de reclassement entraîné si vous le souhaitez :

[rag.rerank]
protocol = "compatible"
url = "https://your-reranker.example/rerank"
model = "YOUR_RERANKER"
api_key_env = "RERANK_API_KEY"

La requête est {model, query, documents, top_n}. Sa réponse doit contenir results avec un index valide unique et un relevance_score fini pour chaque candidat. Les entrées inconnues/dupliquées provoquent un échec plutôt qu'un réordonnancement silencieux du mauvais document. --no-rerank ignore les deux étapes facultatives de reclassement.

Proxys, délais et nouvelles tentatives

[rag.http]
use_env_proxy = true
proxy_url = "http://127.0.0.1:7890"
retries = 2
backoff_ms = 500
connect_timeout_seconds = 10
timeout_seconds = 60
download_timeout_seconds = 900

Les proxys explicites remplacent la découverte des proxys d'environnement. Les URL HTTP, HTTPS, SOCKS5 et SOCKS5h sont prises en charge. Les valeurs de proxy authentifié peuvent être fournies via l'environnement de proxy ; les URL de proxy TOML ne peuvent pas contenir d'informations d'authentification. Les points d'accès modèle/miroir en bouclage se connectent toujours directement. La vérification TLS reste activée.

retries est le nombre de tentatives supplémentaires (0-5). Les échecs de connexion/ lecture de l'API du modèle, 429 et 500/502/503/504 peuvent être retentés avec un délai exponentiel ; les secondes de Retry-After sont respectées jusqu'à 30 secondes. Les erreurs d'authentification/validation, redirections dangereuses et sorties de modèle mal formées ne sont pas retentées. Les redirections de l'API du modèle sont désactivées. Les redirections de téléchargement exigent HTTPS et chaque fichier final est vérifié par son empreinte. Le délai de téléchargement est un budget par fichier. Retenter la génération peut entraîner une facturation supplémentaire du fournisseur. L'autorisation/l'annulation est revérifiée entre les tentatives.

Réponses, citations et MCP

memory_retrieve expose une recherche à périmètre limité aux clients MCP ; memory_ask appelle le service de génération configuré. Tous deux préservent les restrictions de l'autorisation concernant le coffre et les données ordinaires. Ils ne peuvent pas sélectionner un point d'accès arbitraire ou accéder à un identifiant. Les coffres limités à l'appareil rejettent les opérations qui enverraient des données vers des points d'accès modèle hors bouclage ; l'inférence locale et les services de bouclage explicitement configurés fonctionnent. Les anciens outils memory_search et memory_read continuent de fonctionner. La compétence Memories fournie documente memory_retrieve et memory_ask pour les clients d'IA. Après une mise à niveau, remplacez une ancienne compétence installée avec memories inject all --force.

La génération reçoit le texte source comme données non fiables et ne dispose d'aucun outil applicatif. Le modèle doit renvoyer un JSON structuré de réponse/citations, avec des citations telles que [S1] qui existent réellement dans le résultat. Les identifiants invalides ou inventés sont rejetés. En l'absence de preuves, aucun appel de génération n'est effectué et le résultat indique insufficient_evidence. La validation des citations vérifie les références, pas le fondement factuel de chaque affirmation ; vérifiez les réponses importantes à partir de leurs sources.

Le verrouillage, les autorisations expirées/révoquées et les changements de l'état source invalident le travail en cours et suppriment les résultats tardifs. Une requête distante déjà lancée ne peut pas être rappelée. Aucune interface RAG utilisant un modèle n'est ajoutée à la FFI mobile dans cette version ; la recherche ordinaire mobile reçoit les améliorations chinoises/BM25 et peut utiliser la recherche BM25.