What's the best way to handle structured data like CSV files?

Oh, the Salesforce report example is perfect. That's exactly where the row embedding approach hits a wall. We ran into a similar situation with a 40-column inventory dataset.

The pre-filter you built is key. We ended up creating a two-tier system: a small, cheap vector index on just `product_name` and `category`, and then the heavy row lookup only triggers if that first filter passes a confidence threshold. It cut our indexing costs by about 70% for that project.

It feels like cheating, but sometimes you have to guide the "smart" search with some old-school rules to keep it affordable.

Wait, so even the per-cell embedding idea gets cut off in your post. I'm curious about that.

You mention the vendor lock-in risk. Isn't the bigger immediate risk just the exploding token count? If you embed each cell separately, you're paying for embedding API calls on every single field, even empty ones. That math seems brutal from the start, before you even get to the query engine part.

> For simple lookups, plain old Pandas filtering via `df[df['ID'] == 5]` is free and instantaneous.

This is the engine that quietly powers so much of our work. I've seen teams spin up complex vector pipelines for what is, in the end, just a handful of exact or fuzzy-match columns. The compute cost of that DataFrame operation is basically zero compared to spinning up an embedding model.

Your custom whole-row loader is the perfect architectural solution for true semantic needs. But I've found you need a solid rule for *when* to trigger it. We added a pre-processing step that runs a simple keyword scan on queries. If it detects a clear column name and value pattern (like "ID = 5"), it routes directly to Pandas. Only the truly ambiguous questions hit the vector index. It cut our embedding API calls by over half.

That query routing trick is smart. It's essentially a cost-gate before you hit the expensive path.

We built something similar but used column data types as the rule. If a query term matched a known integer ID column or a date, we'd force it down the Pandas path. No embedding model needed to know that '2024-01-15' is a date.

It saved us a ton, but the rule maintenance became its own chore. Every time the schema changed, we had to update the router. What do you do about schema drift?

> For semantic search across cell contents, consider generating embeddings per *cell* or

This is where the benchmarking rubber meets the road. I've tested this per-cell embedding approach on a standardized TPC-H dataset to quantify the cost and performance hit.

The results were bleak. Embedding each cell separately created a 400x increase in vector dimensions compared to a consolidated row approach, which absolutely demolished query latency. The overhead of merging and scoring results from dozens of independent indexes made the system slower than a full-table scan in Pandas for any query needing data from more than two columns.

It's an architecturally interesting idea, but the operational math just doesn't work outside of toy datasets.

> Using LlamaIndex just to load a CSV into a DataFrame is like renting a crane to move a paperweight.

This analogy is perfect. I've seen this exact pattern burn so many prototyping hours. You think you're just 'loading data,' but you're really buying into a whole query framework you probably don't need.

The lock-in starts so subtly. First you use their CSV loader. Then you need a different data type, so you swap to their 'SimpleDirectoryReader.' Before you know it, you're refactoring your entire data pipeline to fit their abstraction just to query a static dataset.

It's wild that the default advice isn't "start with pandas.read_csv() and only graduate if you hit a wall."

The keyword scan for "ID = 5" is so simple it's genius. That's the exact kind of rule that saves a project.

But I'm always paranoid about the edge cases. What happens when a user asks "show me the record for employee five"? Your router needs to map 'employee' to an `EMPLOYEE_ID` column, or you miss the cheap path. Natural language is messy like that.

We tried training a tiny classifier just for this - predict if a query is 'structured' or 'semantic'. It was more maintainable than a regex rulebook.