Classe représentant des données audio dans un format pris en charge (wav ou mp3).Cette classe gère le stockage des données audio et fournit des méthodes pour les charger depuis différentes sources et les exporter vers des fichiers.Attributs :
format : Le format audio (actuellement, ‘wav’ ou ‘mp3’ sont pris en charge)
data : Les données audio brutes, sous forme d’octets
Arguments :
data : Les données audio (octets ou string encodée en base64)
format : Le format audio (‘wav’ ou ‘mp3’)
validate_base64 : Indique s’il faut tenter de décoder les données d’entrée en base64
Exceptions levées :
ValueError : Si les données audio sont vides ou si le format n’est pas pris en charge
Un moniteur qui fusionne plusieurs évaluateurs en un seul classifieur.Les moniteurs de classification regroupent les prompts de plusieurs LLMAsAJudgeScorers ciblant le même modèle en un seul appel d’évaluation.Champs Pydantic :
Normalise op_names lors de la construction lorsqu’un client est disponible.La publication ne dispose d’aucun hook par objet. Pour couvrir également un simple appel à weave.publish(monitor) (sans activate()), les noms courts sont donc développés ici : toute personne qui publie a généralement déjà appelé weave.init, de sorte que le client est défini au moment de la construction du moniteur.Dans plusieurs cas d’usage, la construction s’effectue sans client : tests unitaires, inspection, ou encore désérialisation d’un moniteur stocké dans un worker. La vérification sur get_weave_client() permet la construction sans client. Dans ce cas, la normalisation n’a pas lieu, ce qui ne devrait pas poser de problème, car les moniteurs stockés contiennent déjà des réf. complètes.Il existe un cas limite dans lequel un moniteur peut être créé avec le SDK sans être normalisé : lorsque l’utilisateur construit le moniteur, appelle ensuite weave.init, puis le publie. Pour contourner ce problème, vous pouvez appeler activate() ou deactivate().
Classe permettant de représenter du contenu issu de diverses sources en le convertissant en une représentation unifiée sous forme d’octets, accompagnée des métadonnées associées.Cette classe doit être instanciée à l’aide de l’une de ses classmethods :
Affiche les données sous forme de string. Les octets sont décodés à l’aide de l’attribut encoding. Si l’encodage est base64, les données sont réencodées en octets base64, puis décodées en string ASCII.Retourne :
str.
Initialise un objet Content en récupérant des octets depuis une URL HTTP(S).Télécharge le contenu, déduit le type MIME et l’extension à partir des en-têtes, du chemin de l’URL et des données, puis construit un objet Content à partir des octets obtenus.
Ouvre le fichier avec l’application par défaut du système d’exploitation.Cette méthode s’appuie sur le mécanisme propre à la plateforme pour ouvrir le fichier avec l’application par défaut associée à son type.Retourne :
bool : True si le fichier a bien été ouvert, False sinon.
Copie le fichier vers le chemin de destination spécifié. Met à jour le nom de fichier et le chemin du contenu pour refléter la dernière copie enregistrée.Arguments :
dest : chemin de destination vers lequel le fichier sera copié (string ou pathlib.Path). Le chemin de destination peut être un fichier ou un répertoire. Si dest n’a pas d’extension de fichier (par exemple .txt), la destination est considérée comme un répertoire.
Arguments :
use_base64 : si True, les données sont encodées en base64. Sinon, elles sont encodées en pourcentage (percent-encoding). Valeur par défaut : True.
Retourne :
Une URL de données sous forme de string.
Une conversation. Regroupe les tours de conversation par conversation_id (sans span).continue_parent_trace contrôle l’isolation des traces pour les tours de conversation créés par cette conversation. Avec la valeur par défaut False, chaque tour de conversation démarre sa propre trace OTel (le choix adapté à la vue autonome de l’onglet Agents). Définissez True lorsque l’application dispose d’une trace externe (par exemple, une requête instrumentée par fastapi) qui doit englober l’appel d’agent.Champs Pydantic :
Crée un nouveau tour de conversation. Termine automatiquement le tour de conversation précédent s’il est encore ouvert.Définit la contextvar _current_turn afin que le tour de conversation soit accessible via get_current_turn(), qu’un gestionnaire de contexte soit utilisé ou non. Chacun des paramètres agent_name / model / agent_id / agent_description / agent_version reprend la valeur par défaut de la conversation s’il est laissé vide ; continue_parent_trace est hérité. Vous pouvez redéfinir n’importe lequel d’entre eux ultérieurement via turn.record(...).system_instructions (le prompt système de l’agent) est porté par le span invoke_agent du tour de conversation ; vous pouvez également le définir ultérieurement en affectant l’attribut sur le Turn renvoyé, comme pour start_llm.
Objet Dataset offrant un enregistrement simplifié et une gestion automatique des versions.Exemples :
# Créer un datasetdataset = Dataset(name='grammar', rows=[ {'id': '0', 'sentence': "He no likes ice cream.", 'correction': "He doesn't like ice cream."}, {'id': '1', 'sentence': "She goed to the store.", 'correction': "She went to the store."}, {'id': '2', 'sentence': "They plays video games all day.", 'correction': "They play video games all day."}])# Publier le datasetweave.publish(dataset)# Récupérer le datasetdataset_ref = weave.ref('grammar').get()# Accéder à un exemple précisexample_label = dataset_ref.rows[2]['sentence']
Crée une nouvelle version du dataset en ajoutant des lignes au dataset existant.Cette méthode permet d’ajouter des exemples à des datasets volumineux sans avoir à charger l’intégralité du dataset en mémoire.Arguments :
Configure une évaluation comprenant un ensemble d’évaluateurs et un dataset.L’Appel à evaluation.evaluate(model) transmet les lignes d’un dataset à un modèle, en faisant correspondre les noms des colonnes du dataset aux noms des arguments de model.predict.La méthode appelle ensuite tous les évaluateurs et enregistre les résultats dans Weave.Pour prétraiter les lignes du dataset, vous pouvez transmettre une fonction à preprocess_model_input.Exemples :
# Rassemblez vos exemplesexamples = [ {"question": "What is the capital of France?", "expected": "Paris"}, {"question": "Who wrote 'To Kill a Mockingbird'?", "expected": "Harper Lee"}, {"question": "What is the square root of 64?", "expected": "8"},]# Définissez une fonction de score personnalisée@weave.opdef match_score1(expected: str, model_output: dict) -> dict: # Définissez ici la logique d'évaluation de la sortie du modèle return {'match': expected == model_output['generated_text']}@weave.opdef function_to_evaluate(question: str): # ajoutez ici votre appel LLM et renvoyez la sortie return {'generated_text': 'Paris'}# Évaluez vos exemples à l'aide de fonctions de scoreevaluation = Evaluation( dataset=examples, scorers=[match_score1])# Démarrez le suivi de l'évaluationweave.init('intro-example')# Exécutez l'évaluationasyncio.run(evaluation.evaluate(function_to_evaluate))
Récupère tous les Appels d’évaluation ayant utilisé cet objet Evaluation.Notez que cette méthode renvoie un CallsIter plutôt qu’un Appel unique, car une même évaluation peut donner lieu à plusieurs Appels d’évaluation (par exemple, si vous exécutez la même évaluation plusieurs fois).Retourne :
CallsIter : Un itérateur sur des objets Appel représentant des runs d’évaluation.
Exceptions levées :
ValueError : Si l’évaluation n’a pas de réf. (elle n’a pas encore été enregistrée ni exécutée).
Exemples :
evaluation = Evaluation(dataset=examples, scorers=[scorer])await evaluation.evaluate(model) # Exécutez d’abord l’évaluationcalls = evaluation.get_evaluate_calls()for call in calls: print(f"Evaluation run: {call.id} at {call.started_at}")
Récupère les Appels d’évaluateur pour chaque run d’évaluation, regroupés par ID de trace.Retourne :
dict[str, list[Call]] : Un dictionnaire associant les ID de trace à des listes d’objets Appel d’évaluateur. Chaque ID de trace correspond à un run d’évaluation et la liste contient tous les Appels d’évaluateur exécutés au cours de ce run.
Exemples :
evaluation = Evaluation(dataset=examples, scorers=[accuracy_scorer, f1_scorer])await evaluation.evaluate(model)score_calls = evaluation.get_score_calls()for trace_id, calls in score_calls.items(): print(f"Trace {trace_id}: {len(calls)} scorer calls") for call in calls: scorer_name = call.summary.get("weave", {}).get("trace_name") print(f" Scorer: {scorer_name}, Output: {call.output}")
Extrait et organise les sorties des évaluateurs à partir des runs d’évaluation.Retourne :
dict[str, dict[str, list[Any]]] : Une structure de dictionnaire imbriqué dans laquelle :
les clés de premier niveau sont les ID de trace (runs d’évaluation) ;
les clés de second niveau sont les noms des évaluateurs ;
les valeurs sont des listes de sorties d’évaluateur pour le run et l’évaluateur correspondants.
Exemples :
evaluation = Evaluation(dataset=examples, scorers=[accuracy_scorer, f1_scorer])await evaluation.evaluate(model)scores = evaluation.get_scores()# Accéder aux scores par trace et par évaluateurfor trace_id, trace_scores in scores.items(): print(f"Evaluation run {trace_id}:") for scorer_name, outputs in trace_scores.items(): print(f" {scorer_name}: {outputs}")
Cette classe fournit une interface impérative pour journaliser des évaluations.Une évaluation démarre automatiquement lorsque la première prédiction est journalisée à l’aide de la méthode log_prediction, et se termine lorsque la méthode log_summary est appelée.Chaque fois que vous journalisez une prédiction, un objet ScoreLogger vous est renvoyé. Cet objet vous permet de journaliser des scores et des métadonnées propres à cette prédiction. Pour plus d’informations, voir la classe ScoreLogger.Utilisation de base – journaliser directement des prédictions avec leurs entrées et sorties :
ev = EvaluationLogger()# Journaliser des prédictions dont les entrées/sorties sont connuespred = ev.log_prediction(inputs={'q': 'Hello'}, outputs={'a': 'Hi there!'})pred.log_score("correctness", 0.9)# Terminer l’évaluationev.log_summary({"avg_score": 0.9})
Utilisation avancée : utiliser un gestionnaire de contexte pour les sorties dynamiques et les opérations imbriquées :
ev = EvaluationLogger()# Utilisez un gestionnaire de contexte pour capturer des opérations imbriquéeswith ev.log_prediction(inputs={'q': 'Hello'}) as pred: # Toute opération effectuée ici (comme un appel LLM) devient automatiquement # un enfant de l’appel de prédiction response = your_llm_call(...) pred.output = response.content pred.log_score("correctness", 0.9)# Terminer l’évaluationev.log_summary({"avg_score": 0.9})
Libère explicitement les ressources de l’évaluation sans journaliser de synthèse.Garantit que tous les Appels de prédiction ainsi que l’Appel principal de l’évaluation sont finalisés. Cette méthode est appelée automatiquement lorsque le logger est utilisé comme gestionnaire de contexte.
Journalise un exemple complet avec les entrées, la sortie et les scores.Cette méthode utilitaire combine log_prediction et log_score lorsque vous disposez de toutes les données dès le départ.Arguments :
inputs : les données d’entrée de la prédiction
output : la valeur de sortie
scores : dictionnaire associant les noms des évaluateurs aux valeurs de score
Exemple :
ev = EvaluationLogger()ev.log_example( inputs={'q': 'What is 2+2?'}, output='4', scores={'correctness': 1.0, 'fluency': 0.9})
Journalise une prédiction dans l’Évaluation.Renvoie un ScoreLogger utilisable directement ou comme gestionnaire de contexte.Arguments :
inputs : les données d’entrée de la prédiction
output : la valeur de sortie. Valeur par défaut : None. Peut être définie ultérieurement via pred.output.
Retourne :
Un ScoreLogger permettant de journaliser des scores et, si besoin, de finaliser la prédiction.Exemple (utilisation directe) :
pred = ev.log_prediction({'q': ’…’}, output=“answer”) pred.log_score(“correctness”, 0.9) pred.finish()
Exemple (gestionnaire de contexte) :
with ev.log_prediction({'q': ’…’}) as pred: response = model(…) pred.output = response pred.log_score(“correctness”, 0.9) # Appelle automatiquement finish() à la sortie
Journalise un dict de synthèse dans l’Évaluation.Cette méthode calcule la synthèse, appelle l’op summarize, puis finalise l’évaluation : il n’est alors plus possible de journaliser de prédictions ni de scores.
Joint une vue à la synthèse de l’Appel principal de l’évaluation, sous weave.views.Enregistre le contenu fourni en tant qu’objet dans le projet et écrit son URI de référence sous summary.weave.views.<name> pour l’Appel evaluate de l’évaluation. Les entrées de type string sont encapsulées en tant que contenu textuel à l’aide de Content.from_text, avec l’extension ou le type MIME fourni.Arguments :
name : nom de la vue à afficher, utilisé comme clé sous summary.weave.views.
content : instance de weave.Content ou string à sérialiser.
extension : extension de fichier facultative pour les entrées de contenu de type string.
mimetype : type MIME facultatif pour les entrées de contenu de type string.
metadata : métadonnées facultatives jointes au Content nouvellement créé.
encoding : encodage du texte pour les entrées de contenu de type string.
Ouvre le fichier avec l’application par défaut du système d’exploitation.Cette méthode s’appuie sur le mécanisme propre à la plateforme pour ouvrir le fichier avec l’application par défaut associée à son type.Retourne :
bool : True si le fichier a bien été ouvert, False sinon.
Un Appel d’API LLM. Correspond à un span OTel de chat.
dest : chemin de destination vers lequel le fichier sera copié (string ou pathlib.Path). Le chemin de destination peut être un fichier ou un répertoire.
Enregistre un événement de span OTel à un instant donné au sein de ce span.
Obsolète : Enregistrez plutôt ces données avec set_attributes. OpenTelemetry abandonne progressivement l’API Span Event (Span.add_event). add_event fonctionne toujours, et les données d’événements de span existantes restent valides. Voir https://opentelemetry.io/blog/2026/deprecating-span-events/.
À utiliser pour les données de marqueur ou de cycle de vie : demandes d’autorisation (par ex. weave.permission_request), transitions de cycle de vie (par ex. spawned / streaming / finished) ou tout jalon personnalisé survenant à un instant précis de la durée de vie du span (contrairement à un attribut, qui est une propriété du span dans son ensemble).Doit être appelée entre le début et la fin du span (à l’intérieur du bloc with). En dehors de cette fenêtre, l’Appel n’a aucun effet et journalise un avertissement.
Joindre un média à cet Appel LLM.Crée un objet Content à partir des données fournies, le publie pour obtenir une réf. weave:// et ne stocke que cette réf. Vous devez fournir exactement un des paramètres suivants : content, uri ou file_id.La publication (qui téléverse le média) s’exécute sur un thread d’arrière-plan dédié : l’Appel rend donc la main immédiatement, sans bloquer l’appelant. Un thread est lancé par pièce jointe, ce qui permet d’effectuer plusieurs téléversements en parallèle. L’objet MediaAttachment provisoire est ajouté de manière synchrone, et sa ref est renseignée une fois le téléversement terminé. Les réfs sont toujours renseignées avant l’émission du span (le chemin de construction attend la fin des téléversements en cours via _await_uploads).
Joint une URL de média à cet Appel LLM.Raccourci pratique pour attach_media dans le cas courant où l’appelant dispose d’une URL sous forme de string provenant d’un message en amont. Les URL data: sont décodées en octets puis publiées ; les URI simples sont récupérées puis publiées. Les URL vides sont ignorées. Renvoie self pour permettre le chaînage.
Définit plusieurs champs d’appel LLM en un seul appel.Les agents instrumentés manuellement construisent généralement un span de chat en attribuant au moins huit champs distincts à la fin d’un appel LLM (input_messages, output_messages, usage, response_id, etc.). record(...) les regroupe en un seul appel avec arguments nommés, ce qui permet de garder compact le code d’enregistrement.Seuls les champs explicitement transmis (autres que None) sont appliqués ; les valeurs existantes sont conservées. reasoning accepte soit une instance de Reasoning, soit une simple chaîne de caractères (encapsulée automatiquement). Renvoie self pour permettre le chaînage.
Ajoute des attributs OTel arbitraires à ce span.Passez un dict, que vous ayez une seule clé ou plusieurs : pour une seule clé, utilisez span.set_attributes({"weave.tag": "value"}). Équivalent de Span.set_attributes d’OTel.Doit être appelée entre le début et la fin du span, c’est-à-dire à l’intérieur d’un bloc with. En dehors de cette fenêtre, l’appel est sans effet (no-op) et journalise un avertissement. Pour l’ingestion par lots, renseignez directement les champs déclarés de l’objet et passez celui-ci à log_turn / log_conversation.
Un objet Markdown pouvant faire l’objet d’un rendu.Arguments :
markup (str) : Une chaîne de caractères contenant du markdown.
code_theme (str, facultatif) : Thème Pygments pour les blocs de code. Valeur par défaut : “monokai”. Voir https://pygments.org/styles/ pour les thèmes de code disponibles.
justify (JustifyMethod, facultatif) : Valeur de justification des paragraphes. Valeur par défaut : None.
style (Union[str, Style], facultatif) : Style facultatif à appliquer au markdown.
hyperlinks (bool, facultatif) : Active les liens hypertextes. Valeur par défaut : True.
Un média joint à un appel LLM.Contient toujours une URI de réf. de contenu weave://. Les octets bruts, les URL de données et les URI HTTP simples sont convertis en objet Content publié par LLM.attach_media avant d’être stockés ici.
inline_code_lexer : (str, facultatif) : analyseur lexical à utiliser si la coloration syntaxique du code en ligne est activée. Valeur par défaut : None.
inline_code_theme : (Optional[str], facultatif) : thème Pygments pour la coloration syntaxique du code en ligne, ou None pour désactiver la coloration. Valeur par défaut : None.
Un message unique au sein d’une conversation.Deux styles de construction sont pris en charge :
Plat (rétrocompatible, pratique pour du texte brut) : Message(role="assistant", content="Hi there")
Parties explicites (plus complet — prend en charge les appels d’outil, le mélange de raisonnement et de texte, ainsi que les médias intégrés) : Message(role="assistant", parts=[TextPart(content="Let me check"), ToolCallPart(id="c1", name="get_weather", arguments='{...}')])
Lorsque parts n’est pas vide, il constitue la représentation canonique. S’il est vide, le sérialiseur génère un unique TextPart (ou ToolCallResponsePart pour role="tool") à partir des champs plats.Champs Pydantic :
Construit un message de l’assistant avec, de manière facultative, du texte et des appels d’outil.Utilisez du texte brut pour les réponses simples ; passez tool_calls lorsque l’assistant fait appel à un ou plusieurs outils. Lorsque les deux sont présents, le texte est émis sous la forme d’un TextPart initial, suivi de chaque ToolCallPart, afin que la vue du chat les affiche en ligne.
Construit un message de résultat d’outil pour un appel d’outil demandé précédemment.output peut être une chaîne de caractères, un dict, une liste, un scalaire ou None. Le ToolCallResponsePart sous-jacent encode en JSON les valeurs autres que des chaînes.
Formate un seul message en remplaçant les variables de modèle.Cette méthode délègue la logique de formatage proprement dite à la fonction autonome format_message_with_template_vars.
Destiné à capturer une combinaison de code et de données qui traite une entrée. Par exemple, il peut appeler un LLM avec un prompt pour faire une prédiction ou générer du texte.Lorsque vous modifiez les attributs ou le code qui définit votre modèle, ces modifications sont journalisées et la version est mise à jour. Vous pouvez ainsi comparer les prédictions entre les différentes versions de votre modèle. Utilisez cette fonctionnalité pour itérer sur vos prompts ou pour essayer le dernier LLM et comparer les prédictions obtenues avec différents paramètresExemples :
class YourModel(Model): attribute1: str attribute2: int @weave.op def predict(self, input_data: str) -> dict: # Placez ici la logique du modèle prediction = self.attribute1 + ' ' + input_data return {'pred': prediction}
Configure un moniteur chargé d’attribuer automatiquement un score aux appels entrants.Notez que le nom de l’op sera converti en réf. Weave à partir de l’entity et du projet du client Weave. Si vous travaillez sur plusieurs entities et projets avec le même client, vous devrez indiquer une réf. Weave entièrement qualifiée. Pour plus de détails, voir _normalized_op_names.Exemples :
Normalise op_names lors de la construction lorsqu’un client est disponible.La publication ne dispose d’aucun hook par objet. Pour couvrir également un simple weave.publish(monitor) (sans activate()), les noms courts sont donc développés ici : quiconque publie a généralement déjà appelé weave.init, si bien que le client est défini au moment de la construction du moniteur.Dans plusieurs cas d’usage, la construction se fait sans client : tests unitaires, inspection ou désérialisation d’un moniteur stocké dans un worker, par exemple. La vérification sur get_weave_client() autorise la construction sans client. La normalisation n’a alors pas lieu, mais cela ne devrait pas poser de problème, car les moniteurs stockés contiennent déjà des réf. complètes.Il existe un cas limite dans lequel un moniteur peut être créé avec le SDK sans être normalisé : lorsque l’utilisateur construit le moniteur, appelle ensuite weave.init, puis le publie. Pour contourner ce problème, vous pouvez appeler activate() ou deactivate().
Classe de base pour les objets Weave pouvant être suivis et versionnés.Cette classe étend la classe BaseModel de Pydantic afin de fournir des fonctionnalités propres à Weave pour le suivi, le référencement et la sérialisation des objets. Les objets peuvent avoir un nom, une description et des références, qui permettent de les stocker dans le système Weave et de les en récupérer.Attributs :
name (str | None) : Nom lisible de l’objet.
description (str | None) : Description de ce que représente l’objet.
ref (ObjectRef | None) : Référence à l’objet dans le système Weave.
Exemples :
# Créer un objet simpleobj = Object(name="my_object", description="A test object")# Créer un objet à partir d’un URIobj = Object.from_uri("weave:///entity/project/object:digest")
handle_relocatable_object( v: Any, handler: ValidatorFunctionWrapHandler, info: ValidationInfo) → Any
Gère la validation des objets relocalisables, notamment ObjectRef et WeaveObject.Ce validateur traite les cas particuliers où l’entrée est un ObjectRef ou un WeaveObject qui doit être correctement converti en instance standard de Object. Il garantit que les références sont conservées et que les types ignorés sont correctement pris en charge au cours du processus de validation.Arguments :
v (Any) : La valeur à valider.
handler (ValidatorFunctionWrapHandler) : Le gestionnaire de validation pydantic standard.
info (ValidationInfo) : Informations sur le contexte de validation.
Retourne :
Any : L’instance d’objet validée.
Exemples :
Cette méthode est appelée automatiquement lors de la création et de la validation d’un objet. Elle gère notamment les cas suivants :
# Lorsqu’un ObjectRef est transmisobj = MyObject(some_object_ref)# Lorsqu’un WeaveObject est transmisobj = MyObject(some_weave_object)
strip_weave_serialization_metadata(data: Any) → Any
Supprime les métadonnées de sérialisation de Weave des entrées de type dict.La sérialisation de Weave ajoute _type, _class_name et _bases aux dicts afin de permettre la reconstruction du type. Il ne s’agit pas de véritables champs du modèle : ils doivent donc être supprimés avant la validation Pydantic, qui utilise extra=“forbid”.
URL permettant d’afficher cette vue enregistrée dans l’interface utilisateur.Notez qu’il s’agit de la page de « résultats » contenant les traces, etc., et non de l’URL de l’objet vue.
Alias obsolète de :class:weave.Conversation.Accepte les anciens champs de constructeur session_id / session_name et les expose également sous forme de propriétés en lecture/écriture, redirigées vers conversation_id / conversation_name. Dans la classe Session d’origine, il s’agissait de champs de modèle : l’ancien code qui lit ou attribue s.session_id continue donc de fonctionner.
Enregistre un événement de span OTel à un instant donné dans ce span.
Obsolète : Enregistrez plutôt ces données avec set_attributes. OpenTelemetry abandonne progressivement l’API Span Event (Span.add_event). add_event fonctionne toujours et les données d’événements de span existantes restent valides. Voir https://opentelemetry.io/blog/2026/deprecating-span-events/.
À utiliser pour les données de marqueur ou de cycle de vie : demandes d’autorisation (par ex. weave.permission_request), transitions de cycle de vie (par ex. spawned / streaming / finished) ou tout jalon personnalisé survenant à un instant précis pendant la durée de vie du span (contrairement à un attribut, qui est une propriété du span dans son ensemble).Doit être appelée entre le début et la fin du span (à l’intérieur du bloc with). En dehors de cette fenêtre, l’appel n’a aucun effet et journalise un avertissement.
Démarre un appel LLM au sein de ce sous-agent.Définit la contextvar _current_llm afin que le LLM soit accessible via get_current_llm(), qu’un gestionnaire de contexte soit utilisé ou non.
Définit plusieurs champs du sous-agent en un seul appel.Regroupe en un seul appel à arguments nommés les affectations champ par champ qu’un agent instrumenté manuellement effectuerait sinon sur un sous-agent (system_instructions, agent_id, …). Seuls les champs explicitement transmis (différents de None) sont appliqués ; les valeurs existantes sont conservées. Renvoie self pour permettre le chaînage. Fonctionne comme Turn.record / LLM.record.Remarque : dans le cas du streaming (with), le nom du span du sous-agent est défini à partir de name lors de __enter__. Si vous souhaitez que le nom du span reflète name, définissez-le donc via start_subagent / turn.subagent plutôt que via record ; record met tout de même à jour l’attribut gen_ai.agent.name.
Appose des attributs OTel arbitraires sur ce span.Passez un dict, que vous ayez une seule clé ou plusieurs : pour une seule clé, utilisez span.set_attributes({"weave.tag": "value"}). Équivalent de Span.set_attributes d’OTel.Doit être appelé entre le début et la fin du span, c’est-à-dire à l’intérieur d’un bloc with. En dehors de cette fenêtre, l’appel est sans effet (no-op) et journalise un avertissement. Pour l’ingestion par lots, renseignez directement les champs déclarés de l’objet, puis passez-le à log_turn / log_conversation.
Un Thread qui exécute des fonctions avec le contexte de l’appelant.Il s’agit d’un remplacement direct de threading.Thread qui garantit que les appels se comportent comme prévu à l’intérieur du thread. Weave exige que certaines contextvars soient définies (voir call_context.py), mais les nouveaux threads ne copient pas automatiquement le contexte du parent, ce qui peut entraîner la perte du contexte d’appel, ce qui est fâcheux ! Cette classe automatise la copie des contextvars : ce thread « fonctionne tout simplement », comme l’utilisateur s’y attend sans doute.Vous pouvez obtenir le même résultat sans cette classe en écrivant plutôt :
Valeur booléenne indiquant si ce thread est un thread démon.Elle doit être définie avant l’appel à start(), sinon une RuntimeError est levée. Sa valeur initiale est héritée du thread qui le crée ; le thread principal n’étant pas un thread démon, tous les threads créés dans le thread principal ont par défaut daemon = False.L’ensemble du programme Python se termine lorsqu’il ne reste plus que des threads démons.
Identifiant de ce thread, ou None s’il n’a pas encore été démarré.Il s’agit d’un entier non nul. Voir la fonction get_ident(). Les identifiants de thread peuvent être réutilisés lorsqu’un thread se termine et qu’un autre thread est créé. L’identifiant reste disponible même après la fin du thread.
Chaîne de caractères utilisée uniquement à des fins d’identification.Elle n’a aucune valeur sémantique. Plusieurs threads peuvent porter le même nom. Le nom initial est défini par le constructeur.
Identifiant entier natif de ce thread, ou None s’il n’a pas encore été démarré.Il s’agit d’un entier positif ou nul. Voir la fonction get_native_id(). Cette valeur correspond à l’identifiant du thread tel qu’indiqué par le noyau.
Un ThreadPoolExecutor qui exécute des fonctions avec le contexte de l’appelant.Cette classe remplace directement concurrent.futures.ThreadPoolExecutor et garantit que les appels Weave se comportent comme prévu dans l’exécuteur. Weave exige que certaines contextvars soient définies (voir call_context.py), mais les nouveaux threads ne copient pas automatiquement le contexte du thread parent, ce qui peut entraîner la perte du contexte d’appel, ce qu’il faut éviter ! Cette classe automatise la copie des contextvars, de sorte que cet exécuteur « fonctionne tout simplement », comme l’utilisateur s’y attend probablement.Vous pouvez obtenir le même résultat sans cette classe en écrivant plutôt :
with concurrent.futures.ThreadPoolExecutor() as executor: contexts = [copy_context() for _ in range(len(vals))] def _wrapped_fn(*args): return contexts.pop().run(fn, *args) executor.map(_wrapped_fn, vals)
Une exécution d’outil. Correspond à un span OTel execute_tool.arguments et result utilisent l’annotation JSONString : les appelants peuvent attribuer un dict, une liste ou un scalaire, que le SDK encode en JSON lors de la construction ou de l’attribution. La valeur stockée est toujours une chaîne de caractères, conformément au format de transmission défini par les conventions sémantiques GenAI.Champs Pydantic :
Enregistre un événement de span OTel à un instant donné au sein de ce span.
Obsolète : Enregistrez plutôt ces données avec set_attributes. OpenTelemetry est en train d’abandonner progressivement l’API Span Event (Span.add_event). add_event fonctionne toujours et les données d’événements de span existantes restent valides. Voir https://opentelemetry.io/blog/2026/deprecating-span-events/.
À utiliser pour les données de marqueur ou de cycle de vie : demandes d’autorisation (par ex. weave.permission_request), transitions de cycle de vie (par ex. spawned / streaming / finished) ou tout jalon personnalisé qui survient à un instant précis pendant la durée de vie du span (contrairement à un attribut, qui est une propriété du span dans son ensemble).Doit être appelée entre le début et la fin du span (dans le bloc with). En dehors de cette fenêtre, l’appel est sans effet et journalise un avertissement.
Appose des attributs OTel arbitraires sur ce span.Passez un dict, que vous ayez une seule clé ou plusieurs : pour une seule clé, utilisez span.set_attributes({"weave.tag": "value"}). Équivalent de Span.set_attributes d’OTel.Doit être appelée entre le début et la fin du span, c’est-à-dire à l’intérieur d’un bloc with. En dehors de cet intervalle, l’appel n’a aucun effet (no-op) et journalise un avertissement. Pour une ingestion par lots, renseignez directement les champs déclarés de l’objet, puis passez-le à log_turn / log_conversation.
Un échange entre l’utilisateur et l’agent. Correspond à un span OTel invoke_agent.Par défaut, chaque tour de conversation démarre sa propre trace OTel (continue_parent_trace=False) : l’onglet Agents affiche donc une trace par tour de conversation. Définissez continue_parent_trace=True sur la Conversation (ou directement sur le Turn) lorsqu’une trace externe est déjà active et que vous souhaitez y imbriquer l’appel d’agent — par exemple, dans une requête instrumentée par fastapi.Champs Pydantic :
Enregistre un événement de span OTel à un instant donné dans ce span.
Obsolète : Enregistrez plutôt ces données avec set_attributes. OpenTelemetry abandonne progressivement l’API Span Event (Span.add_event). add_event fonctionne toujours et les données d’événements de span existantes restent valides. Voir https://opentelemetry.io/blog/2026/deprecating-span-events/.
À utiliser pour les données de marqueur ou de cycle de vie : demandes d’autorisation (par ex. weave.permission_request), transitions de cycle de vie (par ex. spawned / streaming / finished) ou tout jalon personnalisé qui survient à un instant précis pendant la durée de vie du span (contrairement à un attribut, qui est une propriété du span dans son ensemble).Doit être appelé entre le début et la fin du span (à l’intérieur du bloc with). En dehors de cet intervalle, l’appel est sans effet et journalise un avertissement.
Démarre un appel LLM (span de chat, enfant de ce tour de conversation).Définit la contextvar _current_llm afin que le LLM soit accessible via get_current_llm(), qu’un gestionnaire de contexte soit utilisé ou non.
Définit plusieurs champs du tour de conversation en un seul appel.Regroupe en un seul appel à arguments nommés les affectations champ par champ qu’un agent instrumenté manuellement devrait sinon effectuer sur un tour de conversation (system_instructions, agent_id, …). Seuls les champs explicitement transmis (non None) sont appliqués ; les valeurs existantes sont conservées. messagesremplace les messages existants du tour de conversation (contrairement à Turn.user(...), qui ajoute un seul message). Renvoie self pour permettre le chaînage. Fonctionne comme LLM.record.Remarque : sur le chemin de streaming (with), le span du tour de conversation est nommé d’après agent_name lors de __enter__. Si le nom du span doit refléter agent_name, définissez-le donc via start_turn plutôt que via record ; record met tout de même à jour l’attribut gen_ai.agent.name.
Appose des attributs OTel arbitraires sur ce span.Passez un dict, que vous ayez une seule clé ou plusieurs : pour une seule clé, utilisez span.set_attributes({"weave.tag": "value"}). Reproduit la méthode Span.set_attributes d’OTel.Doit être appelée entre le début et la fin du span, c.-à-d. à l’intérieur d’un bloc with. En dehors de cet intervalle, l’appel est sans effet (no-op) et journalise un avertissement. Pour une ingestion par lot, renseignez directement les champs déclarés de l’objet et passez-le à log_turn / log_conversation.
Étant donné une fonction décorée avec @weave.op, renvoie son Op.Les fonctions décorées avec @weave.op sont déjà des instances d’Op ; cette fonction n’a donc aucun effet à l’exécution (no-op). Vous pouvez toutefois l’utiliser pour satisfaire les vérificateurs de types si vous devez accéder aux attributs d’OpDef de manière sûre sur le plan du typage.
obj_ref : Référence à la version de l’objet, soit un ObjectRef (renvoyé par weave.publish()), soit une chaîne URI weave ///.
Arrête la journalisation vers Weave.Après l’appel à finish, les appels des fonctions décorées avec weave.op ne sont plus journalisés. Pour reprendre la journalisation, vous devez exécuter à nouveau weave.init().
Une fonction utilitaire permettant d’obtenir un objet à partir d’une URI.De nombreux objets journalisés par Weave sont automatiquement enregistrés auprès du serveur Weave. Cette fonction vous permet de récupérer ces objets à partir de leur URI.Arguments :
uri : une URI de réf. Weave entièrement qualifiée.
Obtenir l’objet Call de l’Op en cours d’exécution, à l’intérieur de cet Op.Retourne :
L’objet Call de l’Op en cours d’exécution, ou None si le suivi n’a pas été initialisé ou si cette méthode est invoquée en dehors d’un Op.Remarque :
Le dictionnaire attributes du Call renvoyé devient immuable dès que l’appel démarre. Utilisez :func:weave.attributes pour définir les métadonnées de l’appel avant d’invoquer un Op. Le champ summary peut être mis à jour pendant l’exécution de l’Op et sera fusionné avec les informations de synthèse calculées lorsque l’appel se terminera.
Initialise le suivi Weave, avec journalisation dans un projet wandb.La journalisation est initialisée globalement : vous n’avez donc pas besoin de conserver une référence à la valeur de retour de init.Une fois init appelé, les appels aux fonctions décorées avec weave.op sont journalisés dans le projet spécifié.Arguments :REMARQUE : le post-traitement au niveau du client s’exécute après le post-traitement propre à chaque op. L’ordre est toujours le suivant : 1. Post-traitement spécifique à l’op 2. Post-traitement au niveau du client
project_name : le nom de l’équipe et du projet Weights & Biases dans lesquels journaliser les données. Si vous ne spécifiez pas d’équipe, votre entity par défaut est utilisé. Pour trouver ou modifier votre entity par défaut, référez-vous à la page Paramètres utilisateur de la documentation W&B.
settings : configuration générale du client Weave. Peut être une instance de UserSettings ou un dict contenant l’une des clés suivantes (toutes facultatives). Tous les paramètres peuvent également être configurés par
des variables d’environnement avec le préfixe WEAVE_ (par exemple, WEAVE_DISABLED=true). Paramètres disponibles : - disabled (bool) : désactive le traçage de toutes les fonctions. Par défaut : False - print_call_link
(bool) : affiche dans le terminal des liens vers l’interface Weave pour les ops. Par défaut : True - log_level (str) : définit le type d’informations à journaliser (DEBUG, INFO, WARNING, ERROR, CRITICAL). Par défaut : INFO -
display_viewer (str) : détermine la façon dont Weave affiche les objets dans la console (auto, rich, print). Par défaut : auto - capture_code (bool) : capture le code des ops tracés dans votre projet Weave.
Par défaut : True - implicitly_patch_integrations (bool) : patche automatiquement les bibliothèques prises en charge. Par défaut : True - redact_pii (bool) : analyse toutes les données de trace à la recherche d’informations sensibles, comme les adresses e-mail, les numéros
de téléphone et les numéros de carte bancaire, et les remplace par des valeurs de substitution avant l’envoi au serveur. Nécessite les paquets presidio-analyzer et presidio-anonymizer.
Default : False - redact_pii_fields (list[str]) : indique les types d’entités PII à masquer lorsque redact_pii vaut True. Si la liste est vide, l’ensemble par défaut de Presidio est utilisé. Exemples : [‘EMAIL’,‘PHONE_NUMBER’,‘CREDIT_CARD’,‘US_SSN’]. Voir la liste complète à l’adresse https://microsoft.github.io/presidio/supported_entities/
Default : [] - redact_pii_exclude_fields (list[str]) : types d’entités PII à exclure. Par défaut : [] - capture_client_info (bool) : capture les informations de version de Python/du SDK. Par défaut : True -
capture_system_info (bool) : capture les informations sur le système d’exploitation. Par défaut : True - client_parallelism (int) : nombre de workers pour les ops en arrière-plan. Par défaut : auto - use_server_cache (bool) : active la mise en cache locale
sur disque des réponses du serveur. - server_cache_size_limit (int) : taille maximale du cache, en octets. Par défaut : 1_000_000_000 - server_cache_dir (str) : répertoire du cache du serveur. Par défaut : temporary -
scorers_dir (str) : répertoire des points de contrôle des modèles d’évaluateurs. Par défaut : ~/.cache/wandb/weave-scorers - max_calls_queue_size (int) : taille maximale de la file d’attente (0 = illimitée). Par défaut : 100_000 -
retry_max_interval (float) : intervalle maximal entre les nouvelles tentatives, en secondes. Par défaut : 300 - retry_max_attempts (int) : nombre maximal de nouvelles tentatives. Par défaut : 3 - enable_disk_fallback (bool) : écrit sur le disque les éléments
rejetés. Par défaut : True - use_parallel_table_upload (bool) : active le téléversement parallèle par fragments pour les tableaux volumineux. Si False, les tableaux sont téléversés séquentiellement, en fragments plus petits.
Default : True - http_timeout (float) : délai maximal, en secondes, accordé aux requêtes HTTP pour se terminer. Ce délai inclut le temps de connexion, le transfert des données et le traitement côté serveur. Augmentez cette valeur si le réseau est lent ou si vous manipulez des charges utiles volumineuses.
Default : 30.0 - use_stainless_server (bool) : utilise le client HTTP généré par Stainless, qui offre une meilleure sûreté de typage, de nouvelles tentatives automatiques et une gestion des erreurs améliorée. Cette fonctionnalité est expérimentale et pourrait devenir le comportement par défaut dans de futures versions.
Default : False - use_calls_complete (bool) : utilise un chemin d’écriture optimisé qui regroupe les données complètes d’un appel (début et fin) dans une seule requête, plutôt que dans des requêtes de début et de fin distinctes. Cela réduit la charge du serveur et améliore les performances, en particulier pour les ops de courte durée.
Default : True - use_otel_v2 : (bool) : Achemine les intégrations compatibles OTel via leur variante OTel.
Default : True
autopatch_settings : (Obsolète) Configuration des intégrations d’autopatch. Utilisez plutôt le patching explicite.
postprocess_inputs : fonction appliquée aux entrées de chaque op tracé par ce client.
postprocess_output : fonction appliquée à la sortie de chaque op tracé par ce client.
attributes : un dictionnaire d’attributs appliqués à chaque trace produite par ce client.
Lie une version de prompt publiée au registre.Arguments :
prompt : un prompt publié, un ObjectRef ou une chaîne URI weave ///… entièrement qualifiée.
target_path : chemin de destination dans le registre, au format <registry_project>/<portfolio_name>, par exemple wandb-registry-prompts/my-prompt-collection.
aliases : alias facultatifs à joindre à la version créée dans le registre.
Retourne :
LinkAssetToRegistryRes : réponse analysée renvoyée par le point de terminaison registry-link.
Journalise un appel directement dans Weave sans utiliser le patron décorateur.Cette fonction fournit une API impérative pour journaliser des opérations dans Weave. Elle est utile lorsque vous souhaitez journaliser des appels après leur exécution, ou lorsque le patron décorateur ne convient pas à votre cas d’usage.Arguments :
op (str) : Le nom de l’opération à journaliser. Il sera utilisé comme op_name de l’appel. Les opérations anonymes (strings ne faisant pas référence à des ops publiés) sont prises en charge.
inputs (dict[str, Any]) : Un dictionnaire des paramètres d’entrée de l’opération.
output (Any) : La sortie/le résultat de l’opération.
parent (Call | None) : Appel parent facultatif dans lequel imbriquer cet appel. S’il n’est pas fourni, l’appel sera un appel de niveau racine (ou imbriqué dans le contexte d’appel actuel, s’il existe). Par défaut : None.
attributes (dict[str, Any] | None) : Métadonnées facultatives à joindre à l’appel. Elles sont figées une fois l’appel créé. Par défaut : None.
display_name (str | Callable[[Call], str] | None) : Nom d’affichage facultatif de l’appel dans l’interface utilisateur. Peut être une string ou un callable qui prend l’appel et renvoie une string. Par défaut : None.
use_stack (bool) : Indique s’il faut empiler l’appel sur la pile du runtime. Si True, l’appel sera disponible dans le contexte d’appel et accessible via weave.require_current_call(). Si False, l’appel est journalisé mais n’est pas ajouté à la pile d’appels. Par défaut : True.
exception (BaseException | None) : Exception facultative à journaliser si l’opération a échoué. Par défaut : None.
Retourne :
Call : L’objet Call créé et terminé, avec les informations de trace complètes.
Exemples :
Utilisation de base :
import weaveweave.init('my-project')call = weave.log_call( op="my_function", inputs={"x": 5, "y": 10}, output=15)# Journalisation avec des attributs et un nom d’affichage :call = weave.log_call( op="process_data", inputs={"data": [1, 2, 3]}, output={"mean": 2.0}, attributes={"version": "1.0", "env": "prod"}, display_name="Data Processing")# Journalisation d’une opération ayant échoué :try: result = risky_operation()except Exception as e: call = weave.log_call( op="risky_operation", inputs={}, output=None, exception=e )# Imbrication d’appels :parent_call = weave.log_call("parent", {"input": 1}, 2)child_call = weave.log_call( "child", {"input": 2}, 4, parent=parent_call)# Journalisation sans ajout à la pile d’appels :call = weave.log_call( op="background_task", inputs={"task_id": 123}, output="completed", use_stack=False # Ne pas empiler sur la pile d’appels)
Émet de manière impérative une conversation complète.L’attribut .spans de chaque Turn fournit ses enfants. Génère automatiquement conversation_id s’il est vide. Par défaut, chaque tour de conversation dispose de sa propre trace OTel. agent_name / model / agent_id / agent_description / agent_version sont des valeurs par défaut au niveau de la conversation — la valeur propre à un Turn est prioritaire ; la valeur de la conversation n’est utilisée que si le Turn ne la renseigne pas. Le paramètre continue_parent_trace de la conversation s’applique à chaque tour de conversation (tout continue_parent_trace défini au niveau d’un Turn est ici volontairement ignoré).Les attributes sont apposés sur chaque span émis. Utilisez des clés personnalisées, hors conventions sémantiques (semconv) : une clé qui entre en conflit avec un attribut gen_ai.* / weave.* propre à un span n’est pas prise en charge (la valeur retenue dépend du chemin d’exécution).
Émet de manière impérative un tour de conversation et ses spans enfants vers OTel.À utiliser lorsque les gestionnaires de contexte ne sont pas envisageables (conteneurs sans état, callbacks, workers de file d’attente). Chaque span enfant transmis doit avoir started_at / ended_at définis ; les horodatages des spans OTel émis proviennent de ces champs. Si le tour de conversation ne fournit pas ses propres horodatages, l’horodatage le plus ancien/le plus récent des enfants est utilisé, puis now() à défaut. agent_id / agent_description / agent_version se comportent comme dans le chemin de streaming.Les attributes sont appliqués à chaque span émis ; le chemin de streaming, lui, les lit à partir de la conversation active. Utilisez des clés personnalisées, hors conventions sémantiques : une clé qui entre en conflit avec un attribut gen_ai.* / weave.* propre à un span n’est pas prise en charge (la valeur retenue dépend du chemin).
Un décorateur permettant de transformer une fonction ou une méthode en op Weave. Fonctionne aussi bien en mode synchrone qu’asynchrone. Détecte automatiquement les fonctions itératrices et applique le comportement approprié.Arguments :
Renvoie l’URL complète du point de terminaison HTTP OTLP pour l’ingestion des traces GenAI de Weave.Les appelants externes (par exemple, les sondes de démarrage qui doivent vérifier que le point de terminaison d’ingestion est joignable avant de s’en remettre au BatchSpanProcessor, qui abandonne les exports sans avertissement) doivent appeler cette fonction plutôt que de construire l’URL eux-mêmes. Le chemin relève du SDK et est susceptible de changer.
func : fonction à décorer.
name : nom personnalisé de l’op. Par défaut, le nom de la fonction.
call_display_name : nom d’affichage des appels ; peut être une string ou un callable.
postprocess_inputs : fonction qui transforme les entrées avant la journalisation.
postprocess_output : fonction qui transforme la sortie avant la journalisation.
tracing_sample_rate : fraction des appels à tracer (de 0.0 à 1.0).
enable_code_capture : indique s’il faut capturer le code source de cette op.
accumulator : fonction qui accumule les résultats des ops en streaming.
attributes : attributs par défaut fusionnés dans chaque appel créé par cette op, avec la priorité la plus faible. Un contexte weave.attributes() et des attributs par appel explicites les redéfinissent en cas de conflit de clé. La clé réservée “weave” ne peut pas être définie ici.
eager_call_start : si True, les débuts d’appel sont envoyés immédiatement plutôt que par lots. Utile pour les opérations de longue durée, comme les évaluations, qui doivent apparaître immédiatement dans l’interface utilisateur.
Enregistre un objet Python et en crée une version.Weave crée une nouvelle version de l’objet si un objet portant ce nom existe déjà et que son hachage de contenu ne correspond pas à celui de la dernière version de cet objet.
base_url : URL de base du trace server. Valeur par défaut : weave_trace_server_url().
Arguments :
obj : l’objet à enregistrer et à versionner.
name : le nom sous lequel enregistrer l’objet.
tags : liste facultative de tags à ajouter à la version d’objet publiée.
aliases : liste facultative d’alias à définir sur la version d’objet publiée.
Retourne :
Une réf. Weave vers l’objet enregistré.
Crée une Ref vers un objet Weave existant. Cette fonction ne récupère pas directement l’objet, mais vous permet de le transmettre à d’autres fonctions de l’API Weave.Arguments :
location : URI de réf. Weave ou, si weave.init() a été appelé, name:version ou name. Si aucune version n’est fournie, latest est utilisé.
Obtient l’objet Call de l’op en cours d’exécution, depuis cet op.Cela vous permet d’accéder aux attributs de l’appel, tels que son id ou son feedback, pendant son exécution.
Il est également possible d’accéder à un appel une fois que l’op a renvoyé son résultat.Si vous disposez de l’id de l’appel, obtenu par exemple depuis l’interface utilisateur, vous pouvez utiliser la méthode get_call du WeaveClient renvoyé par weave.init pour récupérer l’objet Call.
Crée et active une conversation. Définit la contextvar pour permettre l’accès depuis d’autres modules.Les attributes sont apposés sur chaque span émis par cette conversation (par exemple, une identité d’intégration comme weave.integration.*). Utilisez des clés personnalisées, hors conventions sémantiques (semconv) : pour les champs des conventions sémantiques, passez par les paramètres typés (conversation_name, model, …). Une clé qui entre en conflit avec un attribut gen_ai.* / weave.* propre à un span n’est pas prise en charge ; la valeur retenue dépend du chemin d’exécution (streaming ou log_turn).
Crée et active un appel LLM. Utilise le tour de conversation actuel s’il est disponible.Si aucun tour de conversation n’est actif, renvoie un LLM déconnecté (aucune contextvar définie).Transmettez explicitement provider_name. Le SDK ne le déduit pas de l’identifiant du modèle : une déduction fondée sur le préfixe attribue à tort les modèles issus d’un fine-tuning effectué par l’utilisateur (par exemple, un modèle nommé text-...) et inscrit dans la télémétrie des hypothèses sur les futurs noms de modèles, qu’il est coûteux de corriger a posteriori.
Crée un span d’appel de sous-agent.Le span OTel du SubAgent devient automatiquement l’enfant du span courant dans le contexte OTel — généralement un span Turn, s’il y en a un actif. Même structure que start_tool : le contexte OTel gère la propagation parent-enfant, sans qu’aucune délégation explicite soit nécessaire.
Crée un span d’exécution d’outil.Le span OTel de l’outil devient automatiquement l’enfant du span courant dans le contexte OTel, généralement un span de Turn s’il y en a un actif. Aucune délégation explicite au tour de conversation n’est nécessaire : la propagation parent-enfant s’effectue via le contexte OTel, et non via les contextvars du SDK Conversation.
Crée et active un tour de conversation. Utilise la conversation en cours si elle est disponible.Si aucune conversation n’est active, renvoie un Turn déconnecté qui n’est PAS défini dans la contextvar. Par conséquent, get_current_turn() renverra None. Utilisez plutôt conversation.start_turn() si vous avez besoin d’un accès entre modules reposant sur la contextvar.
Gestionnaire de contexte permettant de définir le thread_id des appels effectués dans ce contexte.Exemples :
# Génération automatique du thread_idwith weave.thread() as t: print(f"Thread ID: {t.thread_id}") result = my_function("input") # Cet appel recevra le thread_id généré automatiquement print(f"Current turn: {t.turn_id}")# thread_id explicitewith weave.thread("custom_thread") as t: result = my_function("input") # Cet appel recevra thread_id="custom_thread"# Désactivation du regroupement en threadswith weave.thread(None) as t: result = my_function("input") # Cet appel recevra thread_id=None
Arguments :
thread_id : identifiant du thread à associer aux appels dans ce contexte. S’il n’est pas fourni, un UUID v7 est généré automatiquement. S’il vaut None, le suivi des threads est désactivé.
Génère :
ThreadContext : objet donnant accès à thread_id et au turn_id actuel.
