BMW Genius Assistant
Knowledge assistant for technical information, answering in the language it's asked in.
The problem
The amount of technology on cars has risen dramatically in recent years. Higher-end brands like BMW have felt the need to create a role, the Product Genius, to onboard clients and explain how to operate their new cars. A BMW Product Genius is therefore required to possess deep expertise across a wide range of technical areas across all the different vehicles on BMW’s extensive product line. However well trained the Product Geniuses are, there’s always a question that they’re unable to answer on the spot. This requires them to research a large number of documents to find that answer. It also introduces a delay in providing the answer, and a break in the explanation flow.
What I built
A single query box. Ask in any European language, get an answer in the same language with cited sources drawn from the technical documents. No room for hallucination or searching for answers outside the provided documents. If the answer does not exist in the official documentation, the system informs the Product Genius. Built for 100% accuracy.
How it works
The system I built converts every row of the many spec sheets into declarative sentences before embedding. Source files use four different column layouts depending on the export template, so the parser detects layout per file rather than assuming one.
At query time a model extracts vehicle identifiers plus a version of the question stripped of vehicle context and translated to English — that stripped version is what gets embedded, while the original-language question drives generation. Identifiers resolve against a hand-built reference table into a metadata filter, falling back to unfiltered search when the filter returns nothing.
What I’d do differently
The current system embeds raw chunks and retrieves at query time. That works, but nothing accumulates — the tenth document about the G45 X3 doesn’t make the system smarter about the G45 X3, it just adds more chunks competing for the same retrieval slots.
The next version will put a maintained wiki layer between the sources and the query. Raw sources stay immutable: TDD/EC exports, SIBs, TIS manuals. Above them, an LLM-maintained set of pages — one entity page per model (variants, production years, systems), concept pages for diagnostic procedures and electrical architecture, a summary page per source, plus an index and a change log. Queries hit the wiki, not the raw corpus.
Three things this buys that chunk retrieval doesn’t:
Knowledge compounds. A new SIB updates the existing G45 page rather than landing as another isolated chunk. Years of documentation growth stay navigable instead of turning into vector bloat.
Contradictions become explicit. When a bulletin supersedes an earlier claim — a spec that changed, a charging procedure that differs between generations — the system logs the conflict instead of silently returning both. That’s the failure mode that matters most here: two plausible answers with no indication which one is current.
Retrieval gets narrower. Section-level lookup against curated pages costs far less per query than semantic search plus full-document reads. Reported figures for this pattern land in the 15–23× range; I haven’t benchmarked it on this corpus.
The rest follows from those. A single curated layer can serve people querying in different languages without duplicating documents per market, and the change log gives every page a provenance trail.
Independent project, not affiliated with or endorsed by BMW.