What your documents are missing collects itself
The bot answers from your documents, and questions it could not answer land in a list of gaps.
What the scenario looks like
- Execute + Data
- Data
- LLM
Documents get extended on guesses about what customers find unclear. A list of what is actually missing writes itself — out of the questions the bot could not answer. It only has to be recorded.
What is inside
- A customer question — the entry.
- Search across documents pulls fragments.
- An answer or a gap — the model returns three fields: whether it answered, the text for the customer, and if it did not, a statement of the gap.
- Did we answer? — the branch. The lower one records the gap and still answers.
The gap is phrased from the documents’ side, not the customer’s: the prompt asks for “the documents do not cover X” rather than “a customer asked about X”. The first can be picked up and written; the second has to be thought about again.
The answer is never empty
The model sometimes returns an empty text field. An empty answer never reaches the chat at all: the customer sees silence, the run is green, and the only way you find out is a complaint. Both branches therefore carry fallback text — that is the difference between “the bot got it wrong” and “the bot vanished”.
What to set up for yourself
- The base and the collection — two different ids, easy to mix up.
- The threshold. The model decides whether “an answer was found”. A strict phrasing means more entries in the list and more honest “I don’t know” to customers.
- What to do with the list. After a month it holds a list sorted by life itself: asked more often, repeated more often. That is a ready plan for what to write.
What to connect
A knowledge base under Documents and a collection under Tables. It pairs well with “The bot calls a human”: there the person is called immediately, here the same case is also recorded.