How an answer is made

Knowledge base with embeddings

The spot descriptions are cut into sections and stored as vectors (embeddings) in PostgreSQL with pgvector. Before every answer the question becomes a vector too and is compared with the sections; the closest ones go into the model’s instruction as reference text. Only the spot descriptions are searched, and only what the person asking may read.

Tools instead of invented numbers

The language model does not calculate and knows no weather data. It gets four tools (function calling), each with an exact schema: search and rank spots for a wish, read one spot in detail, the wind now and over the next 48 hours, and where there is good wind today or at the weekend. The model only supplies the arguments – say month 11, at least 20 °C, 15 knots. The server checks them against the schema, runs the tool and returns a compact result. Numbers in the answer therefore always come from the data.

A short, agentic flow

An answer is made in rounds: the model calls a tool, reads the result, calls another one if needed – first the search, say, then the details of the best match – and only then writes the answer. The number of rounds is limited, every round is booked, and before each further one the budget is checked. Meanwhile the person sees that a search is running.

Fixed answer format

The answer is not free text but a JSON object following a strict schema: the text for the person, the spots named, whether the selection should go on the map, one spot for booking, up to three suggestions for the next question and – after a web search – the sources. The page checks every spot key against its own list and builds buttons and addresses itself – a link cannot arrive broken, wrong or in the wrong language.

The model is a setting

Which language model answers is a setting of the agent, not part of the code. Today it is a small, low-cost model on Azure OpenAI; other providers can be connected. The tools need a model with function calling in the supported form.