Find coverage with a particular tone

/search in hybrid mode. The parameters matter less than the reasoning behind them, so that is most of what is below.

The request

HTTP

GET /search
  ?q=<subject>
  &mode=hybrid
  &from=<now - 7d>

# each result carries a tone score; filter client-side
results.filter(a => a.tone > 2)

Why these parameters

Every article carries a tone score derived from its language. Filter on it after retrieval rather than trying to express tone in the query, because a query for "good news about X" retrieves articles that discuss whether the news is good, which is a different set.

The obvious approach, and why it loses

The obvious approach is to put the tone in the query — good news about, positive coverage of, praise for — and it returns something plausible and wrong. Semantic retrieval matches on subject, so a query for good news about a company retrieves articles discussing whether the news is good, which includes every piece arguing that it is not. Keyword variants fail the same way for a different reason: the words that describe sentiment appear most often in pieces analysing sentiment. Retrieve on the subject, filter on the score afterwards, and the two concerns stay separate — which also means you can change the threshold without re-running the retrieval.

When it returns too much, or too little

Tone is a continuous score, so the useful move is almost never a different query but a different cut. Retrieve a week without any tone constraint, look at how the scores actually distribute for your subject, and put the threshold where results stop being what you meant. That point moves by subject: coverage of consumer products sits higher overall than coverage of insurance, so a threshold tuned on one reads as strict on the other. Too little usually means the cut was copied from another subject. Too much usually means the retrieval was broad and the tone filter is being asked to do the relevance work as well, which it cannot.

How you would know it is working

Score a sample by hand and compare. Take thirty articles, mark each as positive, neutral or negative as a reader would, and check the agreement with the score. You are not looking for a high correlation — you are looking for the cases where they diverge, because those tell you what the score is actually measuring on your subject. The usual finding is that measured, technical writing about a genuinely bad event scores neutral while an opinion piece about a minor irritation scores strongly negative. Once you have seen that on your own data, the rule follows: use tone to shape a result set, never as the headline number on a dashboard. Re-run the hand-scored comparison whenever you move to a new subject or a new language, since the score's relationship to how a reader would judge an article is not stable across either, and assuming it is transfers a threshold that was never valid.

When this is the wrong tool

Tone is computed from wording, not from meaning. An article reporting a disaster in measured language scores less negative than an opinion piece complaining about a minor inconvenience. It is a useful filter and a poor metric — do not build a dashboard whose headline number is average tone.

Running it for real

Response fields, failure modes, adaptations and scheduling cost: Find coverage with a particular tone, in the docs.