Aller au contenu

Guides

Images, audio et vidéo

Oloproof évalue les systèmes qui reçoivent ou produisent des images, de l’audio et de la vidéo, et les fichiers ne quittent jamais l’endroit où votre système les garde. Une exécution enregistre chaque fichier par référence ; des vérifications déterministes mesurent les octets ; un juge peut voir les images, les images de vidéo et l’audio ; l’atelier les affiche à côté de chaque verdict. Le tutoriel parcourt les images sur un exemple exécutable.

Enregistrer des médias

Votre système enregistre les fichiers qu’un cas a reçus ou produits avec current_case().media(...), sous la forme d’un artefact media/v1 par appel :

from oloproof import current_case, media_file, system

@system(name="captioner", version="v2", records=("media/v1",))
def caption(case):
    image = render(case["prompt"])            # your system writes its own file
    current_case().media([
        media_file(case["photo"], role="input"),
        media_file(image),                    # role="output" by default
    ])
    return {"caption": describe(image)}

Dans oloproof.yaml, un système appelable déclare records: [media/v1]. Chaque élément contient :

ChampSignification
kindimage, audio ou video, d’après le type MIME
mime_typeimage/png, audio/wav, video/mp4 et ainsi de suite
urioù se trouve le fichier : un chemin file://, une URL https://, ou un chemin relatif au projet
digestle sha256 des octets, sha256:...
size_bytesla taille en octets
roleinput, output (par défaut) ou context
namele nom qu’un prompt ou une page lui donne ; media_file utilise le nom du fichier
width, height, duration_sfacultatifs, tels que votre système les déclare

media_file(path) les remplit à partir d’un fichier local. Rien n’est copié dans le stockage d’Oloproof. Tout ce qui lit le fichier plus tard, une vérification, un juge ou l’atelier, le lit via read_media, qui refuse des octets dont la taille ou le sha256 diffère de l’enregistrement : un contenu modifié arrête l’exécution, et un fichier disparu rend le cas manquant. Gardez les fichiers d’une exécution, inchangés, aussi longtemps que vous gardez l’exécution ; écrivez les sorties de chaque version à leur propre emplacement. Dans votre propre @evaluator, read_media(item) renvoie les octets vérifiés.

Vérifications sans modèle

media_check mesure chaque élément enregistré d’un rôle et réussit quand chacun remplit chaque condition déclarée :

  - type: media_check
    criterion: thumbnail_fits
    kind: image
    formats: [png, jpeg, webp]
    max_width: 256
    max_height: 256
    max_bytes: 50000

Le format est lu dans les premiers octets du fichier, donc un JPEG enregistré en .png échoue ; les dimensions des images et les durées WAV sont lues dans leurs en-têtes ; la taille d’une vidéo ou la longueur d’un MP3 est mesurée avec ffprobe. Les bornes de durée s’appliquent à l’audio et à la vidéo, les bornes de dimensions aux images et à la vidéo.

image_matches_reference réussit quand chaque image ressemble à une référence : leurs hachages perceptuels de 64 bits diffèrent d’au plus max_distance bits (8 par défaut). Une copie redimensionnée ou recompressée reste à quelques bits ; une image vide, un fichier cassé ou une autre scène, non. La référence est un seul reference_file pour chaque cas, ou un chemin que nomme l’expected de chaque cas avec reference_field. Le hachage lit la composition et la lumière, pas la couleur, donc il ne peut pas distinguer deux produits photographiés de la même manière, et les graphiques en aplats avec de grandes zones vides le font bouger davantage que les photographies. Il a besoin de Pillow : pip install 'oloproof[media]'.

Chaque champ est dans la référence de configuration. Les deux vérifications décident dès la première exécution, puisqu’elles n’appellent aucun modèle.

Des juges qui voient les médias

Un rubric_judge avec media voit les médias enregistrés du cas qui ont ce rôle (input, output ou all), chacun nommé dans son prompt pour que le juge puisse distinguer une entrée d’une sortie :

  - type: rubric_judge
    criterion: caption_matches
    provider: openai_compatible
    base_url: http://localhost:11434/v1
    model: qwen2.5vl
    rubric_text: Pass only if the caption truthfully describes the attached image.
    media: output
    video_frames: 4
    transcriber:
      model: whisper-1
  • Les images sont jointes telles quelles, jusqu’à 5 MB chacune et 20 par jugement.
  • La vidéo est jointe sous forme d’images fixes, extraites avec ffmpeg sur la machine qui exécute le juge : video_frames: 4 prend le milieu de quatre intervalles égaux, [0.5, 2.0] prend ces instants.
  • L’audio est transcrit par le transcriber (un point de terminaison /audio/transcriptions compatible OpenAI, celui d’OpenAI quand base_url est omis) et la transcription va dans le prompt ; ou, avec audio: native, il est joint comme son pour un modèle qui entend (wav et mp3 ; pas ceux d’Anthropic).

Les empreintes des médias font partie de la clé d’un jugement, donc des médias modifiés sont jugés à nouveau et des médias inchangés viennent du cache. Le transcripteur et les temps des images font partie de la version du juge, et chaque jugement conserve ses transcriptions et la version de ffmpeg. Un juge déclaré pour l’audio sans transcripteur, ou pour la vidéo sur une machine sans ffmpeg, arrête l’exécution plutôt que de laisser ces cas manquants. Un modèle hébergé facture chaque image comme chaque mot.

Valider un juge de médias

Un juge qui voit des médias ne décide rien tant que les étiquettes de personnes ne montrent pas qu’il est d’accord avec elles, exactement comme un juge qui lit du texte : étiquetez un échantillon aléatoire, puis oloproof evaluators validate (Juges). Dans un espace de travail hébergé, la file de relecture montre les médias de chaque cas au relecteur. Changer le modèle, la grille, media, les images de vidéo ou le transcripteur crée un nouveau juge, qui a besoin de sa propre validation.

Les médias dans l’atelier

Les médias d’un cas apparaissent à côté de sa sortie et de ses verdicts, sur la page du cas et dans la file de relecture, avec le type, la taille et l’empreinte de chaque fichier.

  • Un atelier local lit chaque fichier là où l’exécution l’a enregistré, sur votre machine, et ne l’affiche que tant que son sha256 correspond encore.
  • Un espace de travail hébergé ne reçoit jamais de médias. Le navigateur de la personne qui consulte récupère chaque fichier auprès de oloproof collect sur votre réseau, avec le même ticket à courte durée de vie que la file de relecture utilise pour le contenu des cas (Juges), et vérifie son sha256 avant de l’afficher. Sans collecteur, la page liste les caractéristiques de chaque fichier et dit pourquoi il n’est pas affiché.

Une exécution poussée transporte les enregistrements media/v1, avec l’endroit où chaque fichier est gardé, dans la catégorie d’egress artifacts ; une politique qui retient artifacts garde aussi ces emplacements de votre côté.

Non pris en charge

  • Générer des médias : votre système produit ses fichiers, et Oloproof les évalue.
  • Téléverser des médias vers Oloproof : il n’y a pas de téléversement, ni hébergé ni local.
  • Un modèle qui regarde une vidéo entière ou entend l’audio via l’API d’Anthropic : la vidéo y est jugée à partir d’images, et l’audio à partir d’une transcription.
  • Des vérifications déterministes de ce que contient l’audio ou la vidéo (taux d’erreur sur les mots, détection de scènes) : écrivez-en une avec @evaluator et read_media.
  • Le hachage perceptuel de l’audio ou de la vidéo : image_matches_reference ne lit que des images.