A product team may need to compare usage behavior with what customers say in interviews. Product usage data is structured and can be queried with specialized approaches such as Text2SQL; interview and sales-call records are unstructured and may call for retrieval-augmented generation. Choosing a source therefore means choosing an appropriate way to access and analyze it, not just collecting everything in one place. section 9.1.1 section 9.1.1
Structured data is information arranged to meet a defined format or schema. That matters both when querying existing data and when asking a language model to produce data another part of a workflow can reuse. By default, model responses may be lengthy and unstructured; a prompt can instead specify a format such as JSON or CSV and name the required fields. section 6.4.1 section 9.1.1
From a response to a reusable table
Suppose someone wants an overview of companies developing space tourism. A general request may produce a list that still needs parsing. Asking for JSON with each company’s name, founding year, location, employee count, and main selling point produces a more concise result that can be reused for tables or visualizations. section 6.4.1
When structured data comes from a language model, a requested format is only one control. Match the safeguard to the workflow:
- Specify the output format and fields in the prompt when downstream work needs a predictable shape. section 6.4.1
- Consider constrained generation, function-calling models, or API structured-output options when the application needs tighter control. section 5.2.3
- Validate generated data against a predefined schema; offline processing also allows additional output validation. section 5.2.3
For an agent drawing on several sources, start with the most important ones and add others as confidence grows. Structured usage data can reveal actual behavior, while sales calls capture different kinds of need; neither source answers every product question on its own. section 9.1.1
