Databases for AI, Digital Transformation and Emerging Trends

Introduction

Database management systems (DBMSs) have traditionally been designed to store structured records, enforce integrity, support transactions, and answer queries. Contemporary artificial intelligence (AI) systems have expanded these responsibilities. An AI application may need to retrieve semantically similar documents, combine tabular and unstructured data, maintain rapidly changing features, represent relationships among entities, and serve predictions with millisecond-level latency. Consequently, database architecture is becoming a central part of AI engineering and digital transformation rather than a back-office concern.

This chapter examines the principal database technologies supporting modern AI: feature stores, embeddings and vector databases, similarity search, knowledge graphs, multimodal data systems, and real-time data platforms. It also considers AI-assisted database administration, autonomous databases, data products, architecture choices, governance, and the strategic implications of these developments.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain the purpose and architecture of feature stores.

2. Describe embeddings, vector databases, and similarity-search methods.

3. Distinguish vector databases from knowledge graphs and relational databases.

4. Design a high-level architecture for multimodal and real-time AI data.

5. Evaluate AI-assisted administration and autonomous database capabilities.

6. Apply data-product and digital-transformation principles to database decisions.

7. Identify governance, security, privacy, cost, and operational risks.

8. Recommend an architecture using explicit workload and business criteria.

1. From Conventional Databases to AI-Centred Data Platforms

A conventional operational database primarily answers questions such as: Which customer placed an order? What is the current inventory? Has an invoice been paid? These questions usually involve explicit attributes, exact values, and well-defined relationships.

AI workloads introduce additional requirements:

• Semantic retrieval: finding content that is conceptually related, even when the words differ.
• Feature consistency: ensuring that a model receives the same definition of a feature during training and prediction.
• High-throughput inference: supplying data to models under strict latency requirements.
• Unstructured-data management: storing text, images, audio, video, and documents with metadata.
• Continuous processing: incorporating events such as clicks, sensor readings, and transactions as they occur.
• Relationship reasoning: following links among people, products, places, documents, and events.

No single database type is optimal for all these requirements. A modern architecture is therefore usually polyglot: it combines relational, document, time-series, graph, search, vector, and streaming technologies. Polyglot persistence is useful, but it increases integration, governance, security, and operational complexity. The correct question is not “Which database is newest?” but “Which data model and execution pattern match the workload?”

A useful architectural distinction is between three data states:

1. System of record: the authoritative source for facts such as account balances or order status.

2. System of intelligence: curated, transformed, and enriched data used for analytics and machine learning.

3. System of engagement: low-latency services that deliver recommendations, search results, predictions, and personalized experiences.

The same business entity may appear in all three states, but the copies should have clear ownership, lineage, refresh policies, and consistency expectations.

2. Feature Stores

2.1 Concept and purpose

A feature is an input variable used by a machine-learning model. Examples include the number of purchases made by a customer in the previous 30 days, average sensor temperature during the last hour, or the number of failed login attempts in a day. A feature store is a data platform that manages the definition, computation, storage, discovery, and serving of features for machine-learning systems.

Feature stores address a major engineering problem: training-serving skew. This occurs when a feature is calculated differently during model training and production inference. For example, a training pipeline may calculate “customer spending in the previous 30 days” using completed transactions, while the online service uses all transactions, including cancelled ones. The model then encounters a data distribution different from the one used during training.

2.2 Typical architecture

A feature-store architecture commonly includes:

• Source systems: operational databases, event streams, files, and external APIs.
• Transformation pipelines: batch or streaming computations that create features.
• Offline store: historical feature values used for training, evaluation, and backtesting.
• Online store: a low-latency key-value or database layer used during prediction.
• Feature registry: definitions, owners, schemas, descriptions, versions, and quality rules.
• Serving layer: APIs or libraries through which models request features.
• Monitoring: checks for freshness, missingness, distribution shifts, and serving errors.

A feature definition should specify its entity key, time semantics, source, transformation logic, update frequency, acceptable delay, and owner. For example, a feature may be defined as “the count of successful purchases associated with customer_id during the interval ending at event_time.” The phrase “ending at event_time” is essential because it prevents future information from entering historical training examples.

2.3 Point-in-time correctness

Point-in-time correctness means that a training example uses only information available at the prediction time. Suppose a loan-default model predicts risk at 10:00 on 1 March. A transaction recorded on 2 March must not be included in a feature calculated for that example, even if the transaction was later backdated or corrected.

A practical implementation uses event timestamps and performs an as-of join: each feature value is joined to the latest version whose event time is no later than the prediction timestamp. This prevents data leakage, in which information unavailable in reality makes evaluation appear better than it would be in production.

2.4 Offline and online serving

The offline store is optimized for large historical scans and reproducible datasets. The online store is optimized for rapid retrieval of the latest values, often by entity key. These stores may use different technologies, but their feature definitions must remain consistent.

A feature store is not automatically necessary for every project. A small model with a few stable features may be adequately served from a curated relational table. A feature store becomes more valuable when an organization has many models, shared features, real-time requirements, multiple teams, or strict audit needs.

2.5 Feature quality and governance

Important controls include:

• schema and type validation;
• freshness and completeness thresholds;
• ownership and approval workflows;
• lineage from source to model;
• versioning of transformations;
• access control for sensitive attributes;
• monitoring for drift and unexpected values;
• retention and deletion policies.

Feature reuse improves consistency and reduces duplicated engineering, but a poorly governed feature store can become a catalogue of opaque, unreliable variables. A feature should be treated as a governed data product, not merely as a column.

3. Embeddings, Vector Databases, and Similarity Search

3.1 Embeddings

An embedding is a numerical vector representing an object such as text, an image, an audio segment, a user, or a product. An embedding model maps an object to a point in a multidimensional space. Objects with similar meaning are expected to be located near one another, although this property depends on the model, training data, and domain.

For a vector represented by components \(x_1, x_2, ..., x_d\), its Euclidean norm is:

\[

||x||_2 = \sqrt{\sum_{i=1}^{d} x_i^2}

\]

The cosine similarity of non-zero vectors x and y is:

\[

\operatorname{cos}(x,y)=\frac{x\cdot y}{||x||_2||y||_2}

\]

where \(x\cdot y=\sum_{i=1}^{d}x_i y_i\). Cosine similarity measures the angle between vectors and is commonly used when direction is more important than magnitude. It is applicable only to non-zero vectors. If all vectors are normalized to unit length, maximizing cosine similarity is equivalent to maximizing the dot product. Euclidean distance, in contrast, measures straight-line separation and may be appropriate when magnitude carries meaning.

Embeddings do not constitute ground truth. They are representations produced by a model and may encode bias, omit important distinctions, or change when the model is replaced. Their use therefore requires evaluation with domain-relevant retrieval and business metrics.

3.2 Vector databases

A vector database stores vectors with identifiers, metadata, and indexing structures. It supports operations such as:

• nearest-neighbour search;
• metadata filtering;
• insertion and deletion of vectors;
• updates and versioning;
• hybrid keyword-plus-vector retrieval;
• access control and tenant isolation.

A vector record might contain an embedding for a document chunk, its source document, page number, language, security classification, and creation date. Metadata is crucial because semantic similarity alone should not return a confidential document to an unauthorized user.

3.3 Exact and approximate search

An exact nearest-neighbour search compares a query vector with every candidate vector. It can provide accurate results but becomes expensive as the collection grows. Approximate nearest-neighbour (ANN) indexes reduce search time by exploring only a promising subset of the space. They trade a small amount of recall for improved latency and scalability.

Common ANN families include graph-based indexes, such as navigable small-world graphs, and inverted-file or quantization-based methods. Their parameters influence memory consumption, build time, recall, and query latency. These are engineering trade-offs, not universally optimal settings.

Important evaluation measures include:

• Recall@k: the proportion of the true top-k neighbours returned by the system.
• Precision@k: the proportion of returned top-k results judged relevant.
• Latency: time required to produce results, often reported at percentile levels such as p95 or p99.
• Throughput: queries served per unit time.
• Freshness: delay between source-data change and searchable availability.

3.4 Retrieval-augmented generation

In retrieval-augmented generation (RAG), a system retrieves relevant material and provides it to a generative model as context. A typical pipeline is:

1. collect and authorize source documents;

2. clean, segment, and attach metadata;

3. generate embeddings for segments;

4. index vectors and metadata;

5. embed a user query;

6. retrieve and filter candidate segments;

7. optionally rerank them using a stronger model;

8. provide selected context to the generator;

9. cite sources and log the interaction.

RAG can reduce unsupported answers, but retrieval quality remains a limiting factor. Poor segmentation, stale documents, ambiguous queries, prompt injection, and unauthorized retrieval can all create serious risks. A vector database is a retrieval component; it does not itself guarantee factuality, reasoning, or security.

3.5 Worked example: cosine similarity

Consider a query vector \(q=(1,2)\) and two document vectors \(a=(2,1)\) and \(b=(1,3)\). Their dot products with q are 4 and 7 respectively. The norms are \(||q||=\sqrt{5}\), \(||a||=\sqrt{5}\), and \(||b||=\sqrt{10}\). Therefore:

\[

\operatorname{cos}(q,a)=\frac{4}{5}=0.80

\]

and

\[

\operatorname{cos}(q,b)=\frac{7}{\sqrt{50}}\approx0.99.

\]

Under cosine similarity, b is the closer document. This conclusion assumes that the embedding space is meaningful for the task and that cosine similarity is the selected metric. It does not prove that b is factually more useful; relevance must be evaluated by people or task-specific labels.

4. Knowledge Graphs and Their Relationship with Vector Search

A knowledge graph represents entities and relationships as a graph. A simple statement may be expressed as (University, offers, Programme) or (Drug A, interacts-with, Drug B). Nodes may represent people, products, organizations, locations, or concepts; edges represent typed relationships. Properties, provenance, timestamps, and confidence values can be attached to both nodes and edges.

Knowledge graphs support:

• relationship traversal;
• entity resolution;
• constraint checking;
• recommendation based on connections;
• explainable paths;
• semantic integration across sources;
• rule-based or ontology-based inference.

Graph databases often use property-graph models or RDF-based triples. These models are related but not identical: property graphs emphasize nodes and edges with properties, whereas RDF represents subject-predicate-object triples and commonly uses formal vocabularies and ontologies.

Vector search and graph search solve different problems. Vector search asks, “Which objects are semantically similar?” Graph search asks, “Which entities are connected through specified relationships?” A hybrid system can first retrieve semantically related documents and then traverse a graph to validate entities, permissions, or relationships. Conversely, graph-derived neighbourhoods can be embedded for similarity-based recommendation.

Knowledge graphs require substantial data integration and ontology management. Incorrect entity matching can create false relationships; incomplete graphs can produce misleading conclusions. Graph reasoning should therefore expose provenance and distinguish known, inferred, and uncertain facts.

5. Multimodal and Real-Time Data Systems

5.1 Multimodal data

Multimodal systems process more than one data type, such as text and images, speech and transcripts, or video and sensor measurements. A database architecture must preserve the original objects, derived representations, metadata, and relationships among modalities.

For example, an industrial inspection record may include:

• a machine identifier and inspection time;
• a high-resolution image;
• a vibration time series;
• a technician’s text note;
• an image embedding;
• a predicted defect category;
• links to maintenance history.

Large binary objects are often stored in object storage, while a relational, document, or catalogue database stores metadata and references. Embeddings can be placed in a vector index, and events can be retained in a streaming platform. The architecture must maintain a stable identifier linking all representations to the same physical event.

Challenges include synchronization across clocks, differing quality and resolution, missing modalities, large storage costs, privacy of biometric or voice data, and model-version management. Multimodal systems should retain provenance: which model produced a derived representation, from which source, and at what time.

5.2 Real-time data

Real-time systems process events continuously or with a bounded delay. Examples include fraud detection, fleet monitoring, recommendation updates, predictive maintenance, and operational dashboards.

A typical architecture contains event producers, a durable event log, stream-processing operators, state stores, serving databases, and monitoring. Important design concepts include:

• event time: when an event actually occurred;
• processing time: when the system handled it;
• watermarks: progress indicators used to handle late events;
• windowing: grouping events into intervals such as tumbling, sliding, or session windows;
• delivery semantics: at-most-once, at-least-once, or effectively-once processing;
• idempotency: making repeated processing safe;
• backpressure: slowing producers or processing when consumers cannot keep up.

Exactly-once claims must be interpreted carefully. A system may provide exactly-once effects within a particular transaction boundary while external side effects still require idempotency or deduplication. At-least-once delivery is common and can be reliable when event identifiers and idempotent updates are used.

The freshness of an AI feature is not the same as its accuracy. A rapidly updated but noisy signal may be less useful than a slightly older, well-validated feature. Real-time architecture should therefore specify service-level objectives for latency, completeness, correctness, and recovery.

6. AI-Assisted Administration and Autonomous Databases

Database administration increasingly uses machine learning for workload analysis, index recommendations, query-plan selection, anomaly detection, capacity forecasting, backup verification, and failure prediction. Some systems can automatically create indexes, adjust memory, scale resources, or apply patches. An autonomous database is a database service that automates substantial administration while exposing policy and control mechanisms to operators.

Potential benefits include reduced routine effort, faster response to workload changes, improved availability, and more consistent configuration. However, automation can also create risks:

• an index recommendation may improve one query while harming writes;
• automatic scaling may create unexpected costs;
• a learned query plan may perform poorly after data distribution changes;
• opaque decisions may complicate incident analysis;
• automated patching may conflict with compatibility requirements.

Good practice is to use graduated autonomy. Advisory mode can propose changes; approval mode can apply them after review; fully automated mode can be reserved for low-risk, reversible actions. Every automated change should be logged, attributable, observable, and reversible where feasible.

AI assistants can help administrators translate natural-language requests into queries, explain execution plans, generate migration scripts, and diagnose incidents. Generated SQL must not be trusted without validation, especially when it can modify or disclose data. Least privilege, query allowlists, sandboxing, human review, and audit logging are essential.

7. Data Products and Digital Transformation

A data product is a governed, discoverable, reusable data asset designed to provide value to identifiable consumers. It may be a curated dataset, feature set, API, analytical model, semantic layer, or real-time feed. Data-product thinking shifts responsibility from a central team that merely delivers tables toward domain teams that own quality and meaning.

A mature data product has:

• a clearly defined consumer and use case;
• an accountable owner;
• documented semantics and business definitions;
• quality and freshness objectives;
• access and privacy controls;
• metadata, lineage, and discoverability;
• versioning and a deprecation policy;
• support and incident procedures.

Data products support digital transformation when they make information reusable across business processes. For example, a trusted customer identity product can support service, marketing, fraud detection, and analytics. Without shared identity resolution and governance, each department may create incompatible customer views.

A data mesh is an organizational and architectural approach that emphasizes domain ownership, data as a product, self-service platform capabilities, and federated governance. It is not a particular database technology. Organizations should avoid adopting its vocabulary without the capabilities required to maintain quality, interoperability, and accountability.

8. Strategic Architecture Decisions

Architecture selection should begin with workload analysis. Relevant questions include:

1. Is the workload transactional, analytical, retrieval-oriented, graph-oriented, or streaming?

2. What are the latency, throughput, availability, and recovery objectives?

3. Are reads exact, aggregative, semantic, relational, or predictive?

4. How frequently does data change, and how fresh must results be?

5. What consistency model is required?

6. Which data is sensitive or regulated?

7. What are the expected storage, compute, network, and operational costs?

8. How portable must the system be across vendors or clouds?

9. Can the organization operate the technology effectively?

10. How will quality, lineage, deletion, and model drift be measured?

A decision matrix can score candidate architectures against these criteria, using weights agreed by technical and business stakeholders. Scores should be supported by workload tests rather than marketing claims. Benchmarking must use representative data volumes, query distributions, concurrency, update patterns, and failure conditions.

Important trade-offs include:

• Consistency versus availability: stronger consistency can increase coordination cost or latency.
• Freshness versus cost: frequent computation and replication consume resources.
• Flexibility versus governance: schema flexibility can accelerate experimentation but complicate quality control.
• Specialization versus simplicity: multiple databases may improve performance but increase operational burden.
• Managed service convenience versus portability: managed platforms reduce administration but may create lock-in.
• Recall versus latency: broader similarity search may improve retrieval while slowing responses.

A sound architecture often uses a system of record plus derived indexes and caches. Derived stores should be rebuildable from authoritative sources whenever practical. This reduces the risk that an index or embedding store becomes an untraceable source of truth.

9. Governance, Ethics, Security, and Regulation

AI data systems magnify familiar database risks. Governance must cover both original data and derived artifacts such as embeddings, features, labels, graph inferences, and model outputs.

Key controls include:

• data minimization and purpose limitation;
• consent or another lawful basis where required;
• encryption in transit and at rest;
• role-based or attribute-based access control;
• tenant isolation;
• retention and deletion workflows;
• audit logs and lineage;
• quality and bias testing;
• incident response and breach notification;
• human oversight for consequential decisions.

An embedding may reveal information about its source or permit membership or attribute inference. Removing the original document does not automatically remove every derived vector, cache, backup, or model artifact. Deletion policies must address the entire data lineage.

Regulatory obligations vary by jurisdiction and use case. Systems used in employment, credit, health, education, or public services may require stronger transparency, documentation, risk management, and human review. Organizations should map controls to applicable privacy, cybersecurity, records-management, and AI regulations rather than assuming that a database technology is compliant by itself.

Security threats include injection into retrieved documents, poisoned training data, unauthorized vector search, insecure administrative assistants, exposed backups, and excessive service permissions. Retrieval systems should enforce authorization before or during retrieval, not merely after generation.

10. Illustrative Case: Predictive Maintenance for a Manufacturing Firm

Background

This illustrative case concerns Meridian Components, a manufacturer operating 2,000 motors across several plants. The firm stores maintenance records in a relational DBMS, sensor data in a time-series platform, manuals as PDF files, and technician notes in a service application.

Problem

Unexpected failures are costly. The company wants to predict failures 24 hours in advance and provide technicians with relevant maintenance procedures. Existing reports are batch-based, sensor formats differ by plant, and training features are calculated differently from production features.

Analysis

The project requires several complementary capabilities:

• streaming ingestion for vibration and temperature events;
• time-windowed feature computation;
• an offline store for historical training data;
• an online store for current motor features;
• vector retrieval over manuals and prior repair notes;
• a knowledge graph linking motors, parts, faults, plants, and procedures;
• governance for technician identities and operational safety.

A single relational database could store some of these data, but it would not by itself provide efficient semantic retrieval, continuous event processing, or convenient feature serving at scale.

Approach and solution

The firm retains the maintenance DBMS as the system of record for work orders and parts. Sensor events are written to a durable event platform. A stream processor calculates features such as recent vibration statistics and counts of alerts in defined time windows. The same feature definitions are used to create historical training data through point-in-time joins. Current values are placed in an online feature store.

Manuals and approved repair notes are cleaned, access-labelled, segmented, and embedded. A vector index supports similarity retrieval, but authorization filters restrict results to the technician’s plant and role. A knowledge graph links equipment serial numbers to models, installed components, known fault codes, and approved procedures.

The prediction service retrieves online features, produces a risk score, and records model version, feature timestamps, and explanation fields. A technician application combines the prediction with graph-based equipment context and cited document passages. High-risk recommendations require human confirmation before a maintenance action is scheduled.

Outcome

In a pilot, the firm evaluates not only predictive accuracy but also warning lead time, false-alarm rate, retrieval recall, technician acceptance, system latency, and maintenance cost. It discovers that a highly sensitive model generates too many false alarms on one plant’s older sensors. Rather than deploying the model unchanged, the team introduces plant-specific calibration, sensor-quality features, and a review workflow.

Learning points

1. The architecture is polyglot because the workloads differ.

2. Point-in-time correctness is necessary for credible model evaluation.

3. Vector retrieval and graph traversal complement rather than replace each other.

4. Derived stores require lineage, access control, and deletion procedures.

5. Operational acceptance and safety are as important as predictive metrics.

6. Architecture should be validated through representative pilots and measurable service objectives.

11. Contemporary Developments and Best Practices

Several developments are shaping the field. Lakehouse architectures combine inexpensive object storage with warehouse-like management and governance. Hybrid search combines lexical matching, structured filters, and vector similarity. Small, specialized models increasingly support local or private inference. Streaming databases and incremental computation reduce the delay between events and decisions. Data catalogues are incorporating semantic metadata and automated lineage discovery.

These developments do not eliminate fundamental engineering principles. Recommended practices are:

• begin with business decisions and measurable service objectives;
• preserve authoritative sources and make derived stores reproducible;
• define data ownership and semantics before scaling technology;
• test feature definitions for point-in-time correctness;
• evaluate vector retrieval with labelled, domain-specific queries;
• combine metadata authorization with semantic search;
• use schema, quality, freshness, and drift monitoring;
• design for replay, recovery, deduplication, and late events;
• record model, embedding, feature, and index versions;
• adopt graduated automation with human oversight;
• estimate total cost, including operations and egress;
• conduct privacy, security, and failure-mode reviews;
• measure business outcomes, not only infrastructure performance.

Chapter Summary

AI-oriented database architecture extends traditional data management with semantic representations, feature serving, graph relationships, multimodal storage, and continuous event processing. Feature stores reduce training-serving skew by governing reusable features across offline and online contexts, with point-in-time correctness preventing leakage. Embeddings support semantic representation, while vector databases provide similarity search; cosine similarity is one possible metric, and approximate indexes trade recall for performance. Knowledge graphs represent explicit relationships and can complement vector retrieval in hybrid systems.

Multimodal systems coordinate original objects, metadata, embeddings, and derived predictions. Real-time systems must address event time, late data, delivery semantics, idempotency, and bounded latency. AI-assisted and autonomous databases can reduce administration effort, but require observability, permissions, review, and reversibility. Data products connect technical assets to accountable owners and consumers, while digital transformation depends on deliberate choices among consistency, freshness, cost, portability, specialization, and governance.

The central architectural lesson is that no database is universally best. Successful systems align data models and processing patterns with business objectives, preserve lineage and security, and treat derived AI data as governed enterprise assets.

Key Terms

Embedding: A numerical vector representation of an object such as text, an image, or a user.

Vector database: A database or index designed to store vectors and support similarity search.

Cosine similarity: A measure of the angle-based similarity between two non-zero vectors.

Approximate nearest-neighbour search: Search that improves speed by examining a selected subset of candidates.

Feature: An input variable used by a machine-learning model.

Feature store: A platform for defining, governing, computing, and serving machine-learning features.

Training-serving skew: A difference between feature processing during training and production inference.

Point-in-time correctness: Use of only information available at the relevant historical prediction time.

Data leakage: Inclusion of information in training that would not be available when making a real prediction.

Knowledge graph: A graph representation of entities, relationships, properties, and provenance.

Multimodal data: Data involving multiple forms such as text, images, audio, video, or sensor readings.

Event time: The time at which an event actually occurred.

Idempotency: The property that repeated execution produces the same intended effect as one execution.

Data product: A governed, discoverable data asset designed for identifiable consumers and uses.

System of record: The authoritative source for a particular business fact.

Polyglot persistence: Use of multiple database technologies for different workload requirements.

Autonomous database: A database service that automates significant administration activities.

Data lineage: The documented origin, transformation, movement, and use of data.

Retrieval-augmented generation: Generation that uses retrieved external context to inform a model response.

Training-serving skew: A difference between the data or transformations used in training and serving.

Review Questions

Short Answer Questions

1. What problem does a feature store address?

2. Define an embedding and state one use for it.

3. How does a knowledge graph differ from a vector database?

4. What is point-in-time correctness?

5. Why is idempotency important in event processing?

Long Answer Questions

1. Explain the architecture of a feature store and the roles of its offline and online stores.

2. Compare exact nearest-neighbour search with approximate nearest-neighbour search, including their principal trade-off.

3. Explain how vector retrieval and knowledge graphs can be combined in an AI application.

4. Discuss the benefits and risks of AI-assisted database administration.

5. Describe the characteristics of a high-quality data product and its role in digital transformation.

Analytical / Application Questions

1. A bank wants semantic search over policy documents but must prevent employees from retrieving documents outside their business unit. Design the retrieval controls and explain why vector similarity alone is insufficient.

2. A fraud model uses a feature calculated from transactions arriving late. Propose a point-in-time training method and a production strategy for handling late events.

3. An organization is considering one general-purpose database versus a relational database, stream processor, vector index, and graph database. Develop a decision framework using workload, governance, cost, and operational criteria.

Multiple Choice Questions with Answers

Question 1

What is the primary purpose of a feature store?

A. To replace all operational databases

B. To manage and serve consistent machine-learning features

C. To compress image files

D. To create database user interfaces

Correct Answer: B. To manage and serve consistent machine-learning features

Question 2

Point-in-time correctness primarily prevents which problem?

A. Data leakage from future information

B. Network congestion

C. Duplicate database indexes

D. Lossless image compression

Correct Answer: A. Data leakage from future information

Question 3

For q=(1,2) and a=(2,1), what is their cosine similarity?

A. 0.20

B. 0.50

C. 0.80

D. 1.20

Correct Answer: C. 0.80

Question 4

What does a vector database primarily support?

A. Similarity search over numerical representations

B. Only payroll transaction processing

C. Physical sensor calibration

D. Operating-system scheduling

Correct Answer: A. Similarity search over numerical representations

Question 5

Which statement best describes a knowledge graph?

A. It stores only unstructured binary files

B. It represents entities and typed relationships

C. It is an index that compares only vector magnitudes

D. It is a replacement for every stream processor

Correct Answer: B. It represents entities and typed relationships

Question 6

Which practice helps make repeated event processing safe?

A. Idempotency

B. Increasing document font size

C. Removing event identifiers

D. Disabling audit logs

Correct Answer: A. Idempotency

Question 7

In retrieval-augmented generation, retrieved documents are used primarily to provide what?

A. Database backups

B. External context for generation

C. Operating-system updates

D. Encryption keys

Correct Answer: B. External context for generation

Question 8

Which is a risk of fully autonomous database administration?

A. Every query becomes logically impossible

B. Automated changes may increase cost or harm performance

C. Data can no longer be indexed

D. Users cannot define schemas

Correct Answer: B. Automated changes may increase cost or harm performance

Question 9

Which characteristic is essential to a governed data product?

A. No identifiable owner

B. Undocumented transformations

C. Defined consumers, quality expectations, and ownership

D. Permanent exemption from access controls

Correct Answer: C. Defined consumers, quality expectations, and ownership

Question 10

Why might an AI architecture use both a vector index and a knowledge graph?

A. They provide identical operations and must be duplicated

B. Vectors support semantic similarity while graphs support explicit relationships

C. Graphs eliminate the need for metadata

D. Vector indexes guarantee factual correctness

Correct Answer: B. Vectors support semantic similarity while graphs support explicit relationships