The Tables That Didn't Exist

Chapter 2 — The Tables That Didn't Exist

A technician from a mechanical company in the Northeast told us this over an espresso, with that Venetian calm that foreshadows disaster: "Our chatbot knew everything about the engine. Except the engine data." He then explained. Their internal AI assistant could describe product ranges, application contexts, brand history, and competitive advantages. A marvel, on a narrative level. But when a customer asked for the nominal torque of the CMP50L model — that is, the technical data for which people open the catalog, the number for which they buy an engine — the chatbot would respond vaguely, sometimes plausibly, sometimes not. Five months of development, the operations manager increasingly perplexed, and no one knew why.

The diagnosis arrived by chance, almost out of boredom, while manually inspecting the database after yet another inconclusive meeting. The PDF catalog contained 342 technical tables. Zero had arrived in the database. Not a handful: zero. None. The code that extracted the tables from the PDFs saved the data in fields called columns and data, while the code that then indexed them expected fields called headers and rows. An unrespected "synonym". An internal convention that had been skipped in a forgotten refactoring. The result, for five silent months: the entire numerical intelligence of the catalog — pairs, powers, diameters, weights, order codes, supply voltages — had flowed from the tap without ever being poured into the glass. Three hundred and forty-two tables, lost one by one in liturgical silence.

This is the kind of bug that doesn't shout. It doesn't raise exceptions, doesn't crash anything, and doesn't appear in any logs. Simply, a part of the world ceases to exist for your system, and no one notices until a user — usually an angry user — asks enough insistent questions to reveal the abyss. And it is emblematic of a much larger problem than field names: generic RAG frameworks are optimized for current text — articles, web pages, paragraphs of narrative — and treat tables as second-class citizens, when they treat them at all. But Italian business documents are often tables. Technical catalogs, price lists, product specifications, safety data sheets, order bulletins: the valuable part, for those consulting these documents, is the tabular one. The one that breaks first and that no one notices.

The lesson isn't "be careful with field names". It's more uncomfortable: in a serious RAG, every type of content — tables, images, alphanumeric codes, paragraph titles, footnotes — needs dedicated, designed, and tested handling. And the functionality test isn't "the chatbot answers trivial questions" — even broken systems answer those, because there's enough floating data to build something plausible. The real test is "the chatbot answers questions that force it to touch every single piece of the pipeline". Specific, numerical, verifiable questions. Questions for which there is a right and only one answer, and if the system fails, you know it immediately.

If you don't do this test, you don't know if your RAG works. You only know it isn't complaining. And "not complaining" is a very low quality criterion for a system that people will use to make decisions.