Question 1

Do we need to fine-tune a model?

Accepted Answer

Usually not, and almost never first. Most "the model got it wrong" problems are retrieval or prompt problems — the right information was never put in front of the model, so training it harder does not help. Fine-tuning earns its place when you need a consistent output format or a narrow house style at scale, and even then it sits on top of good retrieval; that scope belongs on our Custom LLM Development page.

Question 2

How do you stop the model inventing answers?

Accepted Answer

Grounding, citation and refusal, in that order. The assistant answers from retrieved passages of your own content and shows where each claim came from, and we write explicit rules for what it does when nothing relevant is found: say so and hand over, rather than improvise. Nobody can honestly promise a hallucination rate of zero — what we can do is make wrong answers rare, visible and traceable to a source.

Question 3

What data do you need from us to start?

Accepted Answer

Your product or service information, your policies, and a sample of the real questions people already ask — helpdesk exports, WhatsApp threads and email are ideal. You do not need a labelled training set or a data warehouse. Messy real questions are far more useful to us than a tidy FAQ page, because they show the phrasing your customers actually use.

Question 4

What will it cost to run each month?

Accepted Answer

Model usage is billed per token, so the honest answer is a range tied to your volume, not a flat number. We estimate it from your real question volume and typical answer length, then track tokens per request in production so you can see cost by feature and set alerts. Routing simple queries to a smaller model tier and caching repeated context are the two levers that move the bill most.

Question 5

Where does our data go, and is it used to train models?

Accepted Answer

Prompts and retrieved context go to whichever model provider you approve; your database stays with you. The major providers offer commercial API terms under which submitted data is not used to train their models, with retention windows that can be shortened or switched off — we configure that explicitly and write down what was chosen. If your policy rules out third-party processing entirely, we design around regional endpoints or an open-weight model you host yourself.

Question 6

Can it read from our existing systems?

Accepted Answer

Yes — that is exactly what tool calling is for. Rather than copying your database into the model, the assistant calls narrow, permission-scoped functions: look up an order by number, check stock for a variant, fetch an invoice. We build those read-only by default, and anything that writes or changes state goes through an explicit confirmation step.

Question 7

How long does a first version take?

Accepted Answer

A focused assistant with retrieval over your content is typically a few weeks to a usable internal prototype, and longer to a public launch once evaluation, guardrails and channel integration are finished. The timeline depends far more on how accessible and current your data is than on the model work itself. We sequence it so you can judge quality early, before the larger integration budget is committed.

Question 8

What happens when the model we use is deprecated?

Accepted Answer

Providers retire models on a published schedule, so this is a planned migration rather than an emergency. Because we keep an evaluation set, moving means running the candidate model against known-good answers, comparing quality, latency and cost, then switching behind a config change. The provider wrapper is deliberately thin, so no application code is welded to one vendor.

Question 9

How good is it in languages other than English?

Accepted Answer

Current frontier models handle Turkish, German and Arabic well for support, summarisation and classification, but quality varies by task and by how your own source content is written. We test in the languages you actually serve, using your own phrasing and product names, before anyone signs off. Where output reads stiff, the fix is usually the prompt and the source content rather than a different model.

Question 10

Can we run the model on our own infrastructure?

Accepted Answer

Yes, with real trade-offs. Open-weight models on your own or an EU-region GPU host keep data inside your boundary, at the cost of infrastructure work, GPU spend and, on the hardest reasoning tasks, a quality gap against the leading hosted models. For most teams we recommend starting with a hosted API under strict retention settings and revisiting self-hosting when a policy requirement or sustained volume makes it pay.

How can we help?

LLM Services
FAQ

Helpful
information

Getting Started

Timeline

Pricing

Support

Still have questions?

LLM ServicesFAQ

Helpfulinformation