> Discover all available pages from the documentation index: https://mastra.zisheng.pro/fr/llms.txt # filterRun() Crée une fonction `prepareRun` à partir d’options déclaratives. Transmettez le résultat à `createScorer()` pour filtrer les messages et limiter la taille du contexte. La fonction supprime également les champs inutiles avant l’exécution du pipeline du scorer. Utilisez [`filterRun()`](#usage-example) pour le filtrage déclaratif. Écrivez directement une fonction `prepareRun` personnalisée lorsque vous avez besoin d’une logique impérative que `filterRun()` ne couvre pas. Pour en savoir plus, consultez la section [Scorers personnalisés : filtrage des entrées](https://mastra.zisheng.pro/fr/docs/evals/custom-scorers). ## Exemple d’utilisation L’exemple suivant crée un scorer qui ne reçoit que les appels de Tools et les messages textuels, limités aux 20 messages de contexte les plus récents : ```typescript import { createScorer, filterRun } from '@mastra/core/evals' const toolScorer = createScorer({ id: 'tool-usage', description: 'Evaluates tool usage patterns', type: 'agent', prepareRun: filterRun({ partTypes: ['tool-invocation', 'text'], maxRememberedMessages: 20, }), }).generateScore(({ run }) => { // run.input.rememberedMessages contains only tool and text messages // run.output contains only tool and text messages return 1 }) ``` ### Filtrer par nom de Tool Conservez uniquement les messages qui impliquent des Tools donnés : ```typescript import { createScorer, filterRun } from '@mastra/core/evals' const fileEditScorer = createScorer({ id: 'file-edit-quality', description: 'Evaluates file editing patterns', type: 'agent', prepareRun: filterRun({ toolNames: ['write_file', 'string_replace_lsp', 'view'], }), }).generateScore(({ run }) => { // Only messages with these tool calls remain return 1 }) ``` ### Supprimer des champs Supprimez les champs dont le scorer n’a pas besoin : ```typescript import { createScorer, filterRun } from '@mastra/core/evals' const simpleScorer = createScorer({ id: 'response-length', description: 'Checks response length', type: 'agent', prepareRun: filterRun({ dropRequestContext: true, dropExpectedTrajectory: true, dropGroundTruth: true, maxOutputMessages: 5, }), }).generateScore(({ run }) => { return run.output.length > 0 ? 1 : 0 }) ``` ## Paramètres **options** (`FilterRunOptions`): Objet de configuration qui contrôle les données reçues par le scorer. **options.partTypes** (`MastraPartType[]`): Conserve uniquement les messages dont les parties correspondent à ces types. Chaque entrée est comparée au préfixe du type de la partie du message. Les messages en texte brut (sans appel de Tool) sont toujours conservés, sauf s’ils sont explicitement exclus. Les messages système et les messages système balisés ne sont jamais filtrés. **options.toolNames** (`string[]`): Conserve uniquement les messages d’appel des Tools indiqués. Chaque entrée est comparée au préfixe du nom du Tool. Les messages qui ne concernent pas un Tool (texte, données) ne sont pas affectés. **options.maxRememberedMessages** (`number`): Nombre maximal de messages à conserver parmi les messages mémorisés (contexte). Les messages sont sélectionnés depuis la fin, donc parmi les plus récents. Cette limite est appliquée après le filtrage par type et par Tool. **options.maxOutputMessages** (`number`): Nombre maximal de messages à conserver dans la sortie. Les messages sont sélectionnés depuis la fin. Cette limite est appliquée après le filtrage par type et par Tool. **options.dropRequestContext** (`boolean`): Supprime entièrement le contexte de requête de l’exécution. **options.dropExpectedTrajectory** (`boolean`): Supprime la trajectoire attendue de l’exécution. **options.dropGroundTruth** (`boolean`): Supprime la vérité terrain de l’exécution. **Renvoie :** `(run: ScorerRun) => ScorerRun`. Une fonction adaptée à l’option `prepareRun` de [`createScorer()`](https://mastra.zisheng.pro/fr/reference/evals/create-scorer). ## Types de parties L’option `partTypes` accepte des valeurs `MastraPartType`. Chaque valeur est comparée comme préfixe ; ainsi, `'data-'` correspond à tous les types de parties de données. | Type | Description | | ------------------- | ------------------------------------------------------------------ | | `'text'` | Parties de contenu textuel | | `'tool-invocation'` | Parties d’appel et de résultat de Tool | | `'reasoning'` | Parties de raisonnement en chaîne de pensée | | `'step-start'` | Parties servant de marqueurs d’étape | | `'image'` | Parties d’image | | `'file'` | Parties de fichier | | `'source'` | Parties de référence de source | | `'source-document'` | Parties de document source | | `'data-'` | Toutes les parties de données (correspond à tout préfixe `data-*`) | | `'data-om-'` | Parties de données d’Observational Memory | | `'data-workspace-'` | Parties de données du Workspace | | `'data-sandbox-'` | Parties de données du Sandbox | | `'data-tool-'` | Parties de données liées aux Tools | ## Comportement du filtrage - Le **filtrage par type de partie** s’applique à `input.rememberedMessages` et à `output` lorsqu’ils contiennent des tableaux de messages d’Agent. - Le **filtrage par nom de Tool** ne concerne que les messages qui contiennent des appels de Tool. Les messages exclusivement textuels sont transmis. - Les **messages système** (`systemMessages`, `taggedSystemMessages`) ne sont jamais filtrés, quelles que soient les valeurs de `partTypes` ou `toolNames`. - Les **limites de messages** (`maxRememberedMessages`, `maxOutputMessages`) s’appliquent après le filtrage par type et par Tool, en sélectionnant les messages les plus récents. - Lorsque `partTypes` et `toolNames` sont tous deux définis, un message doit satisfaire les deux filtres pour être conservé.