build_knowledge_index

io.agent4/agent4-tenant · Verify this server

Build (or rebuild) the structured index for a knowledge base — the second leg beside vector search. Vector search answers "what does this passage say". It **cannot count, filter numerically or aggregate**, so "how many documents", "which ones are between 1000 and 2000 words", "how many per category" are not answered badly — they are structurally unanswerable. This builds a small per-KB table from whatever structured header the documents share, which the agent can then query with SQL via `query_knowledge_table`. Only worth it when the documents share a machine-readable header (a metadata table, YAML front matter, `Field: value` lines). **Prose gets declined, and that is the right answer** — a table of unique values makes statistics meaningless. `roles` names the fields that must be extracted **exactly** and never paraphrased. Use it when the answer has to quote something the model must not invent: - `identity` — what to call the item (book title, drug name, product name) - `link` — where to send the user - `image` — what to show the user - `code` — the unique identifier Which link is "the" link is a business fact the data does not state — only the customer knows. A declared role that cannot be found comes back in `roles.unresolved` **with candidate field names**: ask the user which one it is, do not guess. **Read `dropped` in the report and tell the user about it.** A column that was thrown out (coverage too low, two columns holding identical values) is invisible in later query results — the model simply works around it — so this report is the only place it is ever mentioned.