Before adding another AI input, try taking one away

A richer input is a design decision

Imagine an assistant that helps you organize clips from a small creative project. You could give it filenames, transcripts, still frames, full video and audio. That sounds comprehensive. It also leaves a surprisingly basic question unanswered: which of those inputs does the job actually need?

LiquidAI introduced LFM3 on October 27 as a family of small models sharing a backbone, with variants for text, vision, audio, combined modalities and decisions. Its announcement presents specialization as a central use case. Those are the developer’s descriptions of the released family, not our independent performance findings.

Our suggested method is to remove inputs deliberately before committing to an elaborate pipeline. Ask whether an image, soundtrack or video sequence changes the answer for a reason you can explain. This article develops an original planning and evaluation exercise; we have not run a comparative LFM3 benchmark.

The point is not to find the smallest model at any cost. It is to make every additional kind of evidence earn its place. Sometimes a frame contains the one detail a transcript cannot reveal. Sometimes audio is essential. Sometimes another input adds processing and uncertainty without improving the decision you actually need to make.

Source: LiquidAI: Build specialized multimodal models with LFM3 ↗ · LiquidAI: LFM3-VL-2B model card, examples and requirements ↗ · Scikit-learn: Metrics and scoring ↗ · Hugging Face: Download files at a specific revision ↗

Define a question that has an answer

Start with a task narrow enough that a person could check it. “Understand my media library” is too broad for a first comparison. “Identify which clips show the finished model on a clear background” gives you something observable. You can open the source clip and decide whether the model is finished and the background is clear.

Write down what finished means in this fictional project. Perhaps a painted object counts, while a partly assembled object does not. A clear background might mean no unrelated objects directly behind the subject. These definitions belong to your project; do not present them as universal visual standards.

This reasoning produces testable expectations. For a genuinely visual question, image input should have a chance to contribute. For a question about whether someone says a specific sentence, the transcript may be sufficient. For a question about a sound’s character, a transcript may remove the very property you need.

Write an expected evidence type beside every task before you select a model. This makes it easier to notice a strange result later. If an assistant appears to answer a visual question from filenames alone, inspect whether the names are leaking the answer. A promising score can be a clue about the test materials rather than proof of visual understanding.

Build a deliberately small comparison

Use a collection you own or have permission to analyze. For a first rehearsal, choose a dozen short examples that you can inspect yourself. This is a debugging collection, not enough material to support broad claims about a model’s real-world accuracy.

For each example, write the answer you would accept and the evidence supporting it. If two people disagree about the answer, resolve the task definition before treating either model output as wrong. A vague question produces ambiguous evaluation even when the model is behaving reasonably.

Now plan versions of the same question with different available inputs. One version gets a short text description. Another gets the selected image evidence. A third gets the relevant sequence if your chosen model supports it. Keep the requested output consistent so you are comparing usefulness for the task rather than preferences for a writing style.

Do not feed an unsupported modality into a model and call the resulting failure a quality comparison. The official LFM3-VL model card is the place to check the visual model’s input handling, example preprocessing and supported execution paths. A family name does not mean every member accepts the same data or produces the same type of output.

Look for the reason an answer changed

Suppose the text-only version says a clip shows a finished model, while the image version says it is partly assembled. Open the source and look for the actual difference. Perhaps the filename was optimistic and the visible object still has missing parts. That is a useful correction attributable to visual evidence.

Now suppose both versions say finished, but the image version adds a confident description of a part that is not visible. The answer label alone would hide the problem. Record the unsupported detail as well as the correct decision. A system that arrives at the right category through invented observations still needs attention.

Use a simple explanation request: ask which visible or audible detail supports the decision, and permit “insufficient evidence.” Do not treat the model’s explanation as proof of its internal reasoning. Use it as a claim you can compare with the source material.

Our proposed review sheet has space for the answer, the cited observation, the source location and a reviewer note. It can be a plain document. The most valuable row may be one where the answer changed for no identifiable reason. That case tells you to investigate before declaring the additional modality useful.

Also watch for changes in the task itself. If one version is asked to identify a clip and another is asked to describe everything it contains, the second has more opportunities to be wrong. Keep the question stable, then conduct a separate exploration of richer output if it would serve a real user need.

Separate input value from presentation value

A multimodal system can feel more capable simply because its answer is longer or more vivid. That is a presentation effect you should examine separately from whether the input improved the decision.

For the clip-organizing example, require a compact response: a category, one supporting observation and an uncertainty note when needed. Hide the model name during review if practical. Ask the reviewer whether the result would help them choose the right clip, not which paragraph sounds more impressive.

Then evaluate any creative description in a second pass. A colorful caption could be useful for brainstorming even if it is unsuitable as catalog metadata. The same output can be helpful in one role and misleading in another. Decide which role the application promises.

Scikit-learn’s scoring documentation emphasizes choosing evaluation measures according to the prediction’s intended goal. Applied to this exercise, that means defining success before looking at a favorite result. A wrong catalog label and an imperfect brainstorming phrase do not have the same consequence.

You do not need to install a scoring library to use that principle. Count the decisions a reviewer would accept without correction, record the changes they make and note where uncertainty was missing. For a small pilot, the written explanations are often more informative than a percentage with a false air of precision.

Account for preparation work

An input is not free merely because you already have the file. Someone has to decide what to send, transform it into a supported form and preserve the connection to the original source. In our hypothetical workflow, a reviewer may spend more time choosing frames than the assistant saves organizing the resulting labels.

Record that preparation time separately. If you select the perfect frame by hand for every example, be explicit that the pilot evaluates answers given carefully chosen evidence. It does not yet evaluate automatic frame selection across an entire library.

Likewise, a manually corrected transcript gives the text-only route a cleaner input than a live application may receive. That may be exactly what you want for an early comparison, but write it down. A fair experiment requires knowing which parts have already been helped by a person.

Keep source positions with prepared inputs. A still image should point back to the clip and approximate moment it came from. A transcript segment should remain associated with its source audio. Otherwise a reviewer may be able to read an answer but unable to check it.

For a no-code planning pass, make folders for each example and include a short note explaining the selection. You can discover that a workflow needs better evidence management before spending time on model deployment. That discovery is a useful result, even if it means postponing multimodal automation.

Treat preparation as part of the application design. The model receives only what the pipeline provides, while the user experiences the whole process.

Make the comparison repeatable enough to learn from

After an encouraging first result, resist changing the model, prompt and media preparation at the same time. You would no longer know which change helped. Choose one adjustment and keep a short record of the before and after conditions.

Save the model identifier and exact revision when your execution path permits it. Hugging Face’s download documentation supports selecting files by a revision, including a commit hash, instead of implicitly taking the latest branch contents. That is useful when you need to explain which artifact produced a particular result.

Also record the runtime and preprocessing choices you actually used. Do not copy a recommended configuration into your report unless it was the configuration that ran. If a deployment requires custom code, inspect the relevant instructions and code before enabling it; a convenient example is not a reason to skip understanding what will execute.

For this pilot, a repeatable note might say that one question was applied to the same twelve examples, with a particular frame-selection rule and a fixed response format. It should also say which cases were manually prepared and which were automatic.

Run a few examples more than once if the workflow is stochastic. Different answers to the same evidence can matter even when the average looks acceptable. Record variability without claiming that a handful of repeats establishes a statistical reliability rate.

At the end, classify each additional input as essential, useful in a limited case or not yet justified. Essential means the task cannot be answered responsibly without it. Useful means it improves a defined subset of cases. Not yet justified means the pilot has not shown enough benefit to pay for the added complexity.

You might find that the first version needs still images for object identification but no audio. Another project might need audio for pronunciation review and no camera. These are possible outcomes of the proposed exercise, not findings about LFM3 or claims that one modality is generally superior.

Design the interface around the decision. If audio is unnecessary, do not ask for microphone access merely because the model family offers an audio variant. If the system needs a selected frame, tell the user how to choose one and what happens when it is unclear.

Keep a path for insufficient evidence. A user should be able to provide a better source or complete the task manually. More modalities should not create pressure to accept an answer just because the system processed a large bundle of files.

The useful result is a small map from question to evidence to output. LFM3’s range of models makes that map worth drawing now. You can take advantage of new capabilities while staying precise about what your own application needs to see, hear and explain.