Estou tentando preencher os últimos 90 dias. Ele preencheu com sucesso cerca de 500 de 2000 tópicos, mas agora o progresso está estagnado porque ele continua processando o mesmo tópico toda vez que o trabalho é executado (a cada 5 minutos). Não tenho ideia do porquê - o tópico já tem um resumo válido e não tem novas postagens nos últimos 12 dias. A tabela AI Audit Logs mostra que cada solicitação é bem-sucedida. O status do Sidekiq está OK. Nada relevante em /logs. Como depurar isso?
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
Todos os payloads de resposta brutos parecem válidos. Cada um é ligeiramente diferente, como esperado. Aqui está um exemplo (eu ocultei a maior parte do texto do conteúdo):
{
"id": "msg_016C2dHZik2Miwe16pRHFe9z",
"type": "message",
"role": "assistant",
"model": "claude-3-5-sonnet-20241022",
"content": [
{
"type": "text",
"text": "O Franklin Lexington Private Markets Fund (FLEX) é um novo fundo de secondaries de private equity... [OCULTADO]"
}
],
"stop_reason": "end_turn",
"stop_sequence": null,
"usage": {
"input_tokens": 13848,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 0,
"output_tokens": 416
}
}
Não sei se isso é uma pista, mas o 103 significa que ele acha que resumiu apenas até a postagem 103, e há 108 postagens, então ele precisa de um novo resumo?
-- [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
-- Limiar de contagem de palavras
t.word_count >= :min_word_count
-- Restrição de idade
AND t.updated_at > CURRENT_TIMESTAMP - (:max_age_days || ' DIAS')::INTERVAL
-- Ou não existe resumo OU o resumo precisa ser atualizado
AND (
ais.id IS NULL OR
(
UPPER(ais.content_range) < t.highest_post_number + 1
AND ais.created_at < (CURRENT_TIMESTAMP - INTERVAL '5 minutos')
)
)
)
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
Existem 5 posts ocultos ou excluídos neste tópico. 108-103=5. É possível que não esteja a lidar corretamente com posts ocultos e excluídos? Sim, 108 é o post mais alto, mas apenas 103 são sempre passados, então ele continuamente pensa que há 5 novos posts para resumir.
Tenho outro tópico que também continua regenerando o resumo. Esse tópico não tem posts ocultos ou excluídos, mas está fixado, o que cria um post “este tópico foi fixado globalmente…”. Portanto, o post máximo é 8, mas esse último post não é realmente passado?
best_replies não garante a inclusão da última postagem pública em um tópico. Devemos adicionar a última postagem incondicionalmente, mesmo ao selecionar best_replies.
Obrigado por investigar. E apenas para esclarecer o impacto, não é apenas a ineficiência de regenerar o mesmo resumo repetidamente - isso interrompe completamente o backfill. Digamos que você tenha o backfill definido como 24 tópicos por hora. A cada 5 minutos, ele tenta 2 tópicos. Eventualmente, ambos os tópicos apresentam um problema - tópicos excluídos ou um tópico fixado ou algo mais - e ele continua tentando os mesmos 2 tópicos a cada 5 minutos. Ele nem sequer tenta outros tópicos.
Precisa também de .where("NOT deleted")? Não entendo a diferença entre oculto (hidden) e excluído (deleted), mas tenho ambos ocultos e excluídos no tópico do meu problema.
Estou investigando isso e tentando descobrir o que está acontecendo. O que o @sam apontou é verdade — a exclusão de best_replies do último post poderia fazer o job travar. Estou prestes a finalizar uma correção para isso e introduzir um mecanismo de segurança para transformar o job em um no-op (não fazer nada) e registrar um erro se houver um bug na consulta. Isso não é o ideal e não deveria acontecer, mas é melhor do que regenerar o mesmo resumo repetidamente.
Por outro lado, estou analisando o exemplo Franklin Lexington... que você compartilhou, o qual suspeito ser um problema diferente porque:
Já possui um resumo (149).
UPPER(ais.content_range) < t.highest_post_number + 1 deveria ser FALSE. UPPER deveria retornar 109, que é igual a highest_post_number + 1.
O final do intervalo content_range precisaria ser menor para que o job travasse por causa disso. Nós não nos importamos realmente com posts ocultos ou excluídos ao decidir se um resumo está desatualizado; nós apenas queremos evitar resumir esses.
Você tem o ai_summary_gists_enabled ativado? Se sim, você pode confirmar que tem dois resumos para esse tópico, um com o tipo 0 e outro com o tipo 1? Além disso, na consulta ai_api_audit_logs que você compartilhou, qual é o valor na coluna feature_name?
Manterei você atualizado sobre o que eu encontrar.
Não está mais regenerando resumos para tópicos que já tinham um resumo, o que é bom.
Mas não está resumindo muitos tópicos, mesmo quando há novas postagens, por causa de:
Portanto, o backfill pensa que terminou, mas talvez 75% dos tópicos mais recentes não tenham um resumo, mesmo que tenham novas postagens, apenas porque foram criados há mais de 90 dias. Tenho certeza de que essa não é a intenção. Por favor, mude isso ou me ajude a entender o porquê.
Eu fiz um fork do repositório de IA para poder alterar created_at para updated_at e seguir em frente. Tenho o prazer de informar que ele resumiu com sucesso todos os mais de 400 tópicos que eu esperava que ele resumisse. Alguns falharam na primeira passagem de preenchimento, possivelmente porque estávamos acima da cota naquele minuto, mas ele resumiu com sucesso aqueles na segunda passagem.
Em particular, o tópico Franklin Lexington agora tem um resumo.
Novamente, o preenchimento não funcionará bem ainda para outros, por causa do problema com created_at.
Se a diferença for edições, eu votaria para regenerar em edições. Temos uma wiki como o primeiro post de cada tópico que os membros editam com informações críticas que podem afetar o resumo.
Mas se você optar por não fazer isso, posso continuar executando meu fork.
O trabalho de preenchimento agora usa last_posted_at em vez de created_at. Também fiz alterações na lógica para determinar se um resumo está desatualizado, verificando se o last_revised_at de alguma das postagens é mais recente que o resumo, para levar em conta as edições.
