When the chatbot searches your Knowledge Base, the result is cached for five minutes by default. Ask the same question twice inside that window and the second search is served from the cache rather than sent upstream.
Why it is there
Support questions repeat, heavily. On a busy site the same handful of questions arrive over and over, often in bursts after an email goes out or a product ships late.
Caching the search step means each distinct question costs one upstream search per five minutes rather than one per visitor. That is both faster for the visitor and cheaper for you.
The cache holds the search — which articles matched — not the reply. Every visitor still gets an answer written for their own conversation.
What it does not do
It does not hide your edits. Sync events flush the cache automatically, so publishing or updating an article clears the matching entries. You will not spend five minutes looking at stale results after fixing a typo.
It does not cache across an object-cache flush. The cache lives in the
sohaychat_kb object-cache group. On a site with no persistent object cache
it lasts for a single request, which means most of the benefit is on sites
running Redis or Memcached.
Changing the window
One filter, taking seconds:
add_filter( 'sohaychat_kb_search_cache_ttl', function () {
return 900;
} );
Return 0 to disable it entirely:
add_filter( 'sohaychat_kb_search_cache_ttl', '__return_zero' );
When to touch it
Mostly, do not. The default is a reasonable trade and the automatic flush removes the usual reason to distrust a cache.
Reasons to lengthen it: a high-traffic site with a stable Knowledge Base, where you would rather pay for fewer searches.
Reasons to disable it: you are debugging retrieval and want each question to genuinely re-search every time. Turning it off while you investigate — and back on afterwards — removes one variable from a confusing situation.
Where to go next
The chatbot isn’t using my articles, if what brought you here was an answer that seemed out of date.
