Sto cercando di riempire i dati degli ultimi 90 giorni. Sono stati riempiti con successo circa 500 argomenti su 2000, ma ora il progresso si è bloccato perché continua a elaborare lo stesso argomento ogni volta che il processo viene eseguito (ogni 5 minuti). Non ho idea del perché: l’argomento ha già un riepilogo valido e non ha nuovi post negli ultimi 12 giorni. La tabella AI Audit Logs mostra che ogni richiesta ha successo. Lo stato di Sidekiq è OK. Non c’è nulla di rilevante in /logs. Come posso eseguire il debug di questo problema?
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
Tutti i payload delle risposte grezze sembrano validi. Ognuno è leggermente diverso come previsto. Ecco un esempio (ho oscurato la maggior parte del testo del contenuto):
{
"id": "msg_016C2dHZik2Miwe16pRHFe9z",
"type": "message",
"role": "assistant",
"model": "claude-3-5-sonnet-20241022",
"content": [
{
"type": "text",
"text": "Il Franklin Lexington Private Markets Fund (FLEX) è un nuovo fondo di secondizzazione di private equity... [OSCURATO]"
}
],
"stop_reason": "end_turn",
"stop_sequence": null,
"usage": {
"input_tokens": 13848,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 0,
"output_tokens": 416
}
}
Non so se questo sia un indizio, ma il 103 significa che pensa di aver riassunto solo fino al post 103 e ci sono 108 post, quindi ha bisogno di un nuovo riassunto?
-- [params]
-- integer :summary_type = 0
-- integer :max_age_days = 30
-- integer :min_word_count = 100
WITH topic_candidates AS (
SELECT
t.id as topic_id,
t.title,
t.created_at,
t.word_count,
t.highest_post_number,
t.last_posted_at,
ais.id as summary_id,
ais.content_range,
ais.created_at as summary_created_at,
UPPER(ais.content_range) as content_range_upper
FROM topics t
LEFT OUTER JOIN ai_summaries ais ON
t.id = ais.target_id AND
ais.target_type = 'Topic' AND
ais.summary_type = :summary_type
WHERE
-- Soglia del conteggio delle parole
t.word_count >= :min_word_count
-- Restrizione di età
AND t.updated_at > CURRENT_TIMESTAMP - (:max_age_days || ' DAYS')::INTERVAL
-- O non esiste alcun riassunto O il riassunto necessita di aggiornamento
AND (
ais.id IS NULL OR
(
UPPER(ais.content_range) < t.highest_post_number + 1
AND ais.created_at < (CURRENT_TIMESTAMP - INTERVAL '5 minutes')
)
)
)
SELECT
topic_id,
title,
word_count,
highest_post_number,
created_at,
last_posted_at,
summary_id,
content_range,
summary_created_at,
content_range_upper
FROM topic_candidates
ORDER BY summary_created_at DESC NULLS FIRST, last_posted_at DESC
Ci sono 5 post nascosti o eliminati in questo argomento. 108-103=5. È possibile che non gestisca correttamente i post nascosti ed eliminati? Sì, 108 è il post più alto, ma ne vengono sempre passati solo 103, quindi continua a pensare che ci siano 5 nuovi post da riassumere.
Ho un altro argomento che continua a rigenerare il riepilogo. Quell’argomento non ha post nascosti o eliminati, ma è bloccato, il che crea un post “questo argomento è stato bloccato a livello globale…”. Quindi il post massimo è 8, ma l’ultimo post non viene effettivamente passato?
best_replies non è garantito che includa l’ultimo post pubblico su un argomento. Dovremmo aggiungere l’ultimo post incondizionatamente anche quando si scelgono best_replies.
Grazie per aver approfondito la questione. E solo per chiarire l’impatto, non si tratta solo dell’inefficienza di rigenerare continuamente lo stesso riassunto, ma blocca completamente il backfill. Supponiamo che il backfill sia impostato su 24 argomenti all’ora. Ogni 5 minuti prova 2 argomenti. Alla fine entrambi gli argomenti hanno un problema: argomenti eliminati o un argomento bloccato o qualcos’altro, e continua a riprovare gli stessi 2 argomenti ogni 5 minuti. Non prova nemmeno altri argomenti.
Serve anche .where("NOT deleted")? Non capisco la differenza tra nascosto ed eliminato, ma ho sia nascosto che eliminato nell’argomento del mio problema.
Sto attualmente esaminando la questione e cercando di capire cosa sta succedendo. Quello che @sam ha sottolineato è vero: il fatto che best_replies non includa l’ultimo post potrebbe causare il blocco del job. Sto per terminare una correzione per questo e introdurre un meccanismo di sicurezza per trasformare il job in un’operazione nulla e registrare un errore se c’è un bug nella query. Questo non è l’ideale e non dovrebbe accadere, ma è meglio che rigenerare lo stesso riassunto più e più volte.
D’altra parte, sto esaminando l’esempio Franklin Lexington... che hai condiviso, che sospetto sia un problema diverso perché:
Ha già un riassunto (149).
UPPER(ais.content_range) < t.highest_post_number + 1 dovrebbe essere FALSE. UPPER dovrebbe restituire 109, che è uguale a highest_post_number + 1.
La fine dell’intervallo content_range dovrebbe essere inferiore affinché il job si blocchi a causa di ciò. Non ci interessano davvero i post nascosti o eliminati quando decidiamo se un riassunto è obsoleto; vogliamo solo evitare di riassumerli.
Hai abilitato ai_summary_gists_enabled? Se sì, puoi confermare che hai due riassunti per quell’argomento, uno di tipo 0 e uno di tipo 1? Inoltre, nella query ai_api_audit_logs che hai condiviso, qual è il valore nella colonna feature_name?
Non rigenera più i riassunti per gli argomenti che ne avevano già uno, quindi questo è un bene.
Tuttavia, non riassume molti argomenti, anche quando ci sono nuovi post, a causa di:
Quindi il backfill pensa di aver finito, ma forse il 75% degli argomenti più recenti non ha un riassunto, anche se hanno nuovi post, solo perché sono stati creati più di 90 giorni fa. Sono sicuro che non è l’intento. Per favore, cambialo o aiutami a capire perché.
Ho eseguito il fork della repository ai in modo da poter cambiare created_at in updated_at e andare avanti. Sono lieto di riferire che ha riassunto con successo tutti gli oltre 400 argomenti che mi aspettavo riassumesse. Alcuni sono falliti nel primo passaggio di riempimento, forse perché eravamo oltre la quota per quel minuto, ma li ha riassunti con successo nel secondo passaggio.
In particolare, l’argomento Franklin Lexington ora ha un riassunto.
Ancora una volta, il riempimento non funzionerà bene per altri, a causa del problema created_at.
Se la differenza è dovuta a modifiche, voterei per rigenerare in caso di modifiche. Abbiamo una wiki come primo post di ogni argomento che i membri modificano con informazioni critiche che potrebbero influire sul riepilogo.
Ma se scegli di non farlo, posso continuare a eseguire il mio fork.
Il processo di backfill ora utilizza last_posted_at invece di created_at. Ho anche apportato modifiche alla logica per determinare se un riepilogo è obsoleto verificando se il last_revised_at di uno dei post è più recente del riepilogo, per tenere conto delle modifiche.
