J’essaie de rattraper les 90 derniers jours. J’ai réussi à rattraper environ 500 sujets sur 2000, mais la progression est maintenant bloquée car le même sujet est traité à chaque exécution du travail (toutes les 5 minutes). Je ne sais pas pourquoi : le sujet a déjà un résumé valide et n’a pas de nouveaux messages depuis 12 jours. La table AI Audit Logs montre que chaque requête est réussie. Le statut de Sidekiq est OK. Rien de pertinent dans /logs. Comment déboguer cela ?
SELECT request_tokens,
response_tokens,
raw_response_payload,
topic_id,
created_at AS summary_created_at,
language_model
FROM ai_api_audit_logs
WHERE raw_request_payload LIKE '%Franklin Lexington%'
ORDER BY created_at DESC
LIMIT 40
Tous les payloads de réponse bruts semblent valides. Chacun est légèrement différent comme prévu. Voici un exemple (j’ai masqué la majeure partie du contenu textuel) :
{
"id": "msg_016C2dHZik2Miwe16pRHFe9z",
"type": "message",
"role": "assistant",
"model": "claude-3-5-sonnet-20241022",
"content": [
{
"type": "text",
"text": "Le Franklin Lexington Private Markets Fund (FLEX) est un nouveau fonds de second marché de capital-investissement... [MASQUÉ]"
}
],
"stop_reason": "end_turn",
"stop_sequence": null,
"usage": {
"input_tokens": 13848,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 0,
"output_tokens": 416
}
}
Je ne sais pas si c’est un indice, mais est-ce que 103 signifie qu’il pense n’avoir résumé que jusqu’au message 103, et qu’il y a 108 messages, donc il a besoin d’un nouveau résumé ?
Il y a 5 messages cachés ou supprimés dans ce sujet. 108-103=5. Est-il possible que cela ne gère pas correctement les messages cachés et supprimés ? Oui, 108 est le message le plus élevé, mais seulement 103 sont jamais transmis, il pense donc continuellement qu’il y a 5 nouveaux messages à résumer.
J’ai un autre sujet qui continue également de régénérer le résumé. Ce sujet n’a pas de messages cachés ou supprimés, mais il est épinglé, ce qui crée un message “ce sujet a été épinglé globalement…”. Donc, le message maximum est de 8, mais ce dernier message n’est pas vraiment transmis ?
best_replies n’est pas garanti d’inclure le dernier message public d’un sujet. Nous devrions ajouter le dernier message inconditionnellement, même lors de la sélection de best_replies.
Merci d’avoir examiné la question. Et pour clarifier l’impact, il ne s’agit pas seulement de l’inefficacité de la régénération du même résumé à plusieurs reprises, cela arrête complètement le remplissage. Supposons que vous ayez défini le remplissage sur 24 sujets par heure. Toutes les 5 minutes, il essaie 2 sujets. Finalement, les deux sujets rencontrent un problème - sujets supprimés ou sujet épinglé ou autre chose - et il continue de réessayer les mêmes 2 sujets toutes les 5 minutes. Il n’essaie même pas d’autres sujets.
Doit-il aussi avoir .where("NOT deleted") ? Je ne comprends pas la différence entre caché et supprimé, mais j’ai à la fois des éléments cachés et supprimés dans mon sujet problématique.
Je suis actuellement en train d’examiner la situation et d’essayer de comprendre ce qui se passe. Ce que @sam a souligné est vrai : le fait que best_replies n’inclue pas le dernier message pourrait entraîner le blocage du job. Je suis sur le point de terminer une correction pour cela et d’introduire une mesure de sécurité pour transformer le job en une opération nulle et enregistrer une erreur s’il y a un bug dans la requête. Ce n’est pas idéal et cela ne devrait pas arriver, mais c’est mieux que de régénérer le même résumé encore et encore.
D’un autre côté, j’examine l’exemple Franklin Lexington... que vous avez partagé, qui, je le soupçonne, est un problème différent car :
Il a déjà un résumé (149).
UPPER(ais.content_range) < t.highest_post_number + 1 devrait être FALSE. UPPER devrait retourner 109, ce qui est égal à highest_post_number + 1.
La fin de l’intervalle content_range devrait être plus basse pour que le job soit bloqué à cause de cela. Nous ne nous soucions pas vraiment des messages cachés ou supprimés pour décider si un résumé est obsolète ; nous voulons seulement éviter de résumer ceux-là.
Avez-vous activé ai_summary_gists_enabled ? Si oui, pouvez-vous confirmer que vous avez deux résumés pour ce sujet, un de type 0 et un de type 1 ? De plus, dans la requête ai_api_audit_logs que vous avez partagée, quelle est la valeur dans la colonne feature_name ?
Il ne régénère plus les résumés pour les sujets qui en avaient déjà un, ce qui est une bonne chose.
Cependant, il ne résume pas de nombreux sujets, même lorsqu’il y a de nouveaux messages, à cause de :
Ainsi, le remplissage pense qu’il a terminé, mais peut-être que 75 % des sujets les plus récents n’ont pas de résumé, même s’ils ont de nouveaux messages, simplement parce qu’ils ont été créés il y a plus de 90 jours. Je suis sûr que ce n’est pas l’intention. Veuillez le changer ou m’aider à comprendre pourquoi.
J’ai forké le dépôt d’IA afin de pouvoir changer created_at en updated_at et avancer. Je suis heureux de signaler que cela a réussi à résumer les plus de 400 sujets que je m’attendais à ce qu’il résume. Certains ont échoué lors de la première passe de remplissage, peut-être parce que nous étions hors quota pour cette minute, mais cela a réussi à les résumer lors de la seconde passe.
En particulier, le sujet Franklin Lexington a maintenant un résumé.
Encore une fois, le remplissage ne fonctionnera pas bien pour les autres pour le moment, en raison du problème created_at.
Si la différence concerne les modifications, je voterais pour régénérer lors des modifications. Nous avons un wiki comme premier message de chaque sujet que les membres modifient par wiki avec des informations critiques qui pourraient affecter le résumé.
Mais si vous choisissez de ne pas le faire, je peux continuer à exécuter ma version.
Le travail de remplissage utilise maintenant last_posted_at au lieu de created_at. J’ai également modifié la logique pour déterminer si un résumé est obsolète en vérifiant si le last_revised_at d’un des messages est plus récent que le résumé, afin de prendre en compte les modifications.
