A short request and a long itinerary can both end with an editable trip. That does not mean they should enter the planner in the same way.
The short request usually describes what someone wants. The long document may describe what somebody else did, what a guide recommends, several alternatives, and details the traveler does not want at all. Before planning, the system must decide what kind of evidence it has received.
At Platix, the import workflow separates source extraction from traveler selection and trip planning. Chunking is part of that design, but it is not the whole explanation for why the workflows behave differently.
This article describes the architecture, not a comparative success-rate benchmark. All examples below are synthetic and were written for this article; none comes from a customer conversation or itinerary.
A document is not automatically a set of instructions
Consider a synthetic set of travel notes. One paragraph recommends staying near the coast. Another describes an optional inland excursion. Later, the author mentions returning to the same hotel and says a particular restaurant was their favorite.
A planner that treats every sentence as a command can make several mistakes at once: add an unnecessary hotel change, turn the optional excursion into a requirement, and assume the restaurant recommendation reflects the traveler's own preference.
Extraction has a narrower job. It should identify the overnight base, the possible excursion, the return relationship, and the attributed recommendation. The traveler can then decide what belongs in their trip.
This is an authority distinction, not just a language-understanding problem. Source material is reference material. It should not acquire the authority to change the traveler's goals merely because it appears inside a model's context.
Check the input boundary before blaming the model
When a long input fails, it is tempting to conclude that the model could not handle the context.
But there are several limits before and around a model call: the form's text allowance, request validation, upload size, extracted-text size, model input budget, and output budget. A rejection at one boundary says little about the others.
Characters, bytes, and tokens also measure different things. A file that fits a byte limit may still exceed an extracted-text limit. A character count is not a promise about how many model tokens the text will require.
Platix's text import accepts up to 250,000 characters of normalized source text, with a separate 2 MB upload limit. Those are intake limits, not a claim that every accepted document will produce a complete or correct itinerary. The interface should make the limits visible before submission.
Diagnosing a failure starts with identifying which stage rejected or failed the request. Increasing model context cannot fix a request that never reached the model.
Two meanings of chunking
The word chunking can hide an important architectural difference.
One system may divide text into labeled sections and send all of those sections in one model request. The labels help with references and evidence tracking, but the model still receives the combined context.
Another system may send each section through a separate extraction call, then combine the extracted results. This reduces the raw text any individual extraction call must handle, but introduces a new problem: recovering the relationships between sections.
Platix's source import uses the second pattern. It normalizes the source, divides it into bounded sections, extracts evidence from each, and reconciles the results before presenting possible trip shapes.
A short-prompt planning experience does not need that same document-processing stage. Nor does a single user submission imply a single model call. Brief interpretation, route decisions, day planning, place resolution, and review can still happen in separate stages behind a one-shot interaction.
Extract locally, reconcile globally
Local extraction makes a difficult task smaller. Rather than asking a model to transform an entire document directly into a finished trip, each extraction asks what travel evidence appears in one section.
Useful evidence includes destinations, possible overnight bases, sights, day trips, duration suggestions, and relationships between those items. Keeping references to the source helps later stages distinguish extracted statements from unsupported additions.
Overlap between sections can preserve a sentence or relationship that would otherwise be cut at a boundary. It also creates duplicates. Seeing the same recommendation in two overlapping sections must not make it twice as important.
Reconciliation therefore does more than concatenate summaries. It deduplicates evidence, distinguishes a visit from an overnight stay, and attempts to recover a coherent route across the whole source.
In the synthetic example, the inland excursion and the return to the coastal hotel might be extracted from different sections. Reconciliation needs to connect them without inventing another base. A repeated destination can represent a genuine return, not an accidental duplicate to remove.
This is where a collection of locally plausible interpretations must become one globally plausible proposal.
Let the traveler choose before planning the details
Even a faithful extraction does not settle what the traveler wants.
A document may support several durations or pacing choices. Platix's import workflow produces candidate trip shapes and gives the traveler a selection step before the detailed itinerary is created.
The selected shape becomes a structured planning input: bases, duration, route segments, selected places, and day-level guidance. That handoff lets the import path reuse downstream planning components instead of building a separate itinerary engine for documents.
The distinction matters when a source contains alternatives. A document can supply possibilities; selecting a possibility makes it part of this planning request. Extracting more text is not a substitute for that decision.
This is one practical consequence of using structured travel-planning systems rather than treating everything as chat.
Chunking creates obligations as well as benefits
Splitting work does not make evidence loss impossible.
A detail may be missed during extraction. A summary may lose a qualification. Separate sections may conflict. A later reconciliation model may favor an apparently tidy route over an awkward but important constraint.
Coverage checks must be interpreted carefully. Comparing extracted facts with a merged digest can reveal facts lost during merging. It cannot prove that the extraction found every relevant statement in the original source. A reviewer cannot recover evidence it never sees.
For builders, this suggests several explicit requirements:
- Check that section boundaries cover the intended source, including its beginning, middle, and end.
- Deduplicate overlapping evidence without erasing genuine return visits or repeated commitments.
- Preserve alternatives and contradictions until there is a justified resolution.
- Surface processing limits rather than silently treating omitted material as successfully understood.
- Test relationships that span sections, not only facts contained within a single section.
These are evaluation requirements, not a claim that chunking alone guarantees them. Model review remains another fallible layer, as we discuss in how an LLM can judge an AI-planned trip.
Why not use the import workflow for every request?
Document extraction adds work. Separate extraction calls and reconciliation can increase latency and model usage, especially when calls run sequentially. Overlap repeats some text. Intermediate summaries introduce another opportunity to lose nuance.
For a concise request, that machinery may solve a problem the traveler does not have. Interpreting the request directly can preserve its global constraints without first treating it as a source document.
The right routing question is therefore not merely, "How long is this text?" It is, "Is this primarily an instruction, reference material, or a mixture?"
A long instruction may still contain one tightly connected set of requirements. A short pasted passage may still be somebody else's recommendation. Length is a useful signal, not the definition of intent.
How we would compare the approaches fairly
To establish whether one approach performs better, we would need controlled synthetic cases, not a memorable success beside a memorable failure.
The test set should vary document length, repetition, optional activities, conflicting durations, and relationships that cross section boundaries. It should include constraints near the middle as well as the ends, plus paraphrases that preserve the same meaning.
Useful measurements would include retained requirements, invented commitments, overnight-base accuracy, unnecessary transfers, unresolved ambiguity, latency, and model usage. Repeated runs would help distinguish a durable improvement from a fortunate model response.
The comparison must also control what the traveler confirmed. An import that benefits from an explicit selection step is not equivalent to a request where that choice remains unstated. That extra interaction may explain part of the improvement.
This is the same reason one failure should lead to a family of tests, rather than one narrowly tailored patch.
The durable lesson
A larger context window gives a model room to read more. It does not decide which statements are instructions, which are evidence, and which remain optional.
Reliable import design separates those responsibilities: extract what the source says, reconcile its relationships, let the traveler choose, and hand a structured request to the planner. Chunking helps distribute the reading. The surrounding contracts determine what that reading is allowed to mean.
Loading comments...