Back to blog
Showing the model what matters: the services that lighten LIA's work
Technical3 min read

Showing the model what matters: the services that lighten LIA's work

Why it matters

When LIA calls a language model, she sends it text: your question, the useful context, and the description of the tools it can use. That text is paid for by volume, in tokens, and the longer it is, the slower the answer. LIA covers dozens of domains and many tools. Describing all of them on every request would be expensive, and a planner drowning in options makes worse choices.

The opposite excess is a trap too: taking away information the model needs forces it to guess.

What I wanted

I wanted each model to receive what it needs, nothing less, and not much more. And I didn't want to call a model for something a simple rule already knows how to do. Three services share this work upstream of Pipeline mode, the one that plans before acting.

Understanding the question from the start

The first service reads your question and pulls out the essentials: is it a conversation or an action, which domains are involved, what your words refer to. “What's the weather like at my brother's place?” touches the weather, but also your contacts, since your brother's address is needed. “My wife” becomes the first name your memory knows. “The first one” means the first item in the list LIA just showed you. All the rest of the processing starts from this analysis, without redoing it.

Showing only the right tools

The second service prepares the catalogue the planner sees: only the tools of the domains it identified and of the type of action requested, described compactly. Two safety nets keep this sorting from removing the essentials. First, if a selected tool needs a piece of data that only another tool can produce, that other tool is added: without it, no plan would be possible. Then, if the planner still finds no plan it can execute, LIA tries again once with a wider catalogue. All of this happens before anything is executed.

Skipping what is already known

The third service writes the plan, and it sometimes manages without a model. “Show me the details of the first one”: the item is already identified, so the plan is written directly. “Find the restaurant for that appointment”: the event's location goes as is to the place search.

It also relies on tool sequences that have already been validated, for example “search for a contact, then send an e-mail”. A sequence that is often validated is suggested to the planner. When confidence is very high, the plan can even skip an extra check by a model. This register is shared across the whole installation and only records the sequence of tools, nothing of what you wrote. The operator can load reference sequences into it and, if they choose, let LIA record the ones that pass validation. By default, this recording is off: LIA uses the sequences already there without learning new ones.

The limits

This sorting has its blind spots. If the analysis misses a domain, the planner doesn't see its tools, and the wider catalogue only helps once. Shortcuts only cover simple cases. The sequence register keeps what works for everyone, not your own preferences. And these services prepare Pipeline mode: in ReAct mode, LIA picks her tools differently, either through a relevance ranking computed on your question, or by keeping all your tools at hand, depending on the exchange rhythm you chose.

Read more: Finding what matters without dragging in everything: the thresholds of search by meaning; A conductor and specialists: how LIA handles your request.

#optimization#caching#pattern-learning#token-reduction