Build1 publisher3 min readPublished
Don't start at the model layer: classify inputs by reliability, then let RAG wait
A build note from the team behind Inspecly puts evidence normalization first and pushes RAG and agents to the back of the queue. The reordering is about provenance, not fashion.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- A dev.to post titled "Don't Start With RAG: Lessons From Building an Automotive AI Pipeline" describes the automotive AI pipeline behind Inspecly, written from the perspective of the team that built it.
- The post says it is tempting when building an AI product to start with the fashionable pieces: vector database, RAG, agents, multimodal models, then connect everything to an LLM and hope the final prompt makes sense of it.
- The team's first question was not which LLM to use, but what information they actually have, how reliable it is, and which system should process it; the post says that distinction changed the architecture.
- A request can contain a written description, a voice message, vehicle photos, an OBD scan, vehicle metadata, or only some of these.
- The post states these inputs do not have the same reliability: an OBD code is structured information, a photo is visual evidence, a voice message represents what the driver observed, and vehicle metadata may require exact lookup; treating them as equivalent text would be a mistake.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
The team behind Inspecly published a build note on dev.to arguing that the expensive mistake in AI product work is starting at the model layer, and that the first question should be what information you actually have, how reliable it is, and which system should process it [1][3]. The consequence is architectural rather than philosophical: once inputs are classified by reliability, the fashionable components (vector database, RAG, agents, one large multimodal prompt) get demoted from foundation to fallback [2][11].
The inputs in this domain are messy by construction. A single request can arrive as a written description, a voice message, vehicle photos, an OBD scan, vehicle metadata, or only some of those [4]. According to the post, these are not interchangeable text: an OBD code is structured data, a photo is visual evidence, a voice note is what the driver observed, and vehicle metadata may need an exact lookup [5]. So the pipeline builds a normalized evidence object first, holding make, model, optional VIN, description, transcription, OBD codes and images, and containing no diagnosis at all [6].
That object then routes. OBD code to deterministic lookup, vehicle information to exact lookup or API, photo to visual analysis, voice to transcription, unknown technical information to tool-based retrieval, safety constraint to an explicit business rule [7]. Two of the six paths never touch a model, and a third is a hard-coded rule [18]. Collapse them into one multimodal prompt and you get something attractive for a prototype, difficult to control, and unable to answer where a conclusion came from [8].
The ordering rule that does the most work: if reliable structured information already exists, use it directly [9]. When a diagnostic trouble code is present, the system queries a curated OBD database whose records carry explanation, possible causes, possible actions and a validation_status of reviewed [9]. Semantic retrieval over paragraphs is the wrong instrument for an exact identifier against validated fields; RAG earns its place when the knowledge only lives in documents [10].
Agents arrive last, and conditionally. The internal database cannot cover every code, every manufacturer-specific interpretation and every vehicle configuration, so a tool-using agent searches when structured knowledge is missing [11]. The stated discipline is that such output is tagged with a source type of tool_agent and a validation_status of unverified rather than quietly acquiring the standing of a reviewed record [12]. The system is meant to know at all times whether a fact came from the reviewed internal database, an external technical source, an agent, image analysis, or the driver [13].
Vision gets the same treatment. A photo can show a dashboard warning light, body damage, tyre wear, a fluid trace or a damaged component, but the post notes it almost never tells the whole story [14], so the output is an observation with confidence, limitations and a requires_physical_inspection flag, not a flat "Your vehicle has an oil leak" [15]. The author's blunt version: AI systems often sound more certain than the evidence actually allows [16]. Voice is treated as one more source of context [17].
What to watch: this is one team's account, with no accuracy, latency or cost figures attached to any of it [19]. The load-bearing questions are operational. Who keeps coverage of the curated OBD database current as codes and manufacturer variants multiply, given that the post concedes it cannot be complete [11]. And whether validation_status survives into the user-facing answer, or gets flattened back into prose by the final prompt, which would undo the provenance the rest of the pipeline exists to preserve [12][13].