AskTNT

Warum ich das gebaut habe

Der TWUP-Podcast hat über 300 Folgen zu Training, Therapie, Schlaf und Ernährung. Das Wissen steckt in Stunden von Audio. Wenn du wissen willst, was die beiden zu Periodisierung oder Protein sagen, musst du dich erinnern, in welcher Folge das war. Oder alles noch mal hören.

Ich trainiere seit Jahren, bin selbst YPSI-Trainer mit A-Lizenz und höre den Podcast seit Langem. Ich wollte eine Frage stellen und die Stelle finden, an der darüber gesprochen wird. Mit Zeitstempel, nicht mit einer erfundenen Zusammenfassung. AskTNT ist aktuell mein eigenes Projekt.

Was es macht

• Du stellst eine Frage, AskTNT durchsucht die Transkripte aller Folgen und belegt die Antwort mit den passenden Stellen.
• Jede Folge hat eine eigene Seite mit Themen, Kernaussagen, Audio und einem Transkript, in dem das gesprochene Wort beim Abspielen mitläuft.
• Themenseiten verbinden Aussagen aus dem Podcast mit ausgewählten Studien. Neue Studien werden zusammengefasst und mit passenden Folgen verknüpft.
• Neue Folgen kommen jede Woche automatisch dazu. Wer will, bekommt eine Mail, wenn zu seinem Thema etwas Neues erscheint.
• Seit September 2026 gibt es einen öffentlichen MCP-Connector. Damit durchsuchst du das Archiv direkt aus Claude oder anderen Assistenten, mit deinem eigenen Modell.

Technische Entscheidungen

Eine Rails-App, eine SQLite-Datei. Suche, Vektoren (sqlite-vec), Jobs, Cache, alles in SQLite. Kein separater Vektor-Store, keine Queue als eigener Dienst. Für ein Archiv dieser Größe reicht das locker und ist leicht zu betreiben.

Transkripte, die einen Absturz überleben. Lange Folgen werden in Fünf-Minuten-Stücke mit kurzer Überlappung zerlegt. Jedes Stück ist ein eigener Job, der Fortschritt liegt in der Datenbank. Wenn mitten in der Arbeit deployt wird, macht der Job beim nächsten Stück weiter statt von vorn. Sprecher-Transkripte werden erst veröffentlicht, wenn ein Mensch jedem Sprecher einen Namen gegeben hat.

Modelle per Benchmark statt Bauchgefühl. Für die Sprechertrennung habe ich mehrere Anbieter gegen handgeprüfte Referenzstellen laufen lassen: schnelle Wechsel, lange Monologe, Übergänge zwischen den Stücken. Alle Modelle laufen über OpenRouter und RubyLLM und sind austauschbar.

Zwei Teile davon habe ich als eigene Bausteine herausgelöst: eine Rails-Engine für lange Transkriptionen und ein Gem, das RSS, Taddy und Podcast Index auf ein einheitliches Episodenformat bringt.

Aus den Sessions

Anfang September lief der einzige wöchentliche Job, der neue Folgen verarbeitet, einfach nicht durch. Meine Nachricht an den Agenten: “thats stupid and it should work cant you properly test this its one weekly job”. Die Diagnose lief lesend auf dem Server: Der Scheduler hatte gefeuert, der Job ist an einem doppelten Eintrag im Feed gescheitert, eine ältere Folge tauchte zweimal auf. Fix, Deploy, Job einmal von Hand angestoßen.

Der MCP-Connector entstand Ende September aus einer Frage: Gibt es ein Muster, mit dem Leute die Wissensbasis nutzen, aber ihre eigene KI mitbringen? Das Modell bezahlt dann der Nutzer, bei mir bleibt im Kern das Embedding der Suchanfrage. Am selben Tag war der Connector live.