Bibliothèque de lecture
Évaluez si une fonction de recherche aide son lecteur
Évaluez une recherche sur la quantification avec une tâche de lecture précise : décisions observables, limites des réponses, parcours contrôlés et besoins non satisfaits documentés.
Nommez la décision du lecteur
Partez d'une décision plus précise que « trouver des informations utiles sur Reddit ». Dans un exercice LocalLLaMA proposé, demandez à un développeur de modèles de trouver une discussion historique indiquant les conditions d'une mesure de mémoire liée à la quantification, ou d'expliquer pourquoi les données disponibles ne suffisent pas. La seconde issue compte : une question honnêtement laissée ouverte peut être plus utile qu'une réponse assurée fondée sur un contexte manquant. Il s'agit d'une tâche d'évaluation suggérée, pas de la preuve qu'une discussion correspondante existe ni que la fonction actuelle a permis à de vrais utilisateurs de la réaliser.
Définissez la réussite par ce que l'interface peut soutenir. Le lecteur sait-il identifier les conditions envoyées, examiner le texte source disponible, distinguer sa propre note de ce texte et décider d'affiner ou d'arrêter ? Ne prenez pas pour critère d'acceptation une étude complète de Reddit ou la meilleure réponse à l'échelle mondiale. Le service est une archive historique indépendante, avec une récupération bornée, des champs facultatifs et aucune garantie d'exhaustivité. Une requête HTTP réussie atteste le transport et la récupération, pas que la question de recherche du lecteur a trouvé sa réponse.
Choisissez des observations vérifiables
Notez ce qui se passe pendant la tâche : quels filtres le lecteur reconnaît, quelle condition il modifie, quel texte appuie sa décision et où il hésite. Distinguez une observation de l'interface de son explication déduite après coup. Si un titre lui paraît prometteur, demandez quel contexte du corps le confirme plutôt que de compter le clic comme une réponse correcte. Les enregistrements arrivent dans l'ordre _doc de l'archive, pas par pertinence, date ou score. Le premier résultat affiché est une occasion de lecture, pas une recommandation à valider automatiquement.
Employez des mesures que les éléments disponibles permettent de justifier. Une séance réelle peut documenter les étapes, les requêtes et les problèmes rencontrés, mais cette proposition ne fournit aucun chiffre de référence. Des affirmations de précision ou de rappel exigent un jugement de pertinence défini et un ensemble de référence adapté ; quelques pages récupérées n'établissent pas le rappel à l'échelle de l'archive. Un total de pagination exact ou exprimé comme borne inférieure ne dit rien non plus de la qualité de la réponse. Chronométrer une requête décrit cette observation, pas une garantie de performance. Conservez ces limites à côté des mesures que vous recueillerez.
Parcourez une petite tâche de bout en bout
Commencez par la requête proposée /v1/search?q=quantization&subreddit=LocalLLaMA&limit=3&page=1. Le backend de l'appelant fournit la clé du tenant ; le participant voit la question et les conditions envoyées. Demandez-lui d'examiner une référence renvoyée et d'expliquer ce qui est présent ou manque. Si la mémoire reste le sujet, laissez-le ajouter volontairement le mot memory. Expliquez AND dans un champ : les termes analysés doivent correspondre dans un même champ title ou text. Ne promettez ni expressions exactes, ni correction de fautes, ni compréhension sémantique, ni conversation complète, que le contrat ne fournit pas.
Utilisez des cas locaux contrôlés pour examiner des situations qu'une réponse disponible ne couvrira peut-être pas : titre absent, contexte manquant, succès vide, erreur HTTP ou réponse qui n'arrive jamais. Signalez leur caractère synthétique et consignez tout parcours réellement effectué séparément de ce plan. Vérifiez si le participant retrouve la requête envoyée et choisit une prochaine action. Pour poursuivre, respectez pagination.has_more et la limite de 100 pages ; une dernière fenêtre pleine ne constitue pas une étude complète. Chaque requête supplémentaire réussie, même vide, consomme un crédit.
Documentez les besoins non satisfaits
Formulez chaque constat avec une observation précise et sa conséquence. Une séance future pourrait, par exemple, montrer qu'un lecteur prend une borne inférieure pour un total exact ou ne distingue pas une continuation en échec d'un résultat vide. Ce sont des exemples de constats possibles, pas les résultats d'une étude déjà menée. Séparez les modifications d'interface réalisables des preuves absentes que vous ne pouvez pas fabriquer. Des libellés plus clairs peuvent aider face à une date manquante ; ils ne peuvent ni restituer une source indisponible ni certifier les conditions d'une expérience non documentée.
Limitez l'évaluation aux participants, tâches et cas réellement utilisés. Un petit parcours ne produit ni classement des problèmes d'une communauté ni estimation de leur fréquence. Consignez les besoins non résolus à côté des étapes réussies et précisez les éléments nécessaires à une vérification ultérieure. Ne rapportez l'accessibilité ou le comportement propre à un appareil qu'après les avoir testés. La poursuite du développement doit se fonder sur ce que les lecteurs montrent qu'ils comprennent et savent faire, en conservant l'incertitude sur la couverture historique, les données non vues et les conclusions que le service de recherche ne peut établir.
