Will this work with our own documents and data?
That is the usual reason to do it at all. The common shape is retrieval: your documents are indexed, the relevant passages are found for each question, and the model answers from those rather than from memory, with the source shown so an answer can be checked. It works well where your material is written down. It works badly where the real knowledge lives in someone’s head, and we will tell you which case you are in.
How do you stop it inventing answers?
By constraining what it is allowed to answer from, and by designing for the case where it does not know. Answers are grounded in retrieved passages and cite them, the system is allowed to say it cannot find something rather than being forced to produce a reply, and anything that triggers an action gets a person in the loop until the logs say otherwise. Evaluation runs against a set of real questions with known answers before launch, not impressions.
Does our data go into training someone else’s model?
Not under the arrangements we set up. The provider agreements and settings that govern retention and training are part of the design decision, not an afterthought, and where the data is sensitive enough to make that argument unwinnable, the answer is a model running inside your own environment. Which of those you need is a question about your data and your customers, not about the technology.
How much does it cost to run once it is live?
Running cost is per use rather than fixed, which is unfamiliar if you are used to licences. It depends on how much text goes in and out and which model handles it. The controls are caching repeated work, routing straightforward requests to smaller models, and keeping the retrieved context tight. We instrument the cost from the first day so it is a number you watch rather than a surprise at the end of a month.
How do we know whether it is actually working?
By deciding what working means before it is built, in numbers, and then measuring against them. Impressions are worthless here because everyone forms one in the first ten minutes and defends it afterwards. So we write a set of real questions with known correct answers, drawn from your own material and your own past tickets, and score against it before launch. After launch the measures are the ones that describe your business rather than the model: how many cases were resolved without a person, how often the handoff queue was right to catch something, how long the whole task now takes end to end. If those numbers do not move, the honest conclusion is that this was the wrong problem, and that is worth finding out in a pilot rather than a programme.
Which model do you use, and what happens when a better one appears?
The model should be the most replaceable part of the system, and that is an architectural choice made at the start rather than a claim made afterwards. Providers release new versions on their own schedule, prices move, and a model that leads on quality this quarter may be second next quarter. So the model sits behind an interface, the prompts and evaluation set are versioned like code, and switching is an afternoon of running the evaluation against a different endpoint. Where a build is welded to one provider's specific behaviour, you have taken on a dependency you cannot price, and it is usually taken on without anyone noticing.
Do we need our own data scientists to run this?
For the work described on this page, generally no, and that surprises people. Retrieving from your own documents, extracting fields and routing uncertain cases to a person are engineering problems more than research ones: the model is a component, and the difficulty is in the plumbing, the permissions, the evaluation and the handoff. What you do need is somebody who owns the handoff queue and reads it, because that queue is where the system tells you what it cannot do. That is a business role rather than a technical one, and the deployments that fail are almost always the ones where nobody was given it.
What about the regulations and our customers' consent?
Two separate questions, and both are cheaper to answer during design. The first is what the data allows: whether the material you want indexed contains personal or customer data, what your existing agreements permit you to do with it, and whether it may leave your environment at all. The second is disclosure: whether the person on the other end is told they are dealing with an automated system, which for customer-facing deployments is increasingly expected and occasionally required. Neither is difficult when anticipated. Both are genuinely awkward when raised after a system is live and answering customers.
