Source-linked AI summary
OCTOPUS: Towards A Tag Model for Cross-Query Reuse in Semantic Query Processing
GuangXue Zhang, Nada Lahjouji, Yiming Lin, Ashwin Colaco, Sharad Mehrotra
TL;DR
Many semantic query systems discard model judgments after a query, so later queries pay again. OCTOPUS stores judgments as database tags and reuses related answers; on SemBench’s movie scenario, it sends models 10 to 108× fewer rows and pairs than four baselines at competitive quality.
Problem
Semantic query systems commonly discard model judgments after each query, repeating the cost when later queries need them.
Source: §1 · p. 2Method
Results
On SemBench’s movie scenario, OCTOPUS judges 10 to 108× fewer rows and pairs than four baselines, at competitive quality.
Source: §1 · p. 2Takeaways & Limitations
A database can grow its semantic schema from users’ questions while retaining judgments with provenance and keeping answers consistent as models change.
Source: §6 · p. 6Tag maintenance must account for changes to data, models, and prompts, while semantic staleness remains without a full treatment.
Source: §6 · p. 6
Abstract
from arXiv · showhide
Large language models make it possible to pose semantic questions over diverse, multi-modal data. Recent systems give such workloads the declarative feel of a database through semantic operators: relational operators whose conditions a model judges. Most of them now run on a relational engine, yet almost none keeps what the model says past the query: every judgment is discarded on completion and paid for again the next time a query needs it. We present the tag model and tag operators, the right unit for semantic processing, and OCTOPUS, a prototype built as a middleware over DBMS. Two mechanisms are central. First, the tag: each semantic answer a model produces is written back to the relation as data, which the database engine filters, indexes, and stores as it would any other. Second, the tag operator: the unit into which common semantic operators are translated, which fixes the granularity of reuse. A model judges a tuple once, and later queries reuse that judgment as data: through relationships between predicates, a stored judgment can accept a tuple for a later predicate, eliminate one that cannot satisfy it, simplify its test, or order the search of a query that stops early. On the movie scenario of SemBench, our prototype sends the model 10 to 108x fewer rows than iPDB, ThalamusDB, Palimpzest, and LOTUS at broadly competitive quality, and three of its eight queries issue no model call at all. More broadly, a database that keeps its judgments lets its schema grow from the questions its users ask, so that each semantic answer is paid for once, stays consistent across queries, and can be audited through its provenance.
1 INTRODUCTION
Semantic queries over unstructured data require model judgments, but existing systems often discard those judgments between queries even when predicates overlap. OCTOPUS stores judgments as tags and reuses them at tuple-level granularity, reporting substantially fewer model inputs on the SemBench movie scenario.
1 INTRODUCTION
- Semantic questions concern unstructured meaning, and their predicates are unknown when schemas are designed because users phrase questions in their own terms.Examples include searching for Christmas-themed gifts or films suitable for young children.Source: §1 · p. 1
- Semantic judgments often overlap across queries, but systems that discard them cannot reuse that work or apply database-style pruning and reordering.Semantic operator systems express conditions such as filters, maps, and joins in natural language for an LLM to judge.Source: §1 · p. 1
- The comparison covers planner optimization, semantic-operator optimization, DBMS integration, and caching; cache support differs in whether reuse crosses queries and requires identical prompts.The table caption identifies full, partial, and no support with circles; it does not state the systems’ individual scores in the supplied passage.Source: §1 · p. 1, Table 1 · p. 2
- A tag stores a model’s answer as ordinary database data, while a tag operator makes one tuple-level judgment the unit of reuse.This granularity lets later tag operators reuse stored answers instead of limiting reuse to an identical whole-table question.Source: §1 · p. 2
- Relationships between predicates let stored judgments accept or eliminate tuples, simplify later tests, or order evaluation for queries that stop early.OCTOPUS is presented as a DBMS middleware prototype, and the paper argues that its tags let a database schema grow from users’ questions.Source: §1 · p. 2
- OCTOPUS judges 10 to 108× fewer rows and pairs than four baselines on SemBench’s movie scenario, at competitive quality.The prototype extends a DBMS with the tag model.Source: §1 · p. 2
2 THE TAG MODEL
The tag model stores model judgments as queryable database data, recording values and provenance so that later queries can reuse answers or decide whether to reevaluate them.
2 THE TAG MODEL
- A tag stores a predicate’s answer for a tuple (or tuple pair), using NULL for unevaluated tuples and ordinary SQL-backed columns or relations for storage.As tags fill, the database can filter and index judgments, and a fully populated tag can answer a semantic condition without a model call.Source: §2 · p. 2
- Tag provenance records confidence, model name, timestamp, and cascade stage, allowing later queries to reject low-confidence answers or resume at a later model stage.Timestamps also help identify answers produced before a model replacement or data update.Source: §2 · pp. 2–3
- The system checks tags before calling a model, sends only open tuples for evaluation, and writes returned answers back to tags.The paper distinguishes tags from whole-view materialization and exact-invocation caching by making each judgment a persistent, queryable database unit.Source: §2 · p. 3
3 TAG OPERATORS: THE RIGHT UNIT OF REUSE
Semantic operators are too coarse for cross-query reuse: OCTOPUS decomposes them into tag operators that persist individual model judgments. Later queries can reuse those judgments across operators, while database operations handle the remaining relational work.
3 TAG OPERATORS: THE RIGHT UNIT OF REUSE
- A complex operator such as sem_groupby hides per-review labels, so its answer is reusable mainly for the same question over the same data.A later query for example reviews on one complaint topic needs the per-review judgments sem_groupby already made.Source: §3 · p. 3
- Attaching an optimization to a map inside sem_groupby separates the operator’s logical meaning from its physical implementation.A cascade [1] [6] designed for one per-tuple judgment can be applied without changing sem_groupby’s meaning.Source: §3 · p. 3
- A single model judgment on a tuple or tuple pair—not a semantic operator—is the unit of reuse and optimization.Persisting that unit lets a per-review label serve a group-by query and a later filter.Source: §3 · p. 3
3.1 The Tag Operators
- octo_filter and octo_map judge one tuple at a time, octo_compare judges a tuple pair, and octo_clustering groups tuples using embeddings.nest groups or summarizes rows with ARRAY_AGG and makes no model call or tag.Source: §3.1 · p. 3, §3 · p. 3
3.2 Translating Semantic Operators
- Table 2 translates semantic operators into tag and ordinary relational operators, with the translation adding no model calls.For the complaint-topic example, octo_map stores a label per review, octo_clustering groups labels, and SQL groups and counts them.Source: §3.2 · pp. 3–4, Table 2 · p. 4
- A separable sem_join costs |R| + |S| model calls after extracting tuple properties, while a non-separable join requires |R| × |S| pair judgments.The latter uses octo_compare; the former uses octo_map followed by sql_join.Source: §3.2 · p. 4
4 REUSING JUDGMENTS
OCTOPUS treats stored tag values as known facts that can settle or simplify later predicate tests. When they do not settle a test, tag-conditioned probabilities can guide decisions or the order of evaluation.
Reuse as entailment
- Predicate relationships and a tuple’s existing tags can accept it, eliminate it, or leave it open for a later request.A vegan predicate implies vegetarian, so a vegetarian tag that is FALSE eliminates a tuple from a vegan query; TRUE narrows the remaining test.Source: §4 · p. 4, Table 3 · p. 4
- A stored map value can answer range requests directly, and accumulated tags decide more tuples without a model when the data and predicate rules stay unchanged.For example, tag_map_calories = 200 lets SQL answer comparisons against a bound.Source: §4 · p. 4
Probabilistic reuse
- When tags do not entail a predicate or its negation, their conditional probability can guide acceptance or elimination only with a quality guarantee, or safely order an early-stopping search.Judged tuples also provide statistics for estimating correlations between predicates.Source: §4 · p. 4
Related ideas
- Unlike approaches that start with fixed schemas and rule sets, the tag model derives predicate relationships as queries arrive, but those rules are beliefs that model judgments may violate.The prototype’s Parser derives them from common knowledge; a taxonomy, knowledge graph, or ontology could supply them instead.Source: §4 · pp. 4–5
5 A FEASIBILITY STUDY: OCTOPUS
OCTOPUS uses an LLM-based parser and DBMS executor to run semantic queries and persist judgments for reuse. Its SemBench movie study measures savings from reuse within and across queries, alongside the quality trade-off.
5.1 The OCTOPUS Prototype
- The Parser separates relational from semantic predicates and emits a plan; the Executor filters and reads stored tags in SQL, judges open tuples, then writes answers back with provenance.The prototype batches calls and can run them concurrently; once needed tuples are settled, the query can be answered by the database alone.Source: §5.1 · p. 5
5.2 Case Studies
- 268 rows across Q1–Q8 versus 2,768 for iPDB, 17,240 for ThalamusDB, 17,038 for Palimpzest, and 28,910 for LOTUS; OCTOPUS uses 10×–108× fewer model-judged rows.Table 4 reports per-query model-judged-row costs for Q1–Q8.Source: Table 4 · p. 5, §5.2 · p. 6
- The feasibility study uses SemBench’s Rotten Tomatoes movie scenario, with 1,865 reviews, 116 movies with duplicates, gemini-2.5-flash, and 20 concurrent calls.Its cost measure counts rows or pairs judged by the model, independent of pricing and batching.Source: §5.2 · p. 5
- For family-friendly movies reviewed by a top critic, an input-keyed cache reduces Palimpzest’s model input from 448 joined rows to 81 distinct movies.The 81-row result matches the number of distinct movies in that query’s input.Source: §5.2 · p. 6
- Exact-match, complement, and taxonomy rules let Q4, Q8, and Q6 avoid model calls; later Q3 and Q7 reuse partial tags from Q2 and Q5.Q3 reuses 44 tuples settled by Q2’s LIMIT, while Q7 starts from 20 settled by Q5.Source: §5.2 · p. 6
- Reuse can carry earlier errors: Q6 reads tags left by Q5 and scores 0.58, while Q7 judges the remaining 128 reviews and scores 0.74.The passage notes that an inheriting query may repeat earlier incorrect judgments.Source: §5.2 · p. 6
- On Q7, OCTOPUS judges 108 rows at quality 0.74, versus 16,384 pairs for Palimpzest and ThalamusDB, 8,547 for LOTUS, and 257 rows for iPDB.The passage reports 0.74 as the best quality among the five systems; the others range from 0.24 to 0.73.Source: §5.2 · p. 6
6 FUTURE DIRECTIONS
The paper identifies open design questions for trusting reused judgments, maintaining tags, and relying on the Parser. It also points to optimizer and transaction issues that arise when semantic processing is brought into the database engine.
- The proposed direction is a user-grown semantic schema whose judgments are shared across applications and remain consistent as underlying models change.Source: §6 · p. 6
When to trust a reused answer
- Trusting reused answers remains open: confidence thresholds may trigger re-judgment, while inferred predicate rules add error risk and lack a settled evidence requirement or probability guarantee.The paper also leaves open how to combine per-rule probabilities into an ordering over open tuples.Source: §6 · p. 6
The tag lifecycle
- Tags need maintenance when tuples, models, or prompts change; eviction and filling NULL values can occur offline, but semantic staleness has no full treatment.The paper frames a tag as a partially materialized semantic view and relates its maintenance to view maintenance.Source: §6 · p. 6
The parser as the trusted base
Into the engine
- A cost-based optimizer could weigh model calls against I/O to reorder semantic and relational work; write-back during reads raises transactional questions the middleware sidesteps.Source: §6 · p. 6