Structured vs Unstructured Data: Which Does Your AI Need?

AI applications consume both structured data (database records, API responses, spreadsheets with typed columns) and unstructured data (documents, emails, web pages, chat logs). Each type requires a different ingestion approach, and most production systems need to handle both. This guide explains the differences, the techniques for preparing each type for AI consumption, and the architectural decisions for combining them in a single knowledge base.

What Makes Data Structured or Unstructured

Structured data has a predefined schema that describes the type, format, and meaning of each field. A database table has columns with names, data types, and constraints. A CSV file has headers that label each column. An API response has a JSON schema that defines which fields are present and what values they can contain. The structure is explicit: a program can parse the data and access any field by name without understanding the content.

Unstructured data has no predefined schema. A PDF contains text that might discuss anything. An email body is free-form prose. A web page combines paragraphs, headings, images, and navigation in whatever structure the author chose. The meaning is embedded in natural language that requires interpretation, not in a schema that a program can query directly.

Semi-structured data falls between the two. JSON documents have structure (key-value pairs, nested objects, arrays) but variable schemas (different documents can have different fields). Log files follow patterns (timestamp, severity, message) but contain free-text messages. Emails have structured headers (from, to, date, subject) and an unstructured body. Semi-structured data requires a hybrid approach that extracts the structured fields into metadata and processes the unstructured portions as text.

In practice, most enterprise knowledge is a mix of all three types. A customer relationship management system stores structured records (customer name, plan tier, contract value) alongside unstructured notes (call summaries, support ticket descriptions, sales team comments). A product database has structured specifications (weight, dimensions, price) alongside unstructured descriptions and reviews. Building an AI system that can reason about this combined knowledge requires an ingestion pipeline that handles each type appropriately.

Ingesting Unstructured Data

Unstructured data is the default input for LLM applications because language models are trained on text and process it naturally. The ingestion pipeline for unstructured data follows the standard flow: extract text from the source format (PDF, HTML, DOCX), clean and normalize the text, add metadata, validate quality, and output the cleaned document. The document parsing guide and the web scraping guide cover the source-specific techniques.

The main challenge with unstructured data is preserving the structural context that helps both embedding models and LLMs understand the content. A document with headings, sections, and paragraphs has an organizational structure that conveys meaning: the heading tells you what the section is about, the first paragraph introduces the topic, and subsequent paragraphs elaborate. When this structure is lost during extraction (headings merge with body text, sections are not delineated), the resulting flat text is harder to chunk effectively and harder for the LLM to navigate when it appears as retrieved context.

Layout-aware parsers that produce typed elements (heading, paragraph, table, list) preserve this structure, enabling section-based chunking that creates retrieval units aligned with the document's own organization. This produces measurably better retrieval results compared to fixed-size chunking on flattened text, because each chunk represents a coherent topic with its heading as a natural summary.

Ingesting Structured Data

Structured data requires a fundamentally different approach because feeding raw records to an LLM often produces poor results. Consider a database row: {"customer_id": 12345, "plan": "enterprise", "mrr": 4200, "churn_risk": 0.73, "last_contact": "2026-08-15"}. An LLM can parse this JSON, but it lacks the context to reason about it effectively. What is a normal MRR for enterprise customers? Is 0.73 churn risk high or low? What happened during the last contact?

Textualization solves this by converting structured records into natural language descriptions that carry the same information in a form the LLM can reason about. The same record becomes: "Customer 12345 is on the enterprise plan with monthly recurring revenue of $4,200. Their churn risk score is 0.73, which is above the enterprise average of 0.31 and indicates elevated risk of cancellation. The last customer contact was on August 15, 2026." This text embeds well (the embedding captures the semantic meaning of the record), retrieves well (a query about "enterprise customers at risk of churning" will match), and generates well (the LLM can cite specific details in its answer).

The textualization process involves three decisions. First, which fields to include. Not every column in a database table is relevant for AI retrieval. Internal IDs, audit timestamps, and system flags add noise without value. Include fields that a human would need to answer questions about the record. Second, how to phrase the description. Use natural, readable language rather than mechanical field-value pairs. "Monthly revenue is $4,200" is better than "mrr: 4200". Include units, explain abbreviations, and provide context for values that are not self-explanatory. Third, how much context to add. The textualized record should be self-explanatory without external knowledge. If the churn risk score of 0.73 is only meaningful in comparison to the average, include the average.

One approach that works well for large tables is to generate a textualized document for each row and also create a separate summary document that describes the table's schema, the meaning of each field, and aggregate statistics (averages, ranges, distributions). This summary provides the context that individual row descriptions lack, and the retrieval system can pull both the specific record and the contextual summary when answering questions that require both detail and context.

Combining Structured and Unstructured Data

Production AI systems rarely work with only one data type. A customer support AI needs product documentation (unstructured), customer account records (structured), and support ticket history (semi-structured). A legal AI needs contracts (unstructured), case metadata (structured), and court filings with structured headers and unstructured opinions (semi-structured). The ingestion pipeline must handle all types and produce a unified knowledge base that the retrieval system can search across.

The unification happens through the common document format. Whether a document originated from a PDF, a database row, or an API response, after ingestion it is a text document with metadata. The PDF becomes a text document with metadata like {source_type: "document", file_name: "product-manual.pdf", department: "engineering"}. The database row becomes a textualized document with metadata like {source_type: "database", table: "customers", customer_id: 12345}. The retrieval system treats them identically: both are chunked, embedded, and indexed, and both can be retrieved in response to user queries.

The metadata enables filtered retrieval that respects data type boundaries when appropriate. A query about "enterprise pricing" might search only product documentation (source_type: "document") because pricing details are in the docs, not in customer records. A query about "Customer 12345's current plan" should search only customer records (source_type: "database", customer_id: 12345) because the answer is in the structured data. The retrieval system can apply these filters based on query analysis or explicit user intent, producing more precise results than searching the entire unified knowledge base indiscriminately.

Semi-Structured Data Patterns

Semi-structured data combines structured fields with unstructured content. The ingestion approach extracts the structured fields into metadata and processes the unstructured content as text, producing a document that has rich metadata for filtering and clean text for retrieval and generation.

JSON documents with variable schemas are common in API responses and NoSQL databases. The ingestion approach flattens nested structures into key-value metadata where possible and textualizes the remaining content. A JSON document describing a product might have structured fields (name, price, category, SKU) that become metadata and unstructured fields (description, reviews, specifications_text) that become the document content.

Email threads have structured headers (from, to, date, subject, thread ID) and unstructured body text. The headers become metadata that enables filtered retrieval (search emails from a specific sender, in a specific date range, about a specific subject). The body text is extracted, cleaned (removing signature blocks, quoted previous messages, and disclaimer text), and ingested as the document content. For email threads with multiple messages, each message can be a separate document linked by thread ID, or the entire thread can be a single document with messages in chronological order, depending on whether the retrieval use case favors individual messages or complete conversations.

Log files follow patterns but contain free-text fields. The structured components (timestamp, severity, service name, request ID) become metadata. The free-text message becomes the document content. For AI applications, log ingestion is typically selective: only error and warning messages are worth ingesting, because the volume of info-level logs is too high and the content is too routine to be useful for retrieval.

Common Mistakes

The most common mistake is ingesting structured data in raw format without textualization. A knowledge base full of JSON records or CSV rows will embed poorly, retrieve unpredictably, and produce generated answers that include raw data formatting rather than natural language explanations. If the LLM's retrieved context is {"mrr": 4200, "churn_risk": 0.73}, it cannot provide the context and interpretation that a textualized version enables.

The second common mistake is losing structural context from unstructured data. When a parser flattens a well-organized document into a single text string, the heading hierarchy, section boundaries, and list structure are lost. Downstream chunking then splits the text at arbitrary positions rather than at natural topic boundaries. Preserving structural annotations (element types, heading levels, section labels) during parsing costs minimal additional effort and significantly improves chunking and retrieval quality.

The third common mistake is treating structured and unstructured data as completely separate systems. Building two independent knowledge bases, one for documents and one for records, creates a retrieval gap where questions that require information from both sources cannot be answered by either system alone. The unified approach, where all data types are processed into a common document format and indexed together, enables cross-source retrieval that matches the way humans actually ask questions.

The fourth common mistake is ignoring metadata during ingestion. Documents without metadata are anonymous text fragments that cannot be filtered, attributed, or contextualized. Investing the effort to extract and attach comprehensive metadata at ingestion time pays dividends in retrieval precision, answer attribution, and debugging throughout the life of the knowledge base. The pipeline building guide covers metadata extraction as a core pipeline stage.