In a RAG pipeline, documents are split into chunks before they are embedded and stored in a search index, and at query time the system retrieves the top matches and passes them to a language model with the question. Tuning that splitting step by guesswork wastes hours because different failures come from opposite causes. Work backward from a small set of real mistakes instead.

Collect a small failure set first

Start with 10 to 20 real questions where the prototype already failed or gave an incomplete answer. For each question, write down the expected answer and the exact passage in your source documents that supports it.

Next, write a plain inspection script that runs each question through retrieval only, before the language model sees the prompt. Print the query, the expected source passage, and every retrieved chunk in rank order with its chunk ID, full text, and metadata. Keep the chunk text untruncated so you can see the exact boundaries the index returned.

This log replaces guesswork with direct inspection. A few pages of terminal output will tell you more about your RAG chunking than any rule of thumb.

Ask one question of every retrieved set

Before touching any chunking parameter, read the retrieved chunks for a failed query and ask one test question: could a human who sees only these passages answer the question accurately?

If yes, stop blaming chunking. Retrieval already handed the model what it needed, so the bug sits in your prompt, model choice, or generation behavior. If no, inspect what is missing or broken in those passages and match it to one of the patterns below.

Seven failure patterns and the matching fix

The answer sits next door in a missed neighbor chunk

You see the start of the right topic in a retrieved chunk, while the second half of the sentence or an exception clause sits in the adjacent chunk that never made the top results. Token windows frequently cut a sentence or separate a rule from its condition.

Fix this by splitting on document structure first, such as headings and paragraphs, so related sentences stay together. Then add a small chunk overlap, repeating the end of one chunk at the start of the next so a boundary sentence still appears whole in at least one chunk.

The answer is buried inside a giant section

The right passage is in the retrieved text, surrounded by several paragraphs of unrelated background, caveats, or other subtopics. Either the model overlooks the key sentence in the middle of the noise, or a few huge chunks consume your prompt budget before other relevant passages fit.

Fix this by capping section size and splitting oversized sections into smaller chunks. When chunks are tighter and focused on one point, you can retrieve a cleaner set without filling the prompt with dead weight.

The chunk is a fragment with no context

A retrieved chunk reads cleanly at the sentence level yet makes no sense alone, such as "This does not apply to enterprise plans." Without the earlier paragraph or section heading, neither a human reader nor a language model knows what "this" refers to.

Fix this by keeping chunks aligned with headings and paragraphs, or by prepending the document title and heading path to each chunk before embedding and prompting. That small piece of context anchors pronouns and short rules back to their subject.

A table, code block, or list got sliced down the middle

Half of a Markdown table shows up without its column headers, a fenced code snippet cuts off before the flags that matter, or step four of a five-step procedure appears without steps one through three. Token-count and character-count windows split right through formatted blocks.

Fix this with structure-aware rules that keep tables, fenced code blocks, and short lists intact as atomic units whenever they fit within your size cap. Scanned PDFs often lack reliable headings or block markers, so expect extra cleanup there before chunking.

An old version of the document won the search

Your inspection log shows a coherent, well-formatted chunk that happens to come from last quarter's guide or a deprecated API page. When documents update without removing or replacing their older indexed pieces, stale chunks remain a factual error waiting to surface.

Fix this in your ingestion lifecycle rather than your splitter. When a source file changes, re-chunk and re-embed it, write the new chunks under predictable IDs, and retire or delete the old chunk IDs from the index.

Near-duplicate chunks crowd out the rest of the results

Three of the top five retrieved passages say almost the same thing because wide overlap repeated whole paragraphs across consecutive chunks. That wastes slots in the result set and pushes distinct supporting passages out of the prompt.

Fix this by dialing back chunk overlap, adjusting chunk size, or adding a lightweight deduplication step after retrieval so overlapping siblings from the same section do not dominate the top results. Overlap always increases the tokens you embed and store, so keep it as small as your boundary tests allow.

Raising top-k makes answers worse

When answers look incomplete, the instinctive move is to fetch more chunks. Past a point, feeding more passages into the prompt degrades quality: instruction following slips and recall drops as the prompt grows longer and more cluttered, a problem known as context rot that can show up even under the advertised context limit.

Fix this by retrieving fewer, tighter chunks instead of piling on extra results.

A minimal structure-first splitter in Python

Once your failure log points toward boundary cuts and oversized sections, a structure-first pass is straightforward to prototype with Python's standard library. The example below splits Markdown on headings outside fenced code blocks, records each section's heading path as metadata, and caps long sections by word count with a small overlap.

import re

def chunk_markdown(text, max_words=180, overlap=25):
    sections, stack, buf, fence = [], [], [], False
    for line in text.splitlines():
        if line.lstrip().startswith("`" * 3):
            fence = not fence
        if not fence and (m := re.match(r"^(#{1,6})\s+(.*)$", line)):
            if buf:
                sections.append((" > ".join(stack), " ".join(buf).strip()))
                buf = []
            stack = stack[: len(m.group(1)) - 1] + [m.group(2).strip()]
        else:
            buf.append(line)
    if buf:
        sections.append((" > ".join(stack), " ".join(buf).strip()))
    chunks, step = [], max(1, max_words - overlap)
    for path, body in sections:
        words = body.split()
        for i in range(0, len(words), step):
            chunks.append({"heading_path": path, "text": " ".join(words[i : i + max_words])})
            if i + max_words >= len(words):
                break
    return chunks

Word count is only a rough stand-in here so the sketch stays self-contained. Because embedding models and LLMs enforce token limits and bill by tokens, production code should measure chunk size and overlap using the actual tokenizer of your embedding model. Teams usually start with a size that fits comfortably inside that embedding model's limit, then adjust chunk size and overlap based on what their retrieval failure log shows. Even the classic 2020 RAG paper (arXiv:2005.11401) split Wikipedia articles into non-overlapping 100-word passages for a 21-million-passage research setup, which was an experimental choice rather than a production template.

Metadata that pays off while debugging

Good metadata makes the inspection script much easier to read and keeps bad data out of answers. At minimum, store these fields alongside every chunk:

• A stable chunk ID tied to the source document and position so updates can overwrite or delete old entries cleanly
• Source ID or URL, document title, and heading path so you can verify context at a glance
• Page number for paginated files and an updated timestamp for tracking stale content
• Permission labels enforced as hard filters inside the search index, never left to prompt instructions alone

What chunking cannot fix

Even careful RAG chunking hits hard walls. No splitting strategy can rescue a weak embedding model that misses domain terminology, an unindexed document, an index without permission filters, or a language model that ignores retrieved text and answers from memory. Good chunking reduces retrieval mistakes, though it does not eliminate hallucinations.

For a full reference on token, semantic, and structure-based splitting options, read Lotook's method-by-method guide to chunking documents for RAG on Lotook. Keep your 10-to-20-question failure script as a permanent regression check and re-run it after every splitter change.

Yet locking both ends of a clip only works when the two images belong to the same shot. Give the model two mismatched frames and it cannot bridge them smoothly. Understanding how to select or generate a compatible image pair, why divergent frames trigger sudden cuts, and how to write the transition prompt is the core craft of first-and-last-frame generation.

Why Start and End Frames Depend on Visual Agreement

When you upload two images for start and end frames, the model uses them as the starting and ending frames and generates the transition between them. Because Kuaishou's Kling 4.0 (officially launched on October 15, 2026) generates clips from 3 to 30 seconds in one pass—up from 15 seconds in Kling 3.0—that bridge can span anything from a brief three-second gesture to a thirty-second camera move.

If the opening and closing frames agree on subject identity, perspective, lighting direction, and environment, the model can spend your chosen duration moving the subject and camera smoothly from state A to state B. If the two frames look like they were shot on different sets or with different lenses, the model has to reconcile incompatible geometry before the final second arrives.

How to Choose a Matching First and Last Frame Pair

According to Kling AI's official start and end frames quickstart guide, the content of the two frames should be as similar as possible and share the same theme for smoother transitions. Many users generate the similar pair with an image generator first, then bring those two stills into the start-and-end-frames workflow.

When preparing a first and last frame pair, check four points of alignment:

1. Consistent subject and details: The person or object in both frames should keep the same proportions, textures, and clothing details so the transition does not have to morph them mid-shot.
2. Shared environment and lighting: Keep background architecture, horizon height, color temperature, and key-light direction steady across both frames unless a lighting change is the transition you are prompting.
3. Clean dimensions and matching ratio: Both frames should share the same framing discipline. Under Kling 4.0's official API image rules, input .jpg, .jpeg, or .png files must be 30 MB or smaller, at least 300 px in width and height, with an aspect ratio between 2:5 and 5:2.
4. Controlled differences that encode only the motion: The difference between frame one and frame two should represent a clear physical change—a door that starts closed and ends open, or a subject turning toward the lens—while non-moving elements stay anchored.

What Goes Wrong When Your Two Frames Diverge

The most common failure in a start-and-end-frame setup happens before the prompt is even written: the two uploaded images are too far apart visually.

As Kling's official start-and-end-frames guide notes, significant differences between the two frames may cause a lens (shot) switch. Instead of a continuous camera move or fluid action, the video inserts an abrupt cut to jump from the geometry of the first image to the geometry of the second.

Divergent frames typically break down in three ways:

• Unwanted shot switches: Frame one shows a wide exterior angle and frame two shows a tight interior close-up with no shared background. With no continuous spatial path between the two views, the transition breaks into a lens switch.
• Subject or background drift: Both images show a similar room, but furniture layout or camera height shifts noticeably, forcing props and walls to bend into the final arrangement.
• Unstated reference roles: Even when the two frames match well, leaving the text prompt vague forces the model to guess how the first image becomes the second. Kling's official documentation notes that if you do not state the purpose of each reference explicitly, the model infers how to use it, which may differ from your intent.

A Practical Prompt Skeleton for the Transition in Between

In a start-and-end-frame task, your images already define the look of the subject and room. Instead of re-describing static textures, follow Kling's official prompting advice: organize prompts around reference roles, overall setting, event sequence, and audio requirements, and describe concrete visuals rather than abstract phrases like "premium look."

Kling's user guide also notes that the only negative instructions really needed are "no subtitles" and "no background music", because the model may add them by default.

Here is an illustrative prompt skeleton you can adapt:

Example Transition Prompt Skeleton

• Reference roles: Use the first image (@image_1 in API workflows) as the starting frame showing [subject in opening position], and the second image (@image_2) as the ending frame showing [subject in final position].
• Overall setting: [One concrete sentence describing the shared environment and lighting.]
• Event sequence: [Step-by-step camera and subject motion connecting the starting position to the ending position.]
• Audio / negative rules: [Audio requirements if needed.] No subtitles, no background music.

Applied to a concrete tabletop scene, that skeleton looks like this:

Use the first image as the starting frame with the watch resting flat on the walnut desk, and the second image as the ending frame with the watch standing upright on the leather stand. In a warm, side-lit study, a hand enters from the right, lifts the watch from the desk, and places it onto the stand while the camera dollies slightly forward to match the ending frame. No subtitles, no background music.

How Start and End Frames Map to Kling5 AI vs. Official Kling Modes

How you apply this workflow depends on where you use the model:

• In Kling's official app and API: Kling's app separates image tools into two non-combinable entry points: Omni Reference (images, videos, voice) and Keyframes (images only: first frame, first + last frames, or up to 10 keyframe images for pixel-level consistency). Kling 4.0 Flash (the lighter mode in Kling's app, up to 20 seconds and max 720p) does not currently support start-and-end frames or multiple keyframes. The official /image-to-video/kling-4.0 API (fully available October 28, 2026; billed per second of output with no input video at roughly $0.157/s for 720p and $0.235/s for 1080p as of November 2, 2026) supports first, middle, and last keyframes up to 10 images and defaults to 10 seconds if no duration is specified in the request or prompt.
• On Kling5 AI: Kling5 AI is an independent site (not affiliated with Kuaishou or the official Kling team) that currently offers Kling 4.0 alongside Kling 3.0; Kling 5.0 has not been released or officially announced by Kuaishou as of November 2026. In Kling 4.0 image-to-video on Kling5 AI, you upload a required first frame and an optional last frame (up to 2 images total; middle keyframes and up to 10 keyframes exist only in Kling's official app and API, not on Kling5 AI). You enter a required prompt (up to 2,500 characters), pick any whole-second duration from 3 to 30 seconds (default 5) at 720p or 1080p, and the output follows your uploaded frames' aspect ratio.

For a full tour of the interface settings, see the Kling 4.0 image-to-video walkthrough. If you want broader exercises beyond two-frame transitions, read an earlier piece on practicing Kling 4.0 skills before a next model arrives.

Building a Reusable Frame Library

Kling5 AI plans to add Kling 5.0 once Kuaishou releases it, though no official release date or verified specs exist yet. In our opinion, a library of well-prepared first and last frames and clear transition prompts is likely to stay useful when a next model arrives. Start by pairing two visually consistent stills in Kling 4.0, define their roles in the prompt, and let the bookends guide the motion.