AI
Retrieval quality, not the model, decides whether an AI assistant is useful
Chunking, metadata, permission filtering, and evaluation decide whether an agency assistant is useful, and the model is the replaceable part.
Most AI assistant pilots that disappoint do not disappoint because the model was not capable enough. They disappoint because the assistant was handed the wrong text. The answer sat in a document that never made it into the index, or in a paragraph split down the middle, or in a superseded version, or in a file the person asking could not see. The model then does what models do: it writes a confident answer from whatever it was given.
We run retrieval over our own material: engineering standards, runbooks, internal policy. In that work, changing the model moves answer quality a little. Fixing retrieval moves it a lot.
The model is the replaceable part
Swapping one model for another is a bounded change when the system was built for it: adjust prompts, rerun evaluation, absorb a shift in cost and latency. None of that touches your content. Retrieval is coupled to your documents, your record structure, your access rules, and your update cadence, and it outlives the model generation you start with. Treat the model as a component you will replace, and put the engineering effort into what gets passed to it.
Chunking is a content decision, not a default setting
Most retrieval toolkits default to fixed-size chunking, a set number of characters with a small overlap, and it is a poor fit for the documents agencies hold. Ordinances, administrative policies, benefit manuals, and procedure guides are hierarchical and numbered, and a subsection is often meaningless without the heading above it and the definitions at the front.
What has worked in our own builds is chunking on the document's structure, section by section, with parent headings prepended so each chunk carries its context. Fee tables and schedules should not be split at all. Scanned material needs attention earlier: if text extraction produced garbled output or no text layer, retrieval cannot recover what was lost. Reading extraction output from your worst documents is unglamorous, and it changes results more than most parameter tuning.
Metadata is what makes retrieval precise
Similarity search alone will return last cycle's version of a policy, because it reads almost like the current one. The fix is metadata on every chunk, used at query time: document type, owning department, jurisdiction, effective date, adopted or draft status, what it supersedes, and the source system. Filtering on those fields before ranking removes a class of wrong answers that prompt wording cannot reach.
Run keyword search alongside vector search. Embeddings are weak on exact strings, and agency questions are full of them: code sections, statutory citations, permit numbers, account identifiers.
Permissions belong in retrieval, not in the prompt
An assistant is a new interface to records that already have access rules, and those rules do not change because the interface changed. They come from several directions at once: personnel and investigative files restricted by agency policy and state law; criminal justice information governed by the FBI CJIS Security Policy; protected health information under HIPAA where the agency is a covered entity or business associate; student records under FERPA; and deliberative drafts that may be withheld under FOIA or a state public records act. The boundaries vary by jurisdiction, so the rules come from your records officers and counsel, not a product's defaults.
The enforcement point is the query. Filter the candidate set to what the requesting user is entitled to see, then rank what remains. Instructing the model to decline certain topics is not access control. It is a suggestion to a text generator, and it fails the first time someone rephrases the question. Log retrieval as well: which user, which question, which documents came back. When someone asks how a sensitive record reached an answer, that log is the only way to say.
Evaluation is the only thing that settles arguments
Write real questions and verify the answers by hand against the source documents. Then measure retrieval separately from generation. Did the correct passage appear in the retrieved set at all? If it did not, no prompt work or model upgrade will produce a correct answer, and tuning the generation layer is work on the wrong problem.
Score generation on top of that: is the answer supported by the retrieved text, does it cite correctly, and does it decline when the documents do not address the question. Rerun the set on every change to chunking, embeddings, filters, or content. A modest set of questions, maintained by someone who knows the subject matter, separates measured improvement from the impression of it.
Quality erodes quietly after launch
- Documents updated in the source system and never reindexed
- Near-duplicates crowding out the authoritative copy
- Superseded and deleted records still sitting in the index
- Attachments skipped by the ingestion job without anyone noticing
- No named owner for the corpus, so none of the above gets caught
What to ask when you scope this work
Spend your questions on retrieval. How is content chunked, and on what basis. What metadata exists, and is it used to filter or only to display. Where are permissions enforced, and how is that demonstrated. What is the evaluation set, who maintains it, and what does it score today. Who owns reindexing when documents change. The model named in the proposal is the easiest part to change later. The rest of it is the project.