Så bygger du en sökmotor för det som sägs i YouTube-videor

Problemet det löser

Stora videobibliotek är i praktiken omöjliga att söka i. Fans spolar igenom timmar av material för att hitta ett ögonblick de halvt minns, kursdeltagare ser om hela lektioner för att hitta en enda förklaring, och företag förlorar kunskap som ligger begravd i inspelade föredrag. Genom att indexera transkript med tidsstämplar blir varje bibliotek sökbart som ett dokument, med resultat som hoppar direkt till rätt ögonblick.

Vad den första versionen bör innehålla

• ■Fras- och nyckelordssökning i alla videor i en kanal eller spellista
• ■Resultat som visar den matchande meningen med en länk till exakt tidsstämpel
• ■Semantisk sökning så att "hur prissätter jag min produkt" även hittar "sätta dina priser"
• ■Filter för datum, video och talare
• ■Automatisk indexering av nya uppladdningar

Så bygger du det, steg för steg

1. 01

   Samla in videolistan

   Anropa /channels/resolve eller /playlists/resolve med kanalens handle eller spellistans URL för att få alla video-ID:n och titlar.

2. 02

   Hämta transkript i bulk

   Skicka ID:na till /batch med format.timestamp och format.paragraphs aktiverade. Stora batcher körs asynkront, så polla /batch/{batch_id} eller använd en webhook.

3. 03

   Indexera segmenten

   Lagra varje stycke med dess video-ID och starttid. Fulltextsökning i Postgres räcker för nyckelordssökning; lägg till embeddings i pgvector eller en vektordatabas för betydelsebaserad sökning.

4. 04

   Bygg sökgränssnittet

   Returnera de bästa träffarna med omgivande text och en länk i formatet youtube.com/watch?v=ID&t=SEKUNDER så att användarna hamnar på exakt rätt ögonblick.

5. 05

   Håll det aktuellt

   Kör ett schemalagt jobb som slår upp kanalen igen, hittar nya video-ID:n och transkriberar bara dem.

Startkod

Den här idén bygger på mönstret "Recept 3: Läs in en hel spellista i en kunskapsbas". Byt till dina egna kanaler, promptar och lagring.

import requests

API = "https://www.youtubetranscript.dev/api/v2"
HEADERS = {"Authorization": "Bearer yt_sk_live_YOUR_KEY"}

playlist = requests.post(f"{API}/playlists/resolve", headers=HEADERS,
                         json={"playlist_url": "https://www.youtube.com/playlist?list=PLAYLIST_ID",
                               "limit": 100}).json()

ids = [v["video_id"] for v in playlist["items"]]
batch = requests.post(f"{API}/batch", headers=HEADERS, json={
    "video_ids": ids,
    "format": {"timestamp": True, "paragraphs": True},
}).json()

# Large batches run async: poll GET /batch/{batch_id} until status is "completed"
for r in batch.get("results", []):
    if r["status"] == "completed":
        for p in r["data"]["transcript"].get("paragraphs") or []:
            store(video_id=r["video_id"], start=p["start"], text=p["text"])  # your vector DB

Därför är det värt att bygga

Sälj till den som äger biblioteket snarare än till tittaren: poddnätverk, kursplattformar och företag med interna videoarkiv betalar gärna en månadsavgift för sökning som håller kvar publiken. För fancommunityn fungerar även en gratis publik sökning med en betald nivå för bevakningar eller API-åtkomst.

Misstag att undvika

• ✕Att indexera hela transkript som ett enda dokument: sökresultaten blir oanvändbara utan tidsstämplar på styckenivå.
• ✕Att transkribera om hela kanalen vid varje uppdatering i stället för att hålla koll på vilka video-ID:n du redan har bearbetat.
• ✕Att bara förlita sig på exakt nyckelordsmatchning: talat språk är rörigt, så lägg till semantisk sökning tidigt.

Frågor om den här idén