[데이터사이언스 세미나] 2026년 03월 04일(수), Google Cloud Alon Halevy

Main ideas & lessons

1) The talk’s theme: combining data management with AI (“data management meets its AI partner”)

Alon Halevy frames the promise of GenAI as reducing classic data-management obstacles:

• People can ask questions about data without needing expert SQL/data knowledge.
• AI can interpret not only structured tables but also unstructured data (text/images/audio/video).
• AI can help build and maintain data pipelines so more people can contribute and troubleshoot.

2) Why this is difficult right now

Data science/data management pain points today:

• Getting actionable insight from large, complex warehouses is hard.
• It requires deep expertise (schema/layout/table structure understanding, SQL capability).
• Much of enterprise data (especially unstructured) isn’t accessible to typical query systems.
• Data engineering pipelines are hard to build, maintain, and debug.

LLM limitations (especially on structured data):

• LLMs are strong at reading text and images.
• LLMs struggle with tables/structured query semantics—described as an “Achilles heel.”

The AI ecosystem is moving fast and is confusing:

• Expect contradictory viewpoints and trial-and-error.
• Many tool approaches will fail; progress won’t be a straight line.

3) The “crossing the structure chasm” goal (bridging structured & unstructured querying)

• Halevy describes a long-standing research vision (“Crossing the Structure Chasm”) to let users ask for answers regardless of whether the underlying data is structured or unstructured.
• He argues the field is “very close” now, mostly due to improvements in AI/LLMs.

4) A methodology lesson: don’t solve two hard problems at once

Halevy recounts an earlier “neural databases” effort (e.g., extracting structured facts from sentences, then answering SQL-like queries).

Key failure lesson:

• They tried to handle multiple challenges simultaneously (neural extraction + natural-language query understanding).
• Conclusion: solve one problem at a time; keep the system more controlled and less “guessy.”

5) Modern approach: “LLM operators” inside the database/query layer

Newer systems aim for structured-query workflows while allowing specific spots to call an LLM.

Core idea:

• Keep database semantics (sets, joins, aggregations) and insert LLM-powered predicates/steps where needed.

Common operator categories:

1. LLM-evaluated conditions/predicates

   • Example: classify whether a review complaint mentions “battery degradation.”
   • Example: determine whether a city has great weather in a specific month.
   • Example: detect whether agent responses addressed customer complaints.

2. LLM-driven joins

   • Join tables even without explicit join keys by using LLM reasoning over content relationships (e.g., actors and movies linked by narrative mentions).

3. LLM-driven aggregates

   • Example: “Top 5 reviews that match our marketing material” (semantic fit).
   • Example: “10 funniest paper titles.”

Google Cloud example:

• BigQuery “AI operators” are highlighted as LLM-enabled SQL capabilities.

6) Risks and constraints with LLM-in-query approaches

• Reliability/knowledge issues

  • LLM knowledge may be incomplete or biased (e.g., better coverage for Europe vs. Africa due to training language distribution).
  • Ambiguity risks (e.g., “Florence” could refer to multiple places).
  • LLM may lack company-specific/internal context unless explicitly provided.

• Cost/performance risks

  • Running an LLM on every row at scale is too expensive.

• Semantics shift vs SQL

  • SQL queries have deterministic “right answers” (semantic guarantee).
  • LLM outputs are “best effort” and may vary across runs.
  • Therefore, query expectations should shift toward insight rather than single exact truth—while still enabling responsible human judgment.

7) Optimization direction: “proxy models” to reduce LLM cost

Proposed strategy (described as an upcoming paper):

• For expensive LLM-evaluated conditions:
  1. Evaluate a small sample (e.g., the first few thousand rows) using the LLM.
  2. Use those labeled results to train a proxy predictive model (e.g., linear regression).
  3. Apply the proxy model to the remaining rows cheaply.

Goal: preserve much of the LLM benefit at a fraction of the cost.

---

Ecosystem ideas outside the database

8) Democratizing access: NL-to-answer with follow-up questions

Goal:

• Let non-SQL users ask questions in natural language.

How it should work:

• The system translates into SQL/Python/visualization steps behind the scenes.
• Follow-up questions should be treated as contextually related (e.g., “California last quarter?” → “What about Texas?”).

Key requirement:

• Users must trust correctness; providing raw SQL is not enough—interpretation and verification matter.

9) Data engineering agents (pipeline building and debugging)

Motivation:

• In large enterprises, pipelines can have thousands of nodes; troubleshooting/modifying them is heavy work.

Capability described:

• An agent that can:
  • Build pipelines from instructions.
  • Explain why pipeline outputs are wrong.
  • Support modifications as business needs evolve.

10) Why NL-to-SQL works in practice: metadata quality is the bottleneck

Halevy argues text-to-SQL methods aren’t the main issue.

Main issue: metadata

• Schema alone isn’t sufficient.
• Models need good table/column descriptions, lineage, and meaning.
• If metadata is weak, the model must “guess,” which is dangerous.

Nuance:

• Similar-looking tables/schemas differ by origin/purpose (production vs. experiment/report usage), affecting correctness.

11) Proposed solution: a “metadata reasoner” agent

Concept:

• An agent that understands metadata (schema + descriptions + lineage + quality + usage patterns).

When a user asks a question, the agent should:

• Determine which data sources/tools to use.
• Explain why they’re sufficient.
• Hand selected sources to an NL-to-SQL engine to generate correct SQL.

12) “Deep data research” (business-level questions, not just data-level queries)

North star:

• Move from asking data questions to asking higher-level business questions directly.

Example scenario (toaster company in Sweden):

• Business question: Which country should be the next toaster factory location?
• Decompose into multiple data subproblems:
  • Identify countries with toaster supply-demand gaps.
  • Identify countries with appropriate labor/specialized workers.
  • Account for regulations/tariffs/ease of operating/hiring.
• Combine outputs to produce a recommendation.

13) Personal context matters: agents must know “who you are”

• Answer quality depends on the user:
  • Different departments (finance, legal, supply chain) care about different interpretations.
  • New employees vs. long-time staff need different guidance.
• Halevy ties this to his broader vision of personalized agents (“AI partner”):
  • Agents should understand preferences/values and adapt recommendations accordingly.
  • He suggests future agents that don’t know the user will be far less useful.

---

Well-being and “AI partner” operating system

14) Capturing life data + conversational AI for advice (with privacy)

Halevy frames “AI partners” via well-being:

• Much of life is already captured (transactions, media consumption, sleep/workouts, etc.).
• Conversational AI can ask about subjective experiences and form a detailed personal picture for better recommendations.

Constraint:

• The system should be privacy-preserving (data access controlled and limited in duration/task).

15) “Well-being operating system” vision (3 pillars)

Holistic rather than isolated apps:

• The operating system connects well-being aspects instead of treating them as separate tools.

Not an overbearing planner:

• It should do what computers do best (memory, fast analysis),
• while humans do what humans do best (creativity, learning from mistakes).

Three pillars:

• Experiences

  • Store/organize knowledge about the person’s past:
    • good/bad/ordinary experiences
    • future plans and aspirations
    • subjective thoughts via journals
  • Foundation idea: a “personal timeline” / personal history graph.
  • Privacy angle: data doesn’t need to be centrally stored; it can be retrieved on demand.

• Attention

  • Use knowledge of the person to:
    • recommend when asked (or sometimes proactively)
    • plan tasks/trips/research and offer options for better decisions

• Connection

  • Support and improve quality of:
    • personal relationships (people)
    • community affiliations
  • Help ensure people receive the right support when needed

16) Example personal-data system: “personal timeline”

• Halevy mentions work on a “Timeline Builder” project (referenced as available on GitHub).
• It integrates multiple personal data sources:
  • shopping/reading/workouts/photos/journals
• He notes improved ability and time reduction when rebuilt with more advanced tools in later years.

---

Concluding claims

Halevy’s wrap-up points:

• He’s enthusiastic about AI/LLM operators because they realize a long-standing dream.
• Data management will become easier and enable more interesting queries.
• Personal AI partners are likely inevitable—either as a single general agent or specialized-agent ecosystems.
• Progress must still be responsible:
  • privacy
  • equity
  • guardrails and aligned values

---

Methodology / instruction-like steps explicitly mentioned

A) Optimizing expensive LLM evaluations inside queries (proxy-model approach)

1. Identify query predicates/conditions that require LLM evaluation.
2. Select an initial sample (e.g., first few thousand rows).
3. Run the LLM on the sample to label outputs (treat LLM answers as “ground truth” for training).
4. Train a lightweight proxy predictive model (e.g., linear regression) on:
   • row inputs → LLM-labeled outputs
5. Apply the proxy model to the remaining rows to approximate LLM decisions cheaply.
6. Use this as a query-optimization technique to keep results close while reducing LLM spending.

B) Assembling “deep data research” for a business recommendation

1. Start with a business objective (e.g., “which country for the next factory?”).
2. Decompose into multiple relevant data problems:
   • demand/supply gap detection
   • skilled-labor availability
   • regulations and operating constraints
3. Retrieve/answer each data problem via data agents.
4. Combine outputs into a unified recommendation.

---

Speakers / sources featured (identified)

Speakers

• Alon Halevy (main speaker; Google Cloud Distinguished Engineer; author of The AI Partner)
• Sang (an attendee/host who greets and introduces; asks to start)
• David Sullivan (audience member; professor mentioned; asks about ethics)
• Audience questioner(s) (at least two additional Q&A participants, names not provided)
  • One asks about metadata/knowledge graphs vs. natural-language metadata
  • One asks about the future state of AI and what young people should study
• “Gemini” (mentioned as the AI system that generated the talk title; not a human)

Organizations / products / external references mentioned

• Google Cloud / BigQuery
• Meta (Facebook) (historical research work; “neural databases” team mentioned)
• Stanford and Berkeley (for “Lotus” system; referenced as key authors/system family)
• Timeline Builder (GitHub project mentioned)
• Vanavar Bush (historical “mimic system” inspiration; mentioned)
• Tim Berners-Lee (web inspiration mentioned)
• Paul Allen Institute for AI (AI2) (mentioned via former student connection)
• A research paper: “Crossing the Structure Chasm” (2003; described by Halevy)
• Research area: text-to-SQL literature (mentioned but Halevy downplays its importance)