Chat answers from a local Milvus Lite file, not from MySQL on the request path. Editors can change a page or drop notes onto a hidden category, and the model still sees whatever was embedded last time.
We use hidden pages on purpose. Some answers should not sit on the public wiki, so they go into categories that the site listing skips. Retrieval was also skipping them. One support question had a dedicated hidden FAQ in the database; the model cited an unrelated shop page and said the corpus had nothing on the topic.
The fix is a small sidecar next to the API, same venv, no extra services. On process start, and then every 12 hours, it reads the wiki tables (page id, category, title, update_time, body). Hidden rows are included; we do not filter on visible. Body prefers one locale and falls back to a second. The article key keeps the original category name, hidden marker and all, so the client can still open that page.
A fingerprint of id + update_time + body hash is compared with the last run. No change: exit, leave the API alone. Change: strip HTML, split chunks, embed with the same model the retriever already uses, write milvus_lite.next.db, then replace the live .db. Milvus Lite needs a path that ends in .db. After a real swap we restart the chat process, because it opens the file at boot and has no reload. Unchanged fingerprints must not restart anything; that would kill in-flight replies.
First production run pulled every page with content, including the hidden FAQ. Hitting the existing chat SSE endpoint with the old support question now points at that FAQ.
If someone publishes a hidden page and needs it in chat before the next 12-hour tick, restart the sidecar. It indexes once on startup.
Top comments (0)