particle_podcast_search_transcripts

pro.particle/particle-pro · Verify this server

Search the podcast catalog by what is said in episodes — by meaning (`semantic_search`), by exact phrase (`keyword_search`), or both at once (hybrid ranking). This is THE way to retrieve relevant dialogue, segments, and clips: each result is one segment of one episode with bounded transcript windows pinpointing the highest-relevance lines, plus any highlight clips that overlap the segment inline on the match. Segments partition an episode's transcript — where start_line and end_line are present, every spoken line belongs to exactly one segment and one segment's end_line + 1 is the next one's start_line. They are contiguous in transcript lines, not in wall-clock seconds: the seconds between one segment's end_seconds and the next's start_seconds contain no transcribed speech. These matches do not carry the line ranges themselves — fetch them with `particle_podcast_get_episode` and `include: ["segments"]`, where their absence marks an episode segmented by an earlier version, a small share of which do leave lines uncovered. Clips are sparse, engagement-ranked highlights that overlap some segments. There is no separate clip-search tool — relevant clips arrive on these matches, and a known episode's full clip list is `particle_podcast_get_episode` with `include: ["clips"]`. A match window defaults to one line of context around each matched line; raise `context` to widen windows in place instead of fetching the full transcript. Use this for "find dialogue *about* a topic". For "every line *naming* a person or company" use `particle_podcast_find_mentions` instead — `person_slug` and `company_slug` here narrow ranked results, they don't drive the ranking. **Choosing your query.** At least one of `semantic_search` or `keyword_search` is required, and they do different jobs: - `semantic_search` carries the *idea*. Write it as a sentence describing what should be discussed, in the vocabulary a speaker would use. It is paraphrase-tolerant, so it finds the topic however it happens to be worded. - `keyword_search` carries words that must be *literally spoken*. Every word must occur in the same passage, so it is for one or two exact tokens — a ticker, a product name — not for a description. Putting a sentence here returns nothing. - Use both when a topic must also contain an exact term. The result is their intersection, which is narrow by design; if that comes back empty, `keyword_match: "ranked"` relaxes the keyword side to a relevance hint. **Do not put a name in `semantic_search`.** Resolve it (`particle_person_resolve`, `particle_company_resolve`, `particle_entity_resolve`) and pass the slug — searching for "Sam Altman" as text finds passages that *sound like* him, while `person_slug` finds the episodes actually featuring him. **Start broad, then narrow.** Every filter compounds, and each one can silently remove all results. Issue the query with `semantic_search` alone first, then add filters once you know the topic has coverage. If a search returns nothing because of your filters, the error names the specific parameter responsible and the retry to make — act on it rather than re-issuing variations of the same query. **Note on `role`.** It describes how someone relates to the episode: `guest`/`host`/`panelist`/`correspondent` mean they *spoke*, `mention` means they were *talked about*. Omitting `role` covers both and is almost always what you want.