Why does document search struggle with tables?
Retrieval systems split files into chunks, turn each chunk into an embedding and fetch the closest matches to a question. That works for paragraphs. A spreadsheet chunk might hold rows 400 to 450 without the header row, so the model sees numbers without knowing which column they belong to. A question that needs a total across 3,000 rows cannot be answered from the handful of chunks a retriever returns. Some file search tools do not accept spreadsheets at all: OpenAI's file search lists formats such as .docx, .pdf, .pptx and .txt, and .xlsx and .csv do not appear in that list.
How does a model query a database safely?
In this pattern, often called text-to-SQL, the model receives descriptions of the tables and the user's question, and writes a query. Your application runs the query and passes the rows back for the model to explain. OpenAI's function calling guide describes this division: the model suggests a call, and your code executes it and returns the result. That split is where the safety controls go. Run queries with a read-only database account, limit which tables and views are visible, cap rows and run time, and log every query with the user who asked it.
Permissions belong in the database. Microsoft's row-level security for SQL Server and Azure SQL uses group membership or execution context to control which rows a query can return, so a regional manager's question only sees their region even if the generated query forgets to filter. Relying on the model to add the right WHERE clause is not a control.
When is running code over a file the better fit?
For one-off analysis of an exported file, a code execution tool can load the spreadsheet and calculate with real code. OpenAI's code interpreter, for example, lists .csv and .xlsx among its supported files, and self-hosted deployments can run an equivalent sandbox on their own infrastructure. The model writes and runs a short program, and the answer comes from the program's output, which you can inspect. This suits ad hoc questions about a report someone has exported. It suits live operational data poorly, because the file is a snapshot and the source system's permissions no longer apply once the export has been uploaded.
Are fixed reports simpler than open-ended queries?
Many structured-data questions are predictable: monthly totals, open items by owner, overdue invoices by customer. For these, build a small set of tested queries or report endpoints and give the model one tool for each, with parameters such as month or region. The model chooses the tool and fills in the parameters, and it never writes free-form SQL. You lose some flexibility. In return, the answers match the figures in your existing reports, which matters when finance staff or a board will compare them.
How do you keep the numbers in an answer trustworthy?
Even with correct data, the written explanation can introduce errors, for example by restating a total from memory or mixing up two periods. Design the answer so that a reader can check it against the source in a few seconds, and so that a wrong figure is easy to spot in review. The display rules below help with both. They also make feedback reports more useful, because staff can say which step went wrong.
- Show the figure from the query result, not a number the model restated in its own words.
- Display the query or report name and the time the data was read.
- State the filters applied, such as date range and business unit.
- Round only in presentation, after the calculation.
- Refuse and explain when the question needs data the tools cannot reach.
How should you test structured-data answers?
Build a test set of questions with known answers taken from your existing reports. Include simple lookups, totals across periods, questions with no matching data, and questions a user should not be able to answer because of their role. Run each question as several different users to confirm that row-level permissions hold. Hypothetical example: a 40-question set might hold 15 lookups, 15 aggregations, 5 empty-result questions and 5 permission checks; these numbers are illustrative only. Rerun the set after any change to the schema, the model or the tool definitions.