AI-Zusammenfassung-Backfill ist stecken geblieben, regeneriert immer wieder dasselbe Thema

[markschmucker (Mark S)]

Ich versuche, die letzten 90 Tage rückwirkend zu füllen. Es wurden erfolgreich etwa 500 von 2000 Themen rückwirkend gefüllt, aber jetzt stagniert der Fortschritt, da immer wieder dasselbe Thema verarbeitet wird, wenn der Job läuft (alle 5 Minuten). Ich habe keine Ahnung, warum – das Thema hat bereits eine gültige Zusammenfassung und keine neuen Beiträge in den letzten 12 Tagen. Die Tabelle „AI Audit Logs“ zeigt, dass jede Anfrage erfolgreich ist. Der Sidekiq-Status ist in Ordnung. Nichts Relevantes in /logs. Wie kann ich das debuggen?

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

Alle rohen Antwort-Payloads sehen gültig aus. Jede ist, wie erwartet, leicht unterschiedlich. Hier ist ein Beispiel (ich habe den größten Teil des Inhalts geschwärzt):

{
  "id": "msg_016C2dHZik2Miwe16pRHFe9z",
  "type": "message",
  "role": "assistant",
  "model": "claude-3-5-sonnet-20241022",
  "content": [
    {
      "type": "text",
      "text": "Der Franklin Lexington Private Markets Fund (FLEX) ist ein neuer Private-Equity-Sekundärfonds... [GESCHWÄRZT]"
    }
  ],
  "stop_reason": "end_turn",
  "stop_sequence": null,
  "usage": {
    "input_tokens": 13848,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0,
    "output_tokens": 416
  }
}

[markschmucker (Mark S)]

Ich weiß nicht, ob das ein Hinweis ist, aber bedeutet die 103, dass sie denkt, sie hätte nur bis Beitrag 103 zusammengefasst, und es gibt 108 Beiträge, also braucht sie eine neue Zusammenfassung?

Von SQL Helper generierte Abfrage:

-- [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
    -- Word count threshold
    t.word_count >= :min_word_count
    -- Age restriction
    AND t.updated_at > CURRENT_TIMESTAMP - (:max_age_days || ' DAYS')::INTERVAL
    -- Either no summary exists OR summary needs updating
    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

[markschmucker (Mark S)]

In diesem Thema gibt es 5 versteckte oder gelöschte Beiträge. 108-103=5. Ist es möglich, dass versteckte und gelöschte Beiträge nicht korrekt behandelt werden? Ja, 108 ist der höchste Beitrag, aber es werden nur 103 übergeben, sodass es ständig denkt, es gäbe 5 neue Beiträge zusammenzufassen.

@Falco @sam

[markschmucker (Mark S)]

Ich habe ein weiteres Thema, das ebenfalls die Zusammenfassung immer wieder neu generiert. Dieses Thema hat keine versteckten oder gelöschten Beiträge, ist aber angepinnt, was einen Beitrag “Dieses Thema wurde global angepinnt…” erstellt. Die maximale Anzahl der Beiträge ist also 8, aber der letzte Beitrag wird nicht wirklich übergeben?

[sam (Sam Saffron)]

@markschmucker

UPPER(ais.content_range) < t.highest_post_number + 1

Ja, ich glaube, du bist auf der richtigen Spur, @Roman

lib/summarization/strategies/topic_summary.rb

best_replies garantiert nicht, dass der letzte öffentliche Beitrag zu einem Thema enthalten ist. Wir sollten den letzten Beitrag bedingungslos hinzufügen, auch wenn wir best_replies auswählen.

[markschmucker (Mark S)]

Vielen Dank, dass Sie sich damit beschäftigt haben. Und nur um die Auswirkungen zu verdeutlichen: Es ist nicht nur die Ineffizienz, dieselbe Zusammenfassung wiederholt zu generieren – es stoppt den Backfill vollständig. Angenommen, Sie haben einen Backfill von 24 Themen pro Stunde eingestellt. Alle 5 Minuten versucht er 2 Themen. Schließlich haben beide Themen ein Problem – gelöschte Themen, ein angeheftetes Thema oder etwas anderes – und er versucht weiterhin alle 5 Minuten dieselben 2 Themen erneut. Er versucht nicht einmal, andere Themen zu bearbeiten.

[markschmucker (Mark S)]

@sam

.where("NOT hidden")

Benötigt es auch .where("NOT deleted")? Ich verstehe den Unterschied zwischen „hidden“ und „deleted“ nicht, aber ich habe sowohl „hidden“ als auch „deleted“ in meinem Problemthema.

[Roman (Roman Rizzi)]

Hallo Mark,

ich untersuche das gerade und versuche herauszufinden, was los ist. Was @sam angemerkt hat, stimmt – wenn best_replies den letzten Beitrag nicht einschließt, könnte der Job ins Stocken geraten. Ich bin dabei, eine Korrektur dafür abzuschließen und eine Notfallfunktion einzuführen, die den Job zu einem No-Op macht und einen Fehler protokolliert, falls es einen Fehler in der Abfrage gibt. Das ist nicht ideal und sollte nicht passieren, aber es ist besser, als immer wieder dieselbe Zusammenfassung zu generieren.

Andererseits betrachte ich das von dir geteilte Beispiel Franklin Lexington..., das ich für ein anderes Problem halte, weil:

1. Es hat bereits eine Zusammenfassung (149).
2. UPPER(ais.content_range) < t.highest_post_number + 1 sollte FALSE sein. UPPER sollte 109 zurückgeben, was gleich highest_post_number + 1 ist.
   Das Ende des Intervalls content_range müsste niedriger sein, damit der Job deswegen ins Stocken gerät. Wir kümmern uns nicht wirklich um versteckte oder gelöschte Beiträge, wenn wir entscheiden, ob eine Zusammenfassung veraltet ist; wir wollen nur vermeiden, diese zusammenzufassen.
   Hast du ai_summary_gists_enabled aktiviert? Wenn ja, kannst du bestätigen, dass du zwei Zusammenfassungen für dieses Thema hast, eine mit dem Typ 0 und eine mit dem Typ 1? Und was ist der Wert in der Spalte feature_name in der ai_api_audit_logs-Abfrage, die du geteilt hast?

Ich halte dich über meine Erkenntnisse auf dem Laufenden.

[markschmucker (Mark S)]

Vielen Dank, dass Sie sich damit befassen. Gerne stelle ich Fehlerprotokolle bereit, wenn Ihre Korrektur bereit ist.

@Roman

Haben Sie ai_summary_gists_enabled aktiviert?

https://meta.discourse.org/t/summarize-gists/340269/3

Ich sehe nicht, wie ich es aktivieren kann, daher glaube ich nicht, dass es aktiviert ist.

@Roman

Was ist der Wert in der Spalte feature_name?

“summarize”

[Roman (Roman Rizzi)]

Dies wird die Warteschlange entlasten und den Job widerstandsfähiger gegen solche Probleme machen:

FIX: Make summaries backfill job more resilient.

Könnten Sie mir bitte mitteilen, wie die Dinge nach der Aktualisierung Ihrer Website aussehen?

[markschmucker (Mark S)]

Es werden keine Zusammenfassungen mehr für Themen generiert, die bereits eine Zusammenfassung hatten, das ist also gut.

Aber es werden viele Themen nicht zusammengefasst, auch wenn es neue Beiträge gibt, wegen:

How Does Regenerating Summaries Work?

Found the problem. It’s comparing ai summary backfill topic max age days to topic.created_at, not updated_at. I think this should be changed to updated_at- I have many very active topics created two years ago which still get new posts every week, but if I use a max age of 90 days or even a year, those topics will not get summarized. Please consider changing this. .where("topics.created_at > current_timestamp - INTERVAL '#{max_age_days.to_i} DAY'")

Daher denkt Backfill, dass es fertig ist, aber vielleicht haben 75 % der neuesten Themen keine Zusammenfassung, obwohl sie neue Beiträge haben, nur weil sie zufällig vor mehr als 90 Tagen erstellt wurden. Ich bin sicher, das ist nicht beabsichtigt. Bitte ändern Sie es oder helfen Sie mir zu verstehen, warum.

[markschmucker (Mark S)]

@Roman

Könnten Sie mir bitte mitteilen, wie die Dinge nach der Aktualisierung Ihrer Website aussehen?

Ich habe das KI-Repository geforkt, um created_at in updated_at zu ändern und fortzufahren. Ich freue mich, Ihnen mitteilen zu können, dass es erfolgreich alle 400+ Themen zusammengefasst hat, die ich zusammenfassen wollte. Einige sind beim ersten Backfill-Durchlauf fehlgeschlagen, möglicherweise weil wir für diese Minute das Kontingent überschritten hatten, aber es hat diese beim zweiten Durchlauf erfolgreich zusammengefasst.

Insbesondere das Thema Franklin Lexington hat jetzt eine Zusammenfassung.

Nochmals, das Backfilling wird aufgrund des created_at-Problems für andere noch nicht gut funktionieren.

[sam (Sam Saffron)]

@markschmucker

Nochmal, das Auffüllen wird wegen des created_at-Problems für andere noch nicht gut funktionieren.

Ja, da stimme ich zu, wir müssen uns updated_at oder last_posted_at ansehen, was etwas weniger radikal ist.

Letztendlich sollten wir uns beim Auffüllen auf die Inhaltsänderung stützen.

[markschmucker (Mark S)]

@sam

updated_at oder last_posted_at

Wenn der Unterschied Bearbeitungen sind, würde ich dafür stimmen, bei Bearbeitungen neu zu generieren. Wir haben ein Wiki als ersten Beitrag jedes Themas, das Mitglieder mit wichtigen Informationen bearbeiten können, die die Zusammenfassung beeinflussen könnten.

Wenn Sie sich jedoch dagegen entscheiden, kann ich meine Gabel weiter betreiben.

[Roman (Roman Rizzi)]

Entschuldigen Sie die Funkstille. Ich werde versuchen, bald Zeit zu finden, um daran zu arbeiten.

[Roman (Roman Rizzi)]

Das wurde heute Morgen zusammengeführt:

FEATURE: Changes to summaries' outdated logic.

Der Backfill-Job verwendet jetzt last_posted_at anstelle von created_at. Ich habe auch Änderungen an der Logik vorgenommen, um festzustellen, ob eine Zusammenfassung veraltet ist, indem geprüft wird, ob das last_revised_at eines der Beiträge neuer als die Zusammenfassung ist, um Bearbeitungen zu berücksichtigen.