The practical test at a glance
For Seetours, AIDA Cruises' sales brand, a language model creates draft offer pages. Travel data, image references and editorial rules must become trip descriptions with port sections and complete HTML. Prices come from the booking system; editors review and publish the draft.
The task is more demanding than fluent travel prose suggests. Each port needs the right section, each image the correct assignment and every URL must be copied exactly. A trip with twenty ports creates many dependencies. A persuasive paragraph is of little use if the image beneath it shows a different port.
We also tested locally operated models. In this workflow, the tested variants, including gpt-oss-120b, did not match the commercial frontier models' quality in generating complete HTML. This is experience from a specific project, not a general ranking of local and hosted AI. Without a published comparison using identical prompts, model versions, settings and error rates, no reliable percentage gap can be inferred.
The task is the benchmark
Local or cloud describes the operating location. Open or closed weights is a separate question. Neither location nor licence alone determines how well a model associates travel information or follows instructions.
For our task, the finished result matters: are all required ports included? Do the images match? Are URLs complete and unchanged? Is the HTML usable? How much editorial rework is needed? These criteria say more about suitability than a general benchmark score.
Good individual results are not enough either. An editorial team needs quality across many routes: short trips and long sequences of ports, similar place names and recurring image subjects. The hardest cases therefore belong in the evaluation.
Training and post-training can make a difference
Here, a language model must write, associate information and follow rules simultaneously. Training on structured data and targeted instruction-following post-training are relevant factors. But how much a provider has trained these skills cannot be inferred from the product name alone.
For closed models, training data, architecture and operations are only partly documented publicly. Our result therefore proves neither a particular data volume nor superior positional encoding. Claims such as 'the model has seen more correct HTML documents' would be possible explanations, not established causes, without further evidence.
The same applies to additional computation before an answer. Reasoning can help with tasks involving several constraints. It is not exclusive to commercial cloud models: gpt-oss is also designed as a reasoning model. Source: OpenAI, gpt-oss Model Card.
Why parameter count is not enough
gpt-oss-120b has around 117 billion parameters, of which approximately 5.1 billion are active per token. As a mixture-of-experts model, it selects a subset of its experts for individual processing steps. Source: OpenAI, Introducing gpt-oss.
Total and active parameters describe different properties. But 5.1 billion active parameters do not imply that a dense 70-billion-parameter model necessarily solves the association task better. Architecture, training and the specific task remain part of the comparison. Active parameters are not a measure of model depth either.
For selection, this means a bigger number on the label does not replace testing with your own data. A larger model may help, but may not fix the errors actually blocking the workflow.
Long contexts remain a challenge of their own
The study 'Lost in the Middle' showed that the position of relevant information in the context can affect performance in the models examined. Information in the middle was sometimes used less effectively than information at the beginning or end. This finding concerns the tasks and models studied; it is not a diagnosis for every error on a Seetours offer page. Source: Liu et al., Lost in the Middle.
The practical implication is still useful: we should not just check whether all travel data fits into the context window. We must check whether the model uses it reliably. Clearly separated port sections, unique identifiers and manageable subtasks make this easier to assess.
Test quantisation instead of treating it as the explanation
Quantisation reduces the numerical precision of model weights and can save memory. Its effects on quality depend on the model and method, among other factors. For gpt-oss, the expert weights were already trained with MXFP4 quantisation in mind. Source: OpenAI, Introducing gpt-oss.
A mismatched port image therefore cannot simply be attributed to rounded-off decimal places. Different precision variants of the same model would need testing under comparable conditions. Nor can we assume closed cloud models always run at full numerical precision.
Quantisation belongs in the documentation of a model comparison. It is insufficient as the sole explanation for our project result.
Model selection is only part of the architecture
In the Seetours workflow, travel data is first obtained from the booking system and condensed into context. Image references, internal link targets and writing rules are added. After generation, the system checks and repairs the HTML and validates links. The draft remains unpublished until editorial approval.
A further architectural decision follows: exact URLs, prices and binding associations should, wherever possible, come from verified data and fixed rules. The model can suggest wording; templates can generate recurring technical structures. This division must be tested in the specific workflow and is not a retrospective claim about features already implemented.
Whether a local or hosted model is ultimately used depends on the quality of the defined task, together with data requirements, operations and effort. Our experience favours drawing this boundary deliberately: what should the model write, what can the software insert reliably, and what must a person approve?
The project report shows how this editorial process fits into the overall sales platform: Seetours – a dedicated sales channel for AIDA Cruises.