EyeLevel Launch: Your RAG is Tripping, Here's the Real Reason Why

How do you turn uploaded documents into content an AI application can reliably retrieve? EyeLevel’s starting promise is a short path: upload documents through no-code tools or APIs, then receive retrievals within minutes. Co-founder Benjamin Fletcher brings experience from IBM Research, IBM Watson, and work with brands including The Weather Channel. He describes EyeLevel as the world’s most accurate and scalable RAG platform, developed over four years beginning with early access to the GPT-3 beta.

Getting started with retrieval-augmented generation is easy; mastering it becomes difficult when the knowledge base contains complicated enterprise documents. Fletcher reports that, in EyeLevel’s experience, RAG applications can have error or hallucination rates as high as 35%. His diagnosis points upstream of generation: the retrieved content may already be incomplete, distorted, or irrelevant before the LLM sees it.

The failures fall into three categories:

• Bad text extraction: the extracted words do not faithfully represent the source.
• Missing context: chunking separates a passage from information elsewhere in its document.
• Missing visual information: tables, charts, and other visual elements never reach the retrieval system.

The quality of the answer depends on the evidence that survives ingestion. Fletcher argues that fixing these failures with advanced RAG techniques can take hundreds of implementation hours; EyeLevel packages that data-engineering work into its ingestion pipeline.

Fletcher reports that customers including Air France and Dartmouth say their applications respond correctly more than 95% of the time. He also cites an unnamed study reporting 98% accuracy on complicated real-world documents and up to 120% outperformance over popular competing solutions. The talk does not specify the study’s evaluation protocol, identify the comparators, or define the outperformance calculation, so those figures describe the results Fletcher reports rather than a reproducible comparison supplied in the walkthrough.

EyeLevel’s architecture does not use a vector database. Instead, it creates semantic objects and searches across multiple attributes of each object. Fletcher questions whether vector databases are the best fit for many RAG applications; the alternative he introduces is a richer unit of retrieval than an isolated passage of extracted text.

Air France provides the concrete setting. At the time of the talk, the airline had been using EyeLevel for a year to build a ChatGPT-like copilot for call-center agents. Its knowledge base contains hundreds of thousands of documents, including pages with tables, figures, and text scattered across the layout. Understanding such a page requires identifying its different components before deciding how to extract them.

The ingestion sequence begins with a vision model that locates images, tables, and text. Fletcher says EyeLevel fine-tuned this model with millions of documents. Dedicated multimodal processing pipelines then extract the written and visual information from those regions. The slide labels the detector GroundX Vision Model and shows colored region annotations over an Air France document containing a passenger photo, a table, and text. Region detection is the first step; extracting the meaning within those regions is the next.

Even a correctly extracted document can lose meaning when split into smaller chunks. A passage may no longer carry the section it belongs to—or even the identity of its document. Fletcher compares this to asking questions about a book and receiving random paragraphs: the paragraphs can be accurate while still being poor evidence for an answer.

A semantic object retains the original chunk and adds automatically generated metadata that preserves surrounding information. It also contains two rewrites, each serving a different purpose:

The distinction between the last two fields matters: text that helps find a passage need not be the same text that best helps a model answer from it.

For a small book example, suppose a chapter titled “Seedling care” contains the sentence “Water them daily.” A representation of the described structure could be:

{
  "originalText": "Water them daily.",
  "metadata": {
    "document": "A Beginner's Gardening Guide",
    "section": "Seedling care"
  },
  "searchText": "Seedling care: daily watering frequency.",
  "completionText": "The Seedling care section of A Beginner's Gardening Guide recommends watering seedlings daily."
}

Here the original sentence remains intact, while the surrounding context resolves what “them” refers to. These illustrative field names express the mechanism, not an SDK contract. Current GroundX API concepts document semantic objects, but the walkthrough describes the historical architecture rather than a current API integration.

The next demonstration returns to a figure from an Air France document. Fletcher first shows the result of a familiar sequence: OCR the figure, extract its text, vectorize that text, and place it in a vector database. He then points to information lost along the way and contrasts that result with EyeLevel’s ingestion output, which includes both the search and completion versions of the text.

The comparison turns on what reaches the index. Recognizing words inside a figure does not necessarily preserve the information conveyed by their arrangement or visual relationships. Once extraction has omitted information, vectorizing the remaining text does not restore it. EyeLevel’s demonstrated response is to process visual and written information during ingestion, then produce representations suited to finding that information and using it in an answer.

At query time, the system applies a corresponding transformation to the user’s request:

1. Rewrite the query into a format compatible with the semantic objects.
2. Search multiple fields: the original text, automatically generated metadata, and search rewrite.
3. Rerank the candidates with a fine-tuned LLM to improve the ordering of the results.

The completed pipeline slide labels the middle stage “Weighted Search of Semantic Objects.” The completion rewrite is part of the object, but Fletcher’s enumeration of searched fields specifically names the original text, metadata, and search version.

Fletcher says ingestion and search together use more than nine fine-tuned models. The platform’s promise is to make that machinery available without requiring each application team to assemble it: enterprise-quality, production-ready applications in minutes rather than months. He closes by inviting viewers to try EyeLevel’s XRay. The technical substance behind that invitation is the full sequence just demonstrated—extract the document’s information, preserve the context of each chunk, create separate search and completion representations, and retrieve through query rewriting, multifield search, and reranking.