LinkedIn Deploys Two-Stage RAG Pipeline to Stop Model Hallucinations

Revolutionizing Search: The Power of Semantic Intelligence and Generative AI With LinkedIn — Ai4

Ai4

Pairing approximate nearest neighbor vector retrieval with transformer re-ranking eliminates enterprise model hallucinations without incurring the latency penalties of direct generative inference.

AI-assisted summary of Revolutionizing Search: The Power of Semantic Intelligence and Generative AI With LinkedIn — original source. Check the original for full context.

Source published:

Detailed notes

## Background Published on YouTube by Ai4 on August 29, 2025, this presentation features Rahul Raja, Staff Software Engineer on LinkedIn's Search Infrastructure and AI Platform team. According to the description, the session explores how semantic intelligence and generative AI are reshaping search into contextual, conversational, and user-centric discovery, covering embeddings, LLMs, and production architectural patterns.

## TL;DR Rahul Raja outlines the technical transition from traditional keyword-based inverted indexes and BM25 ranking to semantic vector search and Retrieval-Augmented Generation (RAG). He details how transformer embeddings and cosine similarity enable intent-driven discovery, bridging proprietary enterprise data with LLMs to eliminate hallucinations and streamline knowledge access without costly model retraining. The talk breaks down scalable infrastructure requirements—including vector databases, indexing strategies (HNSW, IVF-PQ), and two-stage ANN re-ranking pipelines—before projecting future directions toward multimodal retrieval and agentic workflows.

## Atmosphere & style The talk carries an authoritative, pragmatic, and polished engineering tone designed specifically for practitioners and system architects. Raja's delivery is measured and methodical, demystifying complex vector mathematics and retrieval pipelines through clean diagrams and clear explanations. Punctuated by moments of casual relatability—such as laughing off a minor slide mismatch—the presentation maintains a practical, production-first focus that separates robust enterprise implementations from fragile prototypes.

## Key takeaways - [00:04](https://www.youtube.com/watch?v=u-kV64T9h00&t=4s) Modern search is transitioning from static keyword matching and lists of links toward conversational, context-aware information discovery driven by semantic intelligence and generative AI. - [03:07](https://www.youtube.com/watch?v=u-kV64T9h00&t=187s) Traditional search infrastructure relies on inverted indexes and statistical scoring methods like TF-IDF and BM25, which operate strictly lexically and fail to recognize synonyms, paraphrases, or conceptual equivalence. - [06:28](https://www.youtube.com/watch?v=u-kV64T9h00&t=388s) Semantic search maps queries and documents into a shared continuous vector space using transformer models, determining relevance by measuring cosine similarity between dense embeddings. - [09:09](https://www.youtube.com/watch?v=u-kV64T9h00&t=549s) Retrieval-Augmented Generation (RAG) mitigates LLM hallucinations on enterprise data by coupling a fast semantic retrieval layer with LLM reasoning over proprietary knowledge. - [10:54](https://www.youtube.com/watch?v=u-kV64T9h00&t=654s) Injecting retrieved vector context directly into the prompt ensures that generated outputs remain anchored in factual, verifiable enterprise documentation. - [11:59](https://www.youtube.com/watch?v=u-kV64T9h00&t=719s) Enterprise RAG enables rapid knowledge discovery and domain adaptation to company-specific jargon without incurring the high computational costs of continuous model retraining. - [11:59](https://www.youtube.com/watch?v=u-kV64T9h00&t=719s) Anchoring generative outputs to auditable source records provides clear traceability and regulatory compliance across organizational workflows. - [14:43](https://www.youtube.com/watch?v=u-kV64T9h00&t=883s) Scalable semantic search infrastructures utilize specialized vector databases such as FAISS, Vespa, or Weaviate, leveraging indexing strategies like IVF-PQ and HNSW graphs to balance latency, memory, and recall. - [17:00](https://www.youtube.com/watch?v=u-kV64T9h00&t=1020s) Production AI search architectures resolve the trade-off between latency and relevance through a two-stage pipeline: fast Approximate Nearest Neighbor (ANN) candidate retrieval followed by heavy transformer re-ranking. - [17:00](https://www.youtube.com/watch?v=u-kV64T9h00&t=1020s) Production-grade enterprise deployments require explicit fact-checking validation layers and grounded prompt injection rather than relying on unverified prototype demos. - [18:49](https://www.youtube.com/watch?v=u-kV64T9h00&t=1129s) Future enterprise RAG systems are expanding toward multimodal retrieval across diagrams, images, and video, as well as real-time dynamic data ingestion without full re-indexing cycles. - [18:49](https://www.youtube.com/watch?v=u-kV64T9h00&t=1129s) RAG architectures are evolving from passive document lookup into autonomous agentic workflows capable of multi-step reasoning, decision-making, and direct operational action.

## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=u-kV64T9h00&t=4s) Evolution of Search: From Keyword Matching to Semantic Intelligence and GenAI

Search systems are undergoing a fundamental transformation in how users interact with and retrieve information. Traditionally, search was designed to help people locate what they needed by having users type a query, submit it, and sift through a static list of ranked links. However, modern user expectations have evolved significantly. Today's users no longer want just raw document links or disjointed answers; they expect a conversational, context-aware experience where the search system genuinely understands the intent behind their query rather than merely performing surface-level keyword matching.

This evolutionary leap from keyword matching to deep semantic comprehension is driven by two major technological forces: semantic intelligence and generative AI. Semantic intelligence provides the capability to represent the true meaning and intent of a user's query beyond literal surface forms. In parallel, large language models (LLMs) bring the power to synthesize, summarize, and explain complex information based on retrieved context. When combined, these forces form the architectural backbone of modern Retrieval-Augmented Generation (RAG) systems, enabling organizations to query their proprietary, domain-specific databases conversationally and deliver grounded, contextual answers.

- **Speaker background:** Rahul Raja, Staff Software Engineer on LinkedIn's Search Infrastructure and AI Platform team. - **Core paradigm shift:** Transitioning from static link retrieval based on surface keywords to contextual, conversational information discovery. - **Key drivers:** The synergy between semantic intelligence (dense semantic representation) and generative AI / LLMs (synthesis, reasoning, and summarization).

---

[03:07](https://www.youtube.com/watch?v=u-kV64T9h00&t=187s) Traditional Search Architecture: Inverted Indexes, TF, and BM25

At a technical level, traditional search engines rely primarily on the inverted index data structure, which remains the workhorse of search infrastructure across most major technology companies. An inverted index functions by parsing a corpus of documents into individual terms and mapping each term to the specific list of document IDs in which it appears. When a user submits a multi-word query, the search engine looks up each term's posting list in the inverted index, computes their intersection or union, and returns matching documents for the user to inspect.

```mermaid flowchart LR accTitle: Traditional Inverted Index Flow subgraph Docs["Document Corpus"] D1["Doc 1: 'AI is cool'"] D2["Doc 2: 'AI platform'"] D3["Doc 3: 'Search is fast'"] end subgraph Index["Inverted Index"] T1["'AI' -> Doc 1, Doc 2"] T2["'is' -> Doc 1, Doc 3"] T3["'cool' -> Doc 1"] end subgraph QueryEngine["Query Execution"] Q["User Query: 'AI'"] --> Lookup["Index Lookup"] Lookup --> Results["Return Doc 1, Doc 2"] end Docs --> Index Index --> Lookup ```

While inverted indexes are highly efficient for exact string retrieval, they suffer from a fundamental limitation: they are purely lexical. If a user searches for *"artificial intelligence"* instead of *"AI"*, a strict inverted index cannot recognize that the two phrases are semantically identical unless explicitly mapped. To score and rank matching documents, traditional search relies on statistical algorithms such as Term Frequency (TF / TF-IDF) and BM25. Term frequency boosts documents where query terms appear frequently while accounting for term rarity across the broader corpus. BM25 builds directly upon term frequency by introducing document length normalization and saturation parameters, preventing overly frequent words from disproportionately dominating ranking scores.

- **Inverted index mechanism:** Maps tokenized terms directly to document posting lists (`term -> [doc_id_1, doc_id_2,...]`). - **Lexical blind spot:** Incapable of recognizing synonyms, paraphrases, or conceptual equivalence (e.g., failing to match "artificial intelligence" to "AI"). - **Classical ranking algorithms:** - **TF / TF-IDF:** Weights the local frequency of a term inside a document against its global document frequency across the corpus. - **BM25:** Refines term frequency scoring with non-linear term frequency saturation and document length normalization.

---

[06:28](https://www.youtube.com/watch?v=u-kV64T9h00&t=388s) The Mechanics of Semantic Search: Vectors, Embeddings, and Cosine Similarity

Semantic search overcomes the rigidity of lexical matching by projecting both queries and documents into a shared continuous vector space. Text strings—such as the query *"fix my laptop screen"* or an instructional repair document—are passed through transformer-based embedding models (such as BERT or OpenAI embedding models) to produce fixed-size, high-dimensional numerical vectors. While these vectors appear as arrays of floating-point numbers, their geometric coordinates capture deep semantic and syntactic meaning.

```mermaid flowchart TD accTitle: Semantic Vector Embedding and Similarity Pipeline subgraph Encoding["Vector Encoding"] Q["Query: 'fix my laptop screen'"] --> M1["Embedding Model"] D["Doc: 'repair notebook display'"] --> M2["Embedding Model"] M1 --> Vq["Query Vector: [0.12, -0.45,...]"] M2 --> Vd["Doc Vector: [0.14, -0.42,...]"] end subgraph Similarity["Semantic Matching"] Vq --> CS["Cosine Similarity Calculation"] Vd --> CS CS --> Score["Relevance Score: cos(θ)"] end ```

To determine how closely a document matches a user's query, the system evaluates the distance or angle between their respective embedding vectors. The standard metric employed is cosine similarity, which measures the cosine of the angle between the two vectors: the smaller the angular divergence, the higher the semantic similarity. Common vector dimensions range from 384 to 768 dimensions (or higher), directly governed by the model's final hidden state width. This dense mathematical representation allows the system to effortlessly resolve nuanced relationships, such as synonyms, paraphrases, and related conceptual queries, forming the foundational retrieval mechanism for RAG pipelines.

- **Vector dimensionality:** Common embedding output sizes include 384 and 768 dimensions, determined by the underlying model architecture. - **Similarity metric:** Cosine similarity measures the angle between query and document vectors in latent space to establish semantic alignment. - **Key capability:** Robustly matches conceptually related terms and paraphrased expressions without requiring literal token overlap.

---

[09:09](https://www.youtube.com/watch?v=u-kV64T9h00&t=549s) The Retrieval-Augmented Generation (RAG) Architecture and Workflow

Retrieval-Augmented Generation (RAG) integrates semantic retrieval directly with large language models to deliver accurate, context-grounded answers. Because general-purpose LLMs are not trained on an enterprise's private or internal data, zero-shot prompting on proprietary subjects often leads models to hallucinate plausible-sounding but incorrect information. RAG solves this grounding problem by coupling a fast, semantic retrieval layer with the reasoning capabilities of the LLM.

```mermaid flowchart LR accTitle: RAG Architecture and Retrieval Workflow subgraph InputStage["1. User Input"] UI["User Interface"] --> P["Prompt + Query"] end subgraph RetrievalStage["2. Retrieval Layer"] P --> Sys["System Interface"] Sys --> Ret["Semantic Search"] Ret --> Sources[("Vector Stores / Document DBs / APIs")] Sources --> Context["Relevant Context"] end subgraph AugmentStage["3. Generation"] Context --> EP["Enhanced Prompt Construction"] EP --> LLM["Large Language Model"] end ```

The RAG workflow operates through an orchestrated multi-step pipeline: 1. **User input:** The process begins when a user submits a query alongside guiding prompt instructions through the system interface. 2. **Retrieval execution:** The system interface routes the query into the retrieval layer, which runs semantic search against connected knowledge sources—including vector databases, document stores, or external enterprise APIs. 3. **Context extraction:** The retrieval layer returns the top matching semantic context containing authoritative proprietary data. 4. **Prompt enhancement:** The system synthesizes the retrieved context and the user's initial query into an enhanced, enriched prompt before passing it to the language model for grounded response generation.

- **Core motivation:** Mitigates LLM hallucinations on enterprise proprietary data by injecting authoritative retrieved context into the prompt context window. - **Knowledge sources:** Encompasses vector stores, indexed document databases, and internal enterprise APIs. - **Pipeline stage:** Serves as the crucial intermediary bridge connecting raw user intent with enriched LLM synthesis.

[10:54](https://www.youtube.com/watch?v=u-kV64T9h00&t=654s) Grounding Generative Prompts with Vector Context

The final stage of the retrieval-augmented generation (RAG) pipeline synthesizes the user's input with domain-specific knowledge. The system constructs an enhanced prompt by fusing the user's original query with the relevant context retrieved from the vector database and enterprise knowledge sources. By feeding this unified payload into the large language model endpoint, the system ensures that the model generates factual, domain-tailored responses rather than speculating. Because the generated text remains anchored in verified internal documents, the risk of hallucination is minimized.

```mermaid flowchart LR accTitle: RAG Prompt Augmentation and Generation Flow subgraph Input["Query & Retrieval"] Q["User Query"] VDB["Vector DB / Knowledge Sources"] end subgraph Augment["Context Integration"] AP["Augmented Prompt<br/>(Query + Context)"] end subgraph Output["Inference"] LLM["LLM Endpoint"] Ans["Grounded Response"] end

Q --> AP VDB --> AP AP --> LLM LLM --> Ans ```

---

[11:59](https://www.youtube.com/watch?v=u-kV64T9h00&t=719s) Enterprise Advantages of Semantic Search and RAG

Pairing semantic search with RAG directly addresses the core vulnerabilities of traditional large language models in enterprise environments. After laughing off a minor slide version mismatch, the speaker emphasizes that traditional LLMs tend to "fabricate details when they are uncertain" due to missing domain context. Grounding model outputs in proprietary enterprise data creates several major operational advantages across an organization:

* **Hallucination Reduction:** Anchor responses strictly to verified corporate knowledge bases to prevent fabricated answers. * **Faster Knowledge Discovery:** Semantic understanding resolves synonyms and conceptual matches, returning the correct resources even when an employee's query phrasing differs from the indexed document text. * **Domain Adaptation Without Retraining:** Tailors outputs to internal company jargon, specialized formats, and private workflows without the high compute cost and complexity of continuous model fine-tuning. * **Regulatory Compliance & Auditability:** Pulls directly from auditable, verified source records, establishing clear traceability and accountability for every answer generated. * **Continuous Synchronization & Better Decisions:** Provides immediate access to updated operational data as soon as documents change, enabling leadership and operational teams to make informed, strategic decisions.

---

[14:43](https://www.youtube.com/watch?v=u-kV64T9h00&t=883s) Search System Architecture: Embeddings, Vector Stores, and Indexing

Building a scalable semantic search stack starts with converting raw text into high-dimensional vector representations. Whether handling unstructured internal documentation or incoming search queries, transformer-based models—such as BERT or OpenAI embeddings—map semantic meaning into a continuous vector space where conceptually related topics cluster together regardless of exact word overlap.

```mermaid flowchart TD accTitle: Semantic Search Ingestion and Indexing Architecture subgraph Ingest["Embedding Generation"] Docs["Raw Documents / Queries"] Trans["Transformer / BERT / OpenAI Models"] end subgraph Storage["Vector Database Storage"] VDB["Vector Databases<br/>(FAISS, Vespa, Weaviate)"] end subgraph Index["Indexing Strategies"] IVF["IVF-PQ Indexing"] HNSW["HNSW Graph Indexing"] end

Docs --> Trans Trans --> VDB VDB --> IVF VDB --> HNSW ```

Once generated, vectors are loaded into specialized vector databases such as FAISS (Facebook AI Similarity Search), Vespa, or Weaviate, which are engineered for ultra-low-latency similarity search. Engineers must carefully select their indexing strategies—such as Inverted File with Product Quantization (IVF-PQ) or Hierarchical Navigable Small World (HNSW) graphs—to strike the right balance between query latency, indexing throughput, memory overhead, and retrieval recall for their specific use cases.

---

[17:00](https://www.youtube.com/watch?v=u-kV64T9h00&t=1020s) Architectural Trade-Offs: Relevance, Latency, and Fact Grounding

Designing production-ready AI search requires balancing relevance against computational latency. Optimizing solely for accuracy by passing large candidate pools through heavy models introduces unacceptable latency. Production architectures resolve this by implementing a two-stage retrieval pipeline:

```mermaid flowchart LR accTitle: Two-Stage Production Retrieval Pipeline subgraph Stage1["Stage 1: Candidate Retrieval"] Q["User Query"] ANN["Approximate Nearest Neighbor (ANN)"] Pool["Candidate Set"] end subgraph Stage2["Stage 2: Re-Ranking & Grounding"] Ranker["Transformer Encoder / Cross-Encoder"] Check["Fact-Checking Validation Step"] Res["Final Production Output"] end

Q --> ANN ANN --> Pool Pool --> Ranker Ranker --> Check Check --> Res ```

* **Two-Stage Retrieval:** A lightweight Approximate Nearest Neighbor (ANN) search rapidly filters millions of vectors down to a small candidate set, after which a more expressive transformer encoder re-ranks the top results. * **Grounding vs. Hallucination Safeguards:** Prompts must explicitly inject the retrieved context, accompanied by an optional automated retrieval-based fact-checking verification step before displaying answers to the user. * **Production Readiness vs. Demos:** Managing these latency, relevance, and validation trade-offs is what separates robust, scalable enterprise deployments from fragile prototype demos.

---

[18:49](https://www.youtube.com/watch?v=u-kV64T9h00&t=1129s) The Future of Enterprise RAG: Multimodality and Agentic Workflows

Looking ahead, RAG architectures are evolving far beyond simple text-based question answering. As enterprise intelligence demands expand, retrieval systems are transforming into proactive, multimodal intelligence backbones across organizations:

* **Multimodal Retrieval:** Moving past plain text to index, search, and reason across mixed media, including diagrams, presentations, images, and video feeds. * **Real-Time Dynamic Knowledge Ingestion:** Incorporating live data streams and immediate updates without requiring time-consuming, full-database re-indexing cycles. * **Self-Improving Retrieval:** Leveraging implicit and explicit interaction feedback loops to refine both retrieval ranking and generation accuracy over time without full model retraining. * **Privacy-Preserving RAG:** Enabling cross-departmental and cross-organizational retrieval that enforces strict access controls and compliance boundaries without exposing underlying raw sensitive records. * **Agentic Workflows:** Elevating RAG from static document lookup into autonomous AI agents capable of executing multi-step reasoning, making operational decisions, and taking direct actions based on retrieved enterprise context.

## Notable quotes > How is search evolving beyond keywords into true understanding? In this talk, I’ll explore how semantic intelligence and generative AI are reshaping the future of search—making it more contextual, conversational, and user-centric. — Rahul Raja

> Attendees will leave with actionable ideas for implementing these techniques in their own systems. If you're rethinking your search stack or looking to stay ahead in AI-powered discovery, this session is for you. — Rahul Raja

> [00:04](https://www.youtube.com/watch?v=u-kV64T9h00&t=4s) Today's users no longer want just raw document links or disjointed answers; they expect a conversational, context-aware experience where the search system genuinely understands the intent behind their query rather than merely performing surface-level keyword matching. — Rahul Raja

> [03:07](https://www.youtube.com/watch?v=u-kV64T9h00&t=187s) An inverted index functions by parsing a corpus of documents into individual terms and mapping each term to the specific list of document IDs in which it appears. — Rahul Raja

> [06:28](https://www.youtube.com/watch?v=u-kV64T9h00&t=388s) While these vectors appear as arrays of floating-point numbers, their geometric coordinates capture deep semantic and syntactic meaning. — Rahul Raja

> [09:09](https://www.youtube.com/watch?v=u-kV64T9h00&t=549s) Because general-purpose LLMs are not trained on an enterprise's private or internal data, zero-shot prompting on proprietary subjects often leads models to hallucinate plausible-sounding but incorrect information. — Rahul Raja

> [11:59](https://www.youtube.com/watch?v=u-kV64T9h00&t=719s) fabricate details when they are uncertain — Rahul Raja

> [17:00](https://www.youtube.com/watch?v=u-kV64T9h00&t=1020s) A lightweight Approximate Nearest Neighbor (ANN) search rapidly filters millions of vectors down to a small candidate set, after which a more expressive transformer encoder re-ranks the top results. — Rahul Raja

> [17:00](https://www.youtube.com/watch?v=u-kV64T9h00&t=1020s) Managing these latency, relevance, and validation trade-offs is what separates robust, scalable enterprise deployments from fragile prototype demos. — Rahul Raja

> [18:49](https://www.youtube.com/watch?v=u-kV64T9h00&t=1129s) Elevating RAG from static document lookup into autonomous AI agents capable of executing multi-step reasoning, making operational decisions, and taking direct actions based on retrieved enterprise context. — Rahul Raja

## Mentioned Rahul Raja, LinkedIn, Ai4, BERT, OpenAI, BM25, TF-IDF, FAISS, Vespa, Weaviate, IVF-PQ, HNSW

## Video description Rahul Raja, Staff Software Engineer, LinkedIn

Abstracts

How is search evolving beyond keywords into true understanding? In this talk, I’ll explore how semantic intelligence and generative AI are reshaping the future of search—making it more contextual, conversational, and user-centric. I’ll walk through how embeddings and LLMs enable richer information retrieval, and discuss architectural patterns that balance relevance and latency. Attendees will leave with actionable ideas for implementing these techniques in their own systems. If you're rethinking your search stack or looking to stay ahead in AI-powered discovery, this session is for you.

[Source](https://www.youtube.com/watch?v=u-kV64T9h00)

中文简报

LinkedIn部署两阶段RAG流水线遏制模型幻觉 将近似最近邻向量检索与Transformer重排序相结合,既能消除企业级模型幻觉,又避免了直接生成式推理带来的延迟代价。 Rahul Raja概述了从传统基于关键词的倒排索引及BM25排序向语义向量搜索和检索增强生成(RAG)的技术转型。他详细阐述了Transformer嵌入与余弦相似度如何实现意图驱动的信息检索,将企业专有数据与LLM连接起来,在无需进行昂贵模型重新训练的情况下消除幻觉并简化知识获取流程。该演讲剖析了可扩展基础设施的需求——包括向量数据库、索引策略(HNSW、IVF-PQ)以及两阶段ANN重排序流水线,并展望了迈向多模态检索与智能体工作流的未来方向。 现代搜索正从传统的关键字匹配与静态链接列表,向由语义智能和生成式 AI 驱动的对话式、上下文感知型知识发现体验转变。 (0:04) 传统搜索架构依赖倒排索引及 TF-IDF、BM25 等统计算法,虽擅长精确词法检索,但无法自动识别同义词、转述或概念层面的等价关系。 (3:07) 语义搜索利用 Transformer 模型将查询与文档映射到高维连续向量空间,通过稠密嵌入向量间的余弦相似度计算,捕捉深层语义和上下文关联。 (6:28) 检索增强生成(RAG)通过将语义检索层与大语言模型推理相结合,把企业私有知识注入提示词,有效遏制模型幻觉并提供可审计的事实验证。 (9:09) 为平衡相关性与计算延迟,生产级系统采用两阶段检索流程(ANN 快速粗筛结合 Transformer 精细重排),并逐步向多模态与自主 Agent 工作流延伸。 (17:00)

Reading summary

Rahul Raja of LinkedIn's Search Infrastructure and AI Platform team argues that modern enterprise search must unite dense semantic vector retrieval with generative large language models to overcome lexical search limitations and anchor conversational answers in authoritative corporate data. Overcoming Lexical Limitations Through Vector Embeddings (3:07) Traditional enterprise search relies primarily on inverted indexes and statistical scoring algorithms such as TF-IDF and BM25, which map tokenized terms to document posting lists while normalizing for document length and term frequency saturation. While computationally efficient for exact string lookups, Raja notes that lexical systems suffer from an inherent blind spot: they cannot detect semantic equivalence, failing whenever user phrasing diverges from indexed document text, such as searching for "artificial intelligence" instead of "AI". Semantic search resolves this rigidity by projecting queries and documents into a shared continuous vector space using transformer models like BERT or OpenAI embeddings, typically ranging from 384 to 768 dimensions. Geometric alignment is evaluated using cosine similarity to measure the angular divergence between vectors. This dense representation allows retrieval engines to match conceptual intent and paraphrases—such as linking "fix my laptop screen" with "repair notebook display"—without requiring literal token overlap. Mitigating Hallucinations with Retrieval-Augmented Generation (9:09) General-purpose large language models lack access to proprietary enterprise repositories and frequently fabricate details when uncertain. Retrieval-Augmented Generation (RAG) resolves this grounding deficiency by deploying a semantic retrieval layer as an intermediary between user intent and model generation. When a user submits a query, the system extracts authoritative proprietary context from vector databases, indexed document stores, or enterprise APIs, constructing an augmented prompt before passing the payload to the language model. Grounding generative prompts in verified corporate records curbs model hallucinations and adapts outputs to company-specific terminology without the compute expense of continuous model fine-tuning. Raja also highlights operational benefits, noting that retrieving from auditable, verified source records establishes regulatory traceability while allowing search outputs to update synchronously as underlying business documents change. Production Trade-Offs in Vector Search Infrastructure (14:43) Operating semantic search at enterprise scale introduces sharp trade-offs between retrieval relevance, memory overhead, and system latency. Vector databases such as FAISS, Vespa, and Weaviate deploy specialized indexing strategies—including Hierarchical Navigable Small World (HNSW) graphs and Inverted File with Product Quantization (IVF-PQ)—to balance memory consumption, indexing throughput, and candidate recall. Raja emphasizes that processing massive candidate pools with expressive transformer encoders introduces unacceptable computational latency. Production systems resolve this tension by adopting a two-stage retrieval pipeline: a lightweight Approximate Nearest Neighbor (ANN) search first filters millions of vectors down to a compact candidate set, after which a transformer cross-encoder re-ranks the finalists and runs optional automated fact-checking checks before responses reach the user. The Horizon of Multimodal and Agentic Search (18:49) Raja projects that enterprise RAG is advancing from static text retrieval toward proactive, autonomous organizational intelligence. Future enterprise systems are anticipated to support multimodal retrieval across non-text assets such as technical diagrams, presentations, and video feeds, coupled with dynamic ingestion pipelines that absorb real-time operational streams without requiring full database re-indexing. Beyond media expansion, Raja anticipates that retrieval architectures will integrate interaction feedback loops for continuous self-improvement alongside privacy-preserving boundaries that govern cross-departmental access. Ultimately, RAG is expected to serve as the foundation for agentic workflows, where autonomous systems do not merely surface answers, but execute multi-step reasoning and perform direct operational tasks grounded in enterprise context. While pairing vector retrieval with generative models resolves the primary failure modes of lexical search and unsubstantiated model outputs, Raja underlines that deploying production-grade enterprise RAG requires balancing indexing latency against recall through multi-stage pipelines and enforcing strict fact-validation safeguards.

精炼阅读摘要

LinkedIn搜索基础设施与AI平台团队的Staff软件工程师Rahul Raja指出,现代企业搜索正在从依赖倒排索引与关键词匹配的传统词法检索,跨越式演进为融合稠密语义向量与大语言模型的检索增强生成(RAG)架构,以在私有知识库上提供兼顾上下文意图、低延迟与事实可溯源的交互式问答服务。 传统词法搜索的机制与语义瓶颈 (3:07) 传统搜索引擎的核心底层依赖于倒排索引(Inverted Index),该结构通过将文档语料解析为独立词项,并建立词项到文档标识符列表(Posting Lists)的映射来执行检索。查询时,引擎通过计算多个词项链表的交集或并集返回匹配文档,并依托统计学排序算法进行相关性打分。其中,词频(TF/TF-IDF)评估词项在文档内的局部频率与全语料库的稀缺度,而BM25算法在此基础上引入了文档长度归一化与词频非线性饱和度参数,以防止高频词过度主导文档得分。 然而,倒排索引本质上属于严格的字面词法匹配,存在无法理解语义同义性的底层缺陷。Raja强调,若用户输入“artificial intelligence”而非“AI”,若没有预设的显式规则映射,倒排索引将完全无法识别两者之间的概念等价性。这种词法局限性导致传统系统无法有效应对复杂措辞、同义表达以及用户深层意图的检索需求。 稠密向量嵌入与语义相似度计算 (6:28) 语义检索通过将文本查询与非结构化文档统一映射至连续的高维向量空间,从而突破了字面匹配的桎梏。系统利用基于Transformer架构的嵌入模型(如BERT或OpenAI嵌入模型),将文本转换为固定长度的高维数值向量,常见维度为384维或768维(取决于底层模型的隐藏层宽度)。这类稠密向量的几何坐标能够表征复杂的语义与句法关联,使得字面完全不重合的表述(例如“fix my laptop screen”与“repair notebook display”)在向量空间中实现紧密聚集。 在评估匹配程度时,系统主要采用余弦相似度(Cosine Similarity)算法,通过计算查询向量与文档向量之间的夹角余弦值衡量相关性,夹角越小表明语义对齐程度越高。为支撑大规模工程落地,生成的向量通常被载入专用向量数据库(如FAISS、Vespa或Weaviate),并依赖乘积量化倒排文件(IVF-PQ)或分层可导航小世界图(HNSW)等索引算法,以在毫秒级查询延迟、索引吞吐率、内存消耗与检索召回率之间达成工程平衡。 检索增强生成与两阶段工程权衡 (9:09) 通用大语言模型在面对企业专有或内部数据时极易产生看似合理但脱离事实的幻觉,而检索增强生成(RAG)通过将语义检索层与LLM推理能力解耦结合,解决了这一可靠性难题。RAG流水线涵盖用户输入、多源检索(覆盖向量库、文档库及企业内部API)、权威上下文提取、提示词增强合成以及大模型生成五个环节。此举使企业无需承担持续全量微调模型的高额算力开销,即可低成本适配内部专业术语,并满足合规审计所需的内容溯源要求。 在生产级系统设计中,工程团队必须严格权衡相关性与计算延迟。Raja指出,直接将海量候选文档传入重型模型会引发不可接受的高延迟,因此工业级架构通常采用两阶段流水线:第一阶段通过轻量级的近似最近邻(ANN)搜索在毫秒级内从数百万向量中初筛出小规模候选集;第二阶段由表达能力更强的Transformer编码器或交叉编码器(Cross-Encoder)进行二次精排,并配套检索驱动的事实核查验证步骤,以确保输出结果的高准确率与事实真实性。 未来演进:多模态与自主智能体 (18:49) 面向企业检索的未来演进,Raja预测RAG架构正从单一的纯文本交互向更具主动性的组织级智能中枢转型。在内容模态上,系统正逐步具备跨图表、演示文稿、图片及视频流的多模态联合检索与推理能力;在时效性上,未来的架构需要支持动态数据流的实时摄入,从而摆脱传统全量数据库重建索引的高耗时周期。 此外,未来的企业RAG架构将重点聚焦于权限隔离与智能体化协作。系统不仅需在跨部门数据流转中执行严格的访问控制边界以保护敏感资产,还将依托用户的隐式与显式交互反馈实现检索排序的自主优化迭代。最终,RAG将从被动的文档检索工具升维为具备多步复杂推理与自动化操作决策能力的自主AI智能体(Agentic Workflows),直接基于企业上下文执行端到端业务任务。 Rahul Raja所阐述的技术演进展现了现代企业搜索从离散词项匹配向稠密语义表征与大模型生成融合的深刻转变。尽管RAG架构显著降低了模型幻觉并提升了知识获取效率,但在千万级规模的多模态动态数据环境下,如何在轻量级ANN召回、昂贵重排计算与严格事实校验之间实现生产级延迟与召回率的最优平衡,仍是企业全面落地AI搜索必须直面的核心工程课题。

Detailed notes — zh

## Background 该视频由 Ai4 频道于 2025 年 8 月 29 日发布在 YouTube 平台上。内容由 LinkedIn 搜索基础设施与 AI 平台团队的资深软件工程师 Rahul Raja 主讲,主要探讨语义智能与生成式 AI 如何推动搜索技术从关键词匹配演进为具有上下文感知、对话式且以用户为中心的新型架构,并分享在生产环境中平衡相关性与延迟的工程实践。 ## TL;DR 本演讲系统梳理了现代搜索技术从传统倒排索引、TF-IDF/BM25 词频匹配向基于高维向量嵌入与余弦相似度的语义搜索范式转移。主讲人深入解析了企业级检索增强生成(RAG)流水线架构,阐明其如何通过将 LLM 严密锚定在私有专有数据上来消除幻觉并实现高效的领域自适应。针对工业化落地难题,演讲提出了包含 ANN 初筛与 Transformer 精排的两阶段检索架构以兼顾延迟与精度,并展望了多模态检索与 Agentic 智能体工作流将 RAG 升级为企业核心智能中枢的发展趋势。 ## Atmosphere & style 整场演讲呈现出典型硅谷工业界技术分享的高效、务实与精炼风格,工程师视角的架构图解与硬核权衡分析环环相扣。讲者语速紧凑流畅、逻辑层层递进,其间还穿插了幽默化解幻灯片小笔误的轻松互动,在有限的时间内将底层检索原理、落地工程权衡与前沿 Agentic 愿景融为一体,给观众带来兼具理论深度与实操启发性的视听体验。 ## Key takeaways - [00:04](https://www.youtube.com/watch?v=u-kV64T9h00&t=4s) 现代搜索技术正从传统的字面关键词匹配迈向语义智能与生成式 AI,推动交互方式从在链接列表中翻找转变为富有上下文的对话式问答。 - [03:07](https://www.youtube.com/watch?v=u-kV64T9h00&t=187s) 传统搜索引擎依赖倒排索引及 TF-IDF、BM25 等算法,因基于纯字面匹配,无法识别同义词或用户输入与文档在表述形式上的差异。 - [06:28](https://www.youtube.com/watch?v=u-kV64T9h00&t=388s) 语义搜索通过预训练模型将查询和文档映射为高维向量嵌入,借助余弦相似度等几何度量精准捕捉深层语义和同义概念。 - [09:09](https://www.youtube.com/watch?v=u-kV64T9h00&t=549s) 直接向大语言模型提问企业私有领域问题极易引发模型幻觉,而 RAG 能够通过语义检索将回答严格锚定在企业私有专有数据之上。 - [10:54](https://www.youtube.com/watch?v=u-kV64T9h00&t=654s) RAG 流水线通过将用户原始提问与向量检索召回的领域上下文拼接为增强提示词(Enhanced Prompt),从而使大模型生成可信的针对性回答。 - [11:59](https://www.youtube.com/watch?v=u-kV64T9h00&t=719s) 企业采用 RAG 与语义搜索无需进行高成本的模型重新预训练或微调,即可快速实现领域自适应,并提供清晰的数据溯源与审计能力。 - [14:43](https://www.youtube.com/watch?v=u-kV64T9h00&t=883s) 工业级语义系统依赖 Transformer 模型生成高维向量,并存入 FAISS、Vespa、Weaviate 等向量数据库,通过 IVF-PQ 或 HNSW 索引权衡延迟与召回率。 - [17:00](https://www.youtube.com/watch?v=u-kV64T9h00&t=1020s) 为化解生产环境中相关性与延迟的冲突,工业界推荐采用两阶段架构:先用 ANN 快速初筛候选集,再用 Transformer 重排模型精细排序。 - [17:00](https://www.youtube.com/watch?v=u-kV64T9h00&t=1020s) 为了强化事实锚定并遏制模型幻觉,除在提示词中注入上下文外,生产系统还可在输出前引入事实验证(Fact-checking)机制校验一致性。 - [18:49](https://www.youtube.com/watch?v=u-kV64T9h00&t=1129s) 企业级 RAG 的演进前沿正在跨越纯文本问答,迈向多模态检索、实时知识流更新、隐私保护检索以及具备多步自主规划能力的 Agentic 智能体工作流。 ## Detailed walkthrough ### [00:04](https://www.youtube.com/watch?v=u-kV64T9h00&t=4s) 搜索演进:从关键词匹配到语义理解与生成式AI 来自 LinkedIn 搜索基础设施与 AI 平台团队(Search Infrastructure and AI Platform Team)的资深软件工程师(Staff Software Engineer)Rahul Raja 开篇指出,现代搜索技术正在经历一场从传统关键词匹配迈向语义智能与生成式 AI 的深刻变革。在信息检索和检索增强生成(RAG)的场景下,企业通常拥有海量的专有数据库(proprietary databases),用户希望系统能针对特定业务领域进行精准、富含上下文的检索,而非仅仅给出一堆相关度模糊的网页链接。 ```mermaid flowchart LR accTitle: 搜索系统的范式转移 subgraph Traditional["传统搜索范式"] A["输入关键词"] --> B["倒排索引匹配"] B --> C["返回链接列表"] end subgraph Modern["现代智能搜索范式"] D["自然语言意图"] --> E["语义检索与 RAG"] E --> F["LLM 对话式综合解答"] end ``` 用户对搜索系统的预期已经发生了根本性转变:过去用户只能在搜索框输入孤立词组并在链接列表中逐条翻找筛选;而如今,用户期望与系统展开富有上下文关联的“对话式交互”(conversation)。推动这一跨越的核心动力来自两大支柱技术: - **语义智能(Semantic Intelligence)**:超越字面表层形态(surface forms),深层建模与表达用户的真实查询意图与语义内涵。 - **生成式 AI 与大语言模型(LLMs)**:具备极强的理解、归纳、总结与阐释能力,能够基于检索到的上下文动态合成针对性答案。 两者结合构成了查询企业私有专有数据的中枢骨干,使搜索平台变得更丰富、更具上下文感知力且更以用户为中心。 --- ### [03:07](https://www.youtube.com/watch?v=u-kV64T9h00&t=187s) 传统搜索的技术基石:倒排索引与词频排序算法 在剖析语义搜索前,Rahul 首先拆解了传统搜索引擎的技术底层逻辑。传统架构的核心数据结构是倒排索引(Inverted Index),这至今仍是多数科技公司搜索系统的基石。倒排索引将文档集拆解为独立的词项(terms),并建立从词项反向映射到其所在文档列表(Posting List)的索引结构。例如,词项 "AI" 映射到文档 1 和文档 2,而词项 "is" 映射到文档 1 和文档 3。当用户发起多词查询时,系统会从倒排索引中查找命中各个词项的文档并求取交并集。 ```mermaid flowchart TD accTitle: 倒排索引与字面匹配局限性 subgraph Corpus["文档语料库"] D1["Doc 1: AI is cool"] D2["Doc 2: AI platform"] D3["Doc 3: Search is fast"] end subgraph Index["倒排索引结构"] T1["Term: 'AI'"] --> P1["Doc 1, Doc 2"] T2["Term: 'is'"] --> P2["Doc 1, Doc 3"] T3["Term: 'Search'"] --> P3["Doc 3"] end subgraph QueryMatch["查询匹配局限"] Q["用户查询: 'Artificial Intelligence'"] -. 无法字面命中.-> T1 end ``` 这种纯字面匹配机制存在天然局限性:若用户输入的词汇在倒排索引中不存在,系统将直接返回空结果。例如,若文档中只有 "AI",而用户输入了完整的 "Artificial Intelligence",系统因缺乏语义理解能力,无法识别两者在语境上的等价性。为了评估文档相关性并排序,传统引擎主要依赖以下算法: - **TF-IDF(词频-逆文档频率)**:通过词频(TF)提升查询词在当前文档中高频出现的权重,同时借助逆文档频率(IDF)降低在所有文档中广泛出现的常见词权重,兼顾重要性与稀缺度。 - **BM25 算法**:在 TF-IDF 的基础上引入了文档长度归一化(normalization)参数,有效防止因文档过长或某些词频过高而过度主导排序结果。 --- ### [06:28](https://www.youtube.com/watch?v=u-kV64T9h00&t=388s) 语义搜索的核心机制:高维向量嵌入与余弦相似度 语义搜索彻底摆脱了字面字符串比对,转而通过将查询(Query)和文档(Document)转化为高维向量嵌入(Vector Embeddings)来捕捉其深层含义。通过诸如 OpenAI 或 BERT 等预训练模型进行编码后,任意长度的文本都会被映射为固定维度的稠密向量(例如常见维度为 384 或 768,具体取决于模型最终隐层状态的输出长度)。这些浮点数值看似随机,但它们在高维几何向量空间(Embedding Space)中的坐标位置精确刻画了文本的语义特征。 ```mermaid flowchart LR accTitle: 语义向量化与余弦相似度计算 subgraph Vectorization["向量化编码"] Q["查询: 'fix my laptop screen'"] --> EQ["编码模型 (BERT/OpenAI)"] --> VQ["Query Vector: [v1, v2,...]"] D["文档: 'repair broken notebook display'"] --> ED["编码模型 (BERT/OpenAI)"] --> VD["Doc Vector: [d1, d2,...]"] end subgraph Matching["相似度度量"] VQ & VD --> CS["余弦相似度 (Cosine Similarity)<br/>cos(θ) = (A·B) / (||A|| ||B||)"] CS --> R["夹角越小,语义相关度越高"] end ``` 为了衡量文档与查询意图的相关程度,系统使用余弦相似度(Cosine Similarity)等几何距离公式来计算两个向量之间的夹角: - 向量之间的空间夹角越小(余弦值越接近 1),代表两者在语义层面的关联度越高。 - 向量空间能够极其自然地捕捉同义词(synonyms)、同义句重述(paraphrases)以及跨概念关联(如将 "laptop screen" 与 "notebook display" 关联)。 这种基于几何距离的语义匹配能力,构成了后续 RAG 流水线中进行高精度文档检索的底层支柱。 --- ### [09:09](https://www.youtube.com/watch?v=u-kV64T9h00&t=549s) 检索增强生成(RAG)工作流架构 大语言模型虽然具备出色的文本生成能力,但并未在企业的私有专有数据上进行全量训练;如果直接让 LLM 回答企业领域问题,模型极易产生幻觉(hallucinate)。通过将语义搜索与大语言模型结合构建 RAG 流水线,系统能够为 LLM 提供经过精准检索的背景知识,确保生成结果“紧密锚定在自有数据库的事实之上”(grounded in your proprietary data)。 ```mermaid flowchart TD accTitle: RAG 检索增强生成完整流水线 subgraph InputStage["1. 输入与调度"] U["用户问题 / 提示词 (Prompt & Query)"] --> SI["系统接口 (System Interface)"] end subgraph RetrievalStage["2. 检索层 (Retrieval Layer)"] SI --> RL["语义检索调度"] RL <--> KS[("知识库源<br/>向量库 (Vector Stores)<br/>文档数据库 / 外部 API")] end subgraph AugmentStage["3. 上下文增强与生成"] RL --> CTX["返回相关上下文 (Relevant Context)"] CTX --> EP["构建增强提示词 (Enhanced Prompt)"] SI --> EP EP --> LLM["大语言模型 (LLM)"] LLM --> ANS["生成精准、低幻觉的最终回答"] end ``` 标准的 RAG 处理流程主要包含以下核心步骤: 1. **输入阶段**:用户提交具体问题(Query)及带有引导指令的系统提示词(Prompt),传递给系统接口层。 2. **检索调度**:系统接口将查询路由至检索层,利用语义搜索技术对底层的知识源(包含向量数据库 Vector Stores、文档数据库或专用 API)进行相似度召回。 3. **上下文富化**:检索层提取与用户意图最契合的私有上下文片段(Context),将其回传给系统。 4. **增强提示词构建**:系统将用户原始提问与检索召回的领域上下文拼接,组装成信息完备的增强提示词(Enhanced Prompt),进而输入大模型生成事实可信的回答。 ### [10:54](https://www.youtube.com/watch?v=u-kV64T9h00&t=654s) 提示词增强与 LLM 生成 在检索增强生成(RAG)流程的最后环节,系统将用户传入的原始查询语句与从向量数据库或知识源中检索到的上下文信息进行拼合,构建出结构更为丰富的最终提示词(Enhanced Prompt)。此时系统明确掌握了与企业私有数据相关的确切背景,从而将大语言模型(LLM)的生成范围严格限制在已知事实之内。这一机制从根源上遏制了模型的无端臆测,迫使其生成具备事实依据且高度契合特定业务领域的回答。 构建完成的增强提示词随后被发送至 LLM 服务端点。由于整个交互上下文被深度锚定(Anchored)在向量数据库返回的高质量内容中,模型在解析这些上下文后生成的文本能够保持极高的准确度,模型出现“幻觉”(Hallucination)的概率也被降至最低水平。 ```mermaid flowchart LR accTitle: RAG 端到端生成流程 subgraph InputStage["输入与检索阶段"] Q["用户查询 Query"] VDB[("向量数据库 / 知识源")] end subgraph PromptStage["提示词工程"] EP["增强提示词 (Query + Context)"] end subgraph GenStage["生成阶段"] LLM["LLM 服务端点"] OUT["事实性业务回答"] end Q --> EP Q --> VDB VDB -->|"检索相关上下文"| EP EP --> LLM LLM --> OUT ``` --- ### [11:59](https://www.youtube.com/watch?v=u-kV64T9h00&t=719s) 语义搜索与 RAG 在企业级 AI 中的核心价值 演讲者在切换幻灯片时打趣地提到 PPT 上有个小笔误:“这里好像有个拼写错误,抱歉,我手里拿的是不同版本的幻灯片”,随后深入阐述了语义搜索结合 RAG 在企业级 AI 应用中的关键价值。传统 LLM 在面对缺乏背景的不确定提问时极易编造细节;而通过语义搜索将回答锚定在企业专有数据上,能够显著抑制这种幻觉。此外,语义搜索能精准捕获用户意图,哪怕员工输入的搜索词与内部文档的实际用词存在差异,也能瞬间召回最相关的资料,从而大幅减少信息检索耗时并加速组织工作流。 对于企业而言,另一个巨大优势在于领域自适应能力(Domain Adaptation)。各大企业通常拥有独特的行业术语、专属数据格式与私有业务流程,通用基础大模型对此一无所知。借助 RAG 与语义搜索,企业无需经历成本高昂的模型全量重新预训练或微调(Fine-tuning),即可直接输出贴合自身业务语境的高质量结果。同时,系统直接从经过验证且可审计的数据源拉取信息,为每一次 AI 生成提供了清晰的数据溯源能力与问责依据,完美契合严格的行业合规与监管要求。 - **动态知识即时更新**:知识库更新后,检索层能够即时调用最新企业数据,使系统回答与组织架构及业务策略的日常变更保持实时同步。 - **强化战略决策**:团队成员能够稳定获取准确、最新且高度契合业务上下文的高价值信息,从而做出更为精准的战略决策。 --- ### [14:43](https://www.youtube.com/watch?v=u-kV64T9h00&t=883s) 架构设计核心:Embedding 生成与向量数据库索引 在分享还剩最后 5 分钟之际,演讲者迅速切入语义检索与生成式系统的工程落地架构设计。搭建此类系统的第一步是向量嵌入(Embedding)生成:无论是用户查询还是原始企业文档,非结构化文本都需要通过 Transformer、BERT 或 OpenAI 的嵌入模型映射为高维空间向量。该向量能够精准凝练文本的底层语义,即便查询词与文档用词毫不相同,语义相近的概念在向量空间中的几何距离依然会紧密相邻。 生成的高维向量将被存入经过高度检索优化的向量数据库中。业界既有以 FAISS(Facebook AI Similarity Search)为代表的高性能开源方案,也有 Vespa、Weaviate 等企业级向量数据库。这些系统在接收到查询向量后,能够在底层依托向量相似度计算快速定位匹配项。为了在性能与召回精度之间取得最佳平衡,架构师可以针对具体业务场景定制索引策略(例如 IVF-PQ 倒排量化与 HNSW 层次化可导航小世界图索引),从而精准微调检索系统的延迟表现与召回质量。 --- ### [17:00](https://www.youtube.com/watch?v=u-kV64T9h00&t=1020s) 生产系统中的关键权衡:相关性与延迟、事实锚定与幻觉 将语义检索与生成式搜索从实验室 Demo 推向工业级生产环境时,必须系统性权衡多项技术指标。其中最核心的冲突在于“相关性与延迟的权衡”(Relevance vs. Latency)。如果单纯追求极致的相关性并叠加复杂模型处理,系统端到端耗时将难以承受。工业界推荐采用两阶段检索架构(Two-stage Retrieval Pipeline)来化解这一矛盾: 1. **第一阶段(初筛候选集)**:利用 ANN(近似最近邻)等轻量级算法在大规模向量库中进行极速扫描,毫秒级召回初步候选文档列表。 2. **第二阶段(精准重排)**:引入基于 Transformer 架构的重排模型(Reranker),仅对少量初筛结果进行深度计算与精细排序。 ```mermaid flowchart TD accTitle: 生产环境两阶段检索与事实验证架构 subgraph Stage1["第一阶段:初筛 (低延迟)"] Q["用户查询向量"] --> ANN["ANN 近似最近邻检索"] ANN --> CR["初筛候选集 (Candidates)"] end subgraph Stage2["第二阶段:精排 (高相关性)"] CR --> RERANK["Transformer 重排模型"] RERANK --> TOP["Top-K 优质上下文"] end subgraph Stage3["第三阶段:生成与事实校验"] TOP --> LLM_GEN["LLM 增强生成"] LLM_GEN --> FC{"事实一致性校验 (Fact Check)"} FC -->|"校验通过"| RESP["最终可信回答"] end ``` 另一个关键权衡是“事实锚定与幻觉的权衡”(Grounding vs. Hallucination)。为了确保大模型的每一个输出字句都严谨对应真实数据,除了将 RAG 检索到的上下文严格注入提示词外,在系统返回答案前还可引入可选的事实验证(Fact-checking)机制,校验生成内容与检索文档的一致性。这种对边界权衡的严格把控,正是“构建工业级可用系统与做一个演示 Demo 之间的本质区别”。 --- ### [18:49](https://www.youtube.com/watch?v=u-kV64T9h00&t=1129s) 企业级 RAG 的演进前沿:多模态、自进化与 Agentic 工作流 在演讲的最后 1 分钟,演讲者展望了 RAG 技术在企业级 AI 领域的演进趋势。当前主流系统多局限于纯文本处理,而未来的核心方向是多模态检索(Multimodal Retrieval)——系统将直接打通文本、图片、视频等全模态数据源的语义关联,使检索与生成更具信息深度与表现力。 ``` 未来演进方向: ┌────────────────────────────────────────────────────────┐ │ 多模态检索 (Multimodal Retrieval) │ │ ├─ 跨越纯文本,深度融合图文、音视频多源异构数据 │ ├────────────────────────────────────────────────────────┤ │ 无全量重建的实时知识流更新 (Real-time Knowledge) │ │ ├─ 消除昂贵的批处理全量 Re-indexing,实现瞬时数据注入 │ ├────────────────────────────────────────────────────────┤ │ 自进化系统 (Self-improving Systems) │ │ ├─ 基于历史交互行为与隐式反馈自动优化检索质量与生成精度 │ ├────────────────────────────────────────────────────────┤ │ 隐私保护型检索 (Privacy-preserving RAG) │ │ ├─ 在不泄露跨部门原始敏感数据的前提下完成跨域检索 │ ├────────────────────────────────────────────────────────┤ │ Agentic 智能体工作流 (Agentic Workflows) │ │ ├─ 超越简单问答,自主进行多步规划、独立决策并调用工具 │ └────────────────────────────────────────────────────────┘ ``` 演讲者总结道,RAG 正从单一的问答工具,向执行多步骤复杂任务、具备自主决策与行动能力的“智能体工作流”(Agentic Workflows)跨越,最终“成为整个企业的核心智能中枢层(Central Intelligence Layer)”。演讲在热烈的掌声中准时收尾。 ## Notable quotes > [00:04](https://www.youtube.com/watch?v=u-kV64T9h00&t=4s) 对话式交互 — Rahul Raja > [03:07](https://www.youtube.com/watch?v=u-kV64T9h00&t=187s) Artificial Intelligence — Rahul Raja > [06:28](https://www.youtube.com/watch?v=u-kV64T9h00&t=388s) fix my laptop screen — Rahul Raja > [06:28](https://www.youtube.com/watch?v=u-kV64T9h00&t=388s) repair broken notebook display — Rahul Raja > [09:09](https://www.youtube.com/watch?v=u-kV64T9h00&t=549s) 紧密锚定在自有数据库的事实之上 — Rahul Raja > [11:59](https://www.youtube.com/watch?v=u-kV64T9h00&t=719s) 这里好像有个拼写错误,抱歉,我手里拿的是不同版本的幻灯片 — Rahul Raja > [17:00](https://www.youtube.com/watch?v=u-kV64T9h00&t=1020s) 相关性与延迟的权衡 — Rahul Raja > [17:00](https://www.youtube.com/watch?v=u-kV64T9h00&t=1020s) 事实锚定与幻觉的权衡 — Rahul Raja > [17:00](https://www.youtube.com/watch?v=u-kV64T9h00&t=1020s) 构建工业级可用系统与做一个演示 Demo 之间的本质区别 — Rahul Raja > [18:49](https://www.youtube.com/watch?v=u-kV64T9h00&t=1129s) 成为整个企业的核心智能中枢层(Central Intelligence Layer) — Rahul Raja ## Mentioned Rahul Raja, LinkedIn, Ai4, OpenAI, BERT, Transformer, FAISS (Facebook AI Similarity Search), Vespa, Weaviate, BM25, TF-IDF, HNSW, IVF-PQ ## Video description Rahul Raja, Staff Software Engineer, LinkedIn Abstracts How is search evolving beyond keywords into true understanding? In this talk, I’ll explore how semantic intelligence and generative AI are reshaping the future of search—making it more contextual, conversational, and user-centric. I’ll walk through how embeddings and LLMs enable richer information retrieval, and discuss architectural patterns that balance relevance and latency. Attendees will leave with actionable ideas for implementing these techniques in their own systems. If you're rethinking your search stack or looking to stay ahead in AI-powered discovery, this session is for you. [Source](https://www.youtube.com/watch?v=u-kV64T9h00)

Source quotes

[0:04] Rahul Raja: 对话式交互 [3:07] Rahul Raja: Artificial Intelligence [6:28] Rahul Raja: fix my laptop screen [6:28] Rahul Raja: repair broken notebook display [9:09] Rahul Raja: 紧密锚定在自有数据库的事实之上 [11:59] Rahul Raja: 这里好像有个拼写错误,抱歉,我手里拿的是不同版本的幻灯片 [17:00] Rahul Raja: 相关性与延迟的权衡 [17:00] Rahul Raja: 事实锚定与幻觉的权衡 [17:00] Rahul Raja: 构建工业级可用系统与做一个演示 Demo 之间的本质区别 [18:49] Rahul Raja: 成为整个企业的核心智能中枢层(Central Intelligence Layer)

Source quotes

Rahul Raja: How is search evolving beyond keywords into true understanding? In this talk, I’ll explore how semantic intelligence and generative AI are reshaping the future of search—making it more contextual, conversational, and user-centric. Rahul Raja: Attendees will leave with actionable ideas for implementing these techniques in their own systems. If you're rethinking your search stack or looking to stay ahead in AI-powered discovery, this session is for you. [0:04] Rahul Raja: Today's users no longer want just raw document links or disjointed answers; they expect a conversational, context-aware experience where the search system genuinely understands the intent behind their query rather than merely performing surface-level keyword matching. [3:07] Rahul Raja: An inverted index functions by parsing a corpus of documents into individual terms and mapping each term to the specific list of document IDs in which it appears. [6:28] Rahul Raja: While these vectors appear as arrays of floating-point numbers, their geometric coordinates capture deep semantic and syntactic meaning. [9:09] Rahul Raja: Because general-purpose LLMs are not trained on an enterprise's private or internal data, zero-shot prompting on proprietary subjects often leads models to hallucinate plausible-sounding but incorrect information. [11:59] Rahul Raja: fabricate details when they are uncertain [17:00] Rahul Raja: A lightweight Approximate Nearest Neighbor (ANN) search rapidly filters millions of vectors down to a small candidate set, after which a more expressive transformer encoder re-ranks the top results. [17:00] Rahul Raja: Managing these latency, relevance, and validation trade-offs is what separates robust, scalable enterprise deployments from fragile prototype demos. [18:49] Rahul Raja: Elevating RAG from static document lookup into autonomous AI agents capable of executing multi-step reasoning, making operational decisions, and taking direct actions based on retrieved enterprise context.

Original transcript

[0:04] Hey, good evening everyone. So yeah, I'm [0:06] uh Rahul. I'm a staff software engineer [0:09] at LinkedIn. I work in the search [0:11] infrastructure and AI platform team. [0:14] So yeah, today I'm going to talk about [0:17] revolutionizing search and the power of [0:20] semantic intelligence and how especially [0:23] uh generative AI is also [0:26] kind of helping us from moving to the [0:29] traditional like keyword based search [0:32] models that we had to a more semantic [0:35] intelligence and semantic search. So [0:37] since uh this track is about retrieval [0:40] augmented generation. So we'll also see [0:43] uh how we can use semantic intelligence [0:45] and the power of like context based [0:48] search which is called a semantic search [0:50] to do a more context based retrieval. [0:54] This is because often we have our like [0:57] proprietary databases where we want to [1:00] query and get some information related [1:03] to only that domain. So we'll see how [1:07] semantic search and also like we have to [1:10] use like both of them together. So we'll [1:11] see how both like are useful to do that. [1:15] So okay [1:19] yeah so traditionally as I already [1:22] mentioned search has been about one [1:24] thing like helping people what they need [1:26] but the way that we uh uh like use [1:29] search systems they have been evolving [1:31] how what we expect from search. So we [1:33] have moved from days where we uh just [1:36] let's say type some query and we want [1:38] the system to give us some results some [1:40] documents and we just shift through a [1:42] list of links. So today users they don't [1:45] want like just answers. They want kind [1:47] of like a conversation with the search [1:49] system. They want like context and they [1:52] want that the search system should be [1:53] able to understand the context of the [1:55] query rather than just returning a key [1:58] keyword based documents. So that shift [2:01] which is from this keyword matching to [2:04] to more kind of a semantic understanding [2:06] this powered by two major forces. So one [2:10] of them is semantic intelligence which [2:11] is our ability to represent the meaning [2:14] of what a user wants to search for the [2:16] query and not just the surface forms [2:19] and another one obviously is generative [2:21] AI and particularly LMS. So now they [2:24] have become so powerful that they can [2:26] like synthesize they can summarize they [2:29] can explain based on like what they [2:31] retrieve and the whole context of it. So [2:34] in this talk like on the further slides [2:36] we'll see how these two forces they [2:39] combine together to transform search [2:41] into a more like platform which is more [2:44] rich uh more contextual and also it's [2:46] more userentric. [2:48] So again this is uh uh in in another [2:51] track. So we'll look at how semantic [2:53] search and LLM they create kind of a [2:55] backbone for querying your proprietary [2:57] data where you use it to answer queries [3:00] which are more conversational like which [3:01] are more contextual. [3:06] [Music] [3:07] Okay. So this is just to give a brief [3:11] intro like on the architecture. So this [3:13] is what traditional search works at a [3:16] technical level. So let's say we have a [3:18] bunch of documents. So document three [3:20] has let's say it has all these terms. [3:22] Document one has yeah is cool and second [3:25] one has something else and third [3:26] document has some some other sentences. [3:29] Now so in order to uh like query in [3:33] order to take a user query and serve [3:35] some search results out of it we [3:37] traditionally what we have called an [3:39] inverted index data structure. [3:41] So these uh inverted indexes usually are [3:44] still like uh they are still the major [3:47] like uh uh platform how search is done [3:50] in majority of the technology companies. [3:53] So we build an inverted index and this [3:55] is nothing but as the name suggests it's [3:57] an index search index but uh in in the [4:00] inverted form. So here is what it looks [4:02] like for all the documents that we have [4:05] here. So the left portion is just [4:08] contains uh all the terms uh in these in [4:11] these sentences. So for example AI is [4:13] one term, a is one term, cool is another [4:16] term and then on the right side we just [4:20] uh like map these terms with all the [4:22] documents where it's appearing. So you [4:24] can see the first term which is AI it [4:26] appears in doc one and do two and then [4:29] similarly is it appears in doc one and [4:31] do three and so on. [4:34] So in this case let's say if a user [4:35] wants to search for some query which has [4:38] multiple words. So what the system does [4:41] is it just combines all the documents [4:43] where these terms are appearing and it [4:45] will just return the results to the user [4:47] and then in the in those documents the [4:49] user can open and see or like is the [4:52] search query or the relevance like what [4:54] they want to search for is present in uh [4:56] that document or not. So [5:00] yeah, so as you see like this is working [5:02] just uh based on a simple like keyword [5:05] based matching. So in this case let's [5:07] say if a user wants to search something [5:09] which is not present in the inverted [5:11] index. So the search system won't be [5:13] able to return anything. Let's say [5:14] instead of AI I search for artificial [5:18] intelligence. So this system won't know [5:20] that artificial intelligence is [5:22] semantically or contextually same as AI. [5:25] So this is purely word based search. Now [5:28] to rank these documents we have few [5:32] algorithms which are still being used uh [5:34] in in search search engines. So we have [5:36] TF and we also have BM25. So TF it [5:40] stands for term frequency. Yeah I think [5:42] and this uh and this is used to just [5:45] rank all the documents that is returned [5:47] by query. So and TF TF it tries to boost [5:51] those terms which occur frequently in [5:53] the document and it also tries to like [5:57] find the terms which are rare across all [5:58] the documents. So in a way it's trying [6:00] to capture like both the importance of [6:03] the query importance of the document and [6:05] also the uniqueness where the query is [6:07] the term is appearing in all the [6:08] documents. So BM25 it improves slightly [6:12] upon TF by adding a normalization term [6:15] and it tries to uh like prevent the [6:18] terms which are overly which are very [6:20] frequent from dominating the search [6:21] result. [6:25] [Music] [6:28] Okay. So this is what the semantics of [6:31] the mechanics of semantic search looks [6:33] like. So as we saw traditional search [6:36] what it was was doing is was just [6:38] literally searching through an inverted [6:39] index and we can we just store that [6:41] inverted index that big data structure [6:44] somewhere. So now semantic search works [6:46] by understanding the meaning of the [6:48] query that user wants to search and it [6:50] does that by converting uh all the both [6:53] the query and the documents which are [6:56] there where we want to search for into [6:58] what we call as embeddings. So [6:59] embeddings are nothing but [7:01] highdimensional vectors which are used [7:03] to capture the semantic meaning of the [7:05] text. So as an example, let's say my [7:08] query is fix my laptop screen. So if I [7:10] encode it using some model, let's say [7:12] OpenAI model or B model. After encoding, [7:15] it will give me a vector. Now these [7:17] vectors [7:18] are some random numbers of a fixed size. [7:21] That size is determined by what model [7:23] are you using. So similarly, we have a [7:25] document here. This document contains [7:27] this sentence. So if we try to create an [7:30] embedding of that also it will create [7:32] another embedding vector. So these [7:34] vectors it might look like it has some [7:37] random numbers but the position they [7:40] have some exact position in the [7:41] embedding in the embedding space and [7:43] that position it determines the exact [7:46] meaning of those sentences. So now to [7:48] determine let's say uh I have I have an [7:50] embedding vector for the query I have an [7:52] embedding vector for the document which [7:54] I want to match it with. Now to [7:56] determine how relevant a document is to [7:58] a query we'll use something called as [8:00] cosine similarity. There are many other [8:02] like similarity equation [8:05] terms or equations we can use. One of [8:07] them is cosine similarity. So that will [8:09] measure the angle between these two [8:12] vectors and the smaller the angle [8:14] between these two vectors are the more [8:16] semantically similar they are. So in [8:18] this way we can like very easily figure [8:20] out if this query is matching [8:23] semantically to this document or not. So [8:27] yeah in practice we have embeddings of [8:29] fixed size like 768 384 are just some [8:32] sizes. It's totally dependent on the [8:34] what model are you using what's the [8:37] length of the hidden state of the final [8:39] state of the model is and they help us [8:41] to capture these nuance relationship. [8:43] For example, if you want to find out if [8:45] these two words are synonyms of each [8:47] other, if you want to figure out they [8:49] are paraphrases or related concepts. So [8:51] we can do that using cosign similarity. [8:55] And this is what the foundation of rag [8:58] pipelines is that uh we do accurate [9:00] retrieval of documents which are [9:02] semantically related. [9:07] [Music] [9:09] Okay. So this uh diagram walks through [9:12] the pipeline of uh retrieval augmented [9:15] generation workflow which combines both [9:17] semantic search and of course large [9:20] language model is the foundation of that [9:22] to produce uh queries or answers which [9:25] are accurate and more grounded in what [9:28] database that you are using. For a [9:30] company it's usually proprietary data [9:32] when we query something we don't want [9:33] our LLM to generate some random answers [9:36] because an LLM is not usually trained on [9:39] your company data. So usually it does [9:40] that it will try to elucinate but rags [9:43] using semantic intelligence is what will [9:45] keep the answers grounded. [9:48] So this process it begins with first a [9:51] prompt and a query. Now this query can [9:53] be a user's question and prompt is they [9:56] pro want to provide some guiding [9:57] instructions to to the LLM of course. So [10:00] this input is will be passed to the [10:03] system interface. Now the system will [10:05] now send the query to the retrieval [10:07] layer. So in this retrieval layer is [10:09] where we will use the semantic search. [10:12] So uh in this retrieval layer we'll have [10:14] some we'll have some knowledge sources. [10:17] So these knowledge sources are uh inter [10:19] like typically these are document [10:21] databases. These are vector stores which [10:23] are used to like store these vector [10:25] embeddings or they can even be APIs. [10:29] So now as part of step three the [10:31] retrieval layer will return the relevant [10:33] context and this is the information [10:35] which we will use to enrich the context [10:38] with the user supplied to like get the [10:40] most to get the uh uh to get the [10:43] information which is relevant to our [10:45] data. So this context is then brought [10:47] back to the system and as part of step [10:50] four we create an enhanced prompt. So [10:52] this prompt is uh this prompt is created [10:54] by combining the original prompt with [10:56] the user passed the query that we have [10:58] and the retrieval retrieved context that [11:01] we got from our vector DB or uh the [11:03] knowledge sources. So this now that we [11:07] have the end context context we already [11:10] have like by this context we mean that [11:12] we know what we want to search uh with [11:15] respect to our data. So this will ensure [11:17] that the LLMs it won't try to [11:19] hallucinate. It will try to give you a [11:21] factual and domain specific answer and [11:24] that's what step five does it sends all [11:27] of these to the LM endpoint. Now this [11:29] LLM endpoints it will use this uh [11:32] enhanced prompt and it will try to [11:34] generate a text response. So because all [11:36] this context is anchored in uh this like [11:40] query the the whole term is anchored in [11:42] the retrieved context that we got from [11:44] our DB. So the answer will be like more [11:47] accurate and less likely that the LLM [11:50] will less likely like hallucinate. [11:58] [Music] [11:59] Okay, so this is where it's helpful the [12:04] combination of semantic search and rag [12:06] it's helpful in enterprise AI. Uh [12:08] hallucination is one of the I think [12:10] biggest positive points. So traditional [12:12] LMS they often they try to hallucinate [12:15] when [12:16] okay I think there's a typo here sorry I [12:18] have a different version of a slide here [12:20] okay so traditional LMS they sometimes [12:22] try to fabricate [12:24] details when they are uncertain because [12:27] they don't have all the context for the [12:28] data which we want to query for. So if [12:31] we try to ground the responses in our uh [12:33] enterprise in our proprietary data [12:35] through semantic search we can [12:36] significantly reduce these [12:38] hallucinations. [12:40] They also help in uh enabling faster [12:43] knowledge access. So semantic search it [12:45] retrieves the most uh relevant content. [12:48] So even when the phrased word it's [12:50] slightly different from the documents [12:52] which are actually stored. So this saves [12:54] time for most of the people, most of the [12:56] employees and uh this speeds up the [12:58] workflows in large organizations. They [13:01] also help in uh domain adaptation [13:03] because enterprises they often have [13:05] their own jarens and they have their own [13:07] formats and processes which are like [13:09] very private very individual to them and [13:11] usually the LMS they are not aware of [13:13] that. So if we combine retrieval [13:16] augmented generation with semantic [13:17] search, it will help us to like tailor [13:20] the output according to the company [13:21] specific domain. And one big benefit is [13:24] that it won't require a full retraining [13:26] of the model also because if you want to [13:29] let's say get some uh data from LLM and [13:32] it has not seen that data, you usually [13:34] will have to fine-tune that LM model. [13:38] They also help us in regulatory [13:40] compliance. So pulling because here we [13:42] are pulling the data directly from [13:44] verified and auditable knowledge sources [13:46] and this will help us that the AI will [13:49] uh output the data which is very [13:51] compliant with the industry regulation. [13:53] So in a way this helps in maintaining a [13:56] traceability and also accountability for [13:58] every uh response that we are getting. [14:01] And finally uh enhanced decision making. [14:04] So continuous updates is also one of the [14:05] things. So uh this combination of [14:08] semantic search and rags it allows the [14:10] AI to access the latest enterprise data [14:14] without model uh retraining as I already [14:16] mentioned. So this will keep the [14:18] responses very aligned with any [14:20] operational changes that are there in [14:21] the organization [14:23] and finally it help it helps us in the [14:26] enhanced decision making. So we are [14:29] getting accurate up-to-date very [14:31] contextually relevant data. So teams it [14:33] can help the teams in making making uh [14:35] better strategic decisions. [14:40] [Music] [14:43] Okay, I have five minutes left. So let [14:45] me cover [14:47] yeah some of the architectures. Yeah. So [14:51] now I can I'll talk about like how we [14:53] can uh keep in mind keep in mind some of [14:55] the architectural points while designing [14:58] a system that has semantic plus [15:00] generative search and uh how we can uh [15:03] balance the trade-offs. [15:08] So the first step in any uh uh kind of [15:12] this pipeline is the embedding [15:13] generation. That's the first step in [15:15] enabling semantic search overall. So we [15:17] take some raw text whether it's a query [15:19] or a user document and we convert it [15:21] into a highdimensional vector. So this [15:24] vector in a sense is going to capture [15:25] the meaning of the text and similar [15:28] concepts in terms of query and both [15:30] documents they are going to end up very [15:32] close in the vector representation. So [15:35] even if the words that we use are [15:36] different. So once we have these [15:38] embeddings and uh we store them in [15:41] vector database there are many open [15:43] source vector databases available. face [15:45] Facebook AI similarity search is one of [15:46] them. We have Westpine and V8 also I [15:49] think these are the proprietary ones. So [15:51] these systems they're also very much [15:53] optimized for fast similarity search. So [15:56] if you give uh if you present a vector [15:59] uh to these systems they will do a [16:01] similarity search based on the vector [16:02] representation itself because internally [16:04] they are also storing the vector [16:06] representation of these documents. So [16:08] they also help us to like enable [16:11] semantic search and they do like they're [16:12] very fast and optimized to do that. Of [16:15] course then again we have a choice of [16:17] indexing strategies available in all of [16:19] these vector databases that we have. [16:21] IVFPQHS [16:23] is is one of the indexing strategies [16:25] that can like help determine help us [16:27] determine the it can impact both the [16:30] performance and the accuracy of what [16:31] we're trying to uh uh retrieve. So I [16:34] think that we can fine-tune all these [16:36] things the indexing strategy in all of [16:38] these vector databases to suit our uh [16:41] use cases. Also I think I missed the [16:43] embedding generation. I think this is we [16:46] can do embedding generation with like [16:48] any of the transformer models, open AI [16:50] models or but models and then store [16:52] these embeddings in the vector DBs. [16:56] [Music] [17:00] Yeah. So when uh designing semantic [17:02] search plus generative search we have to [17:04] keep in mind some of the trade-offs. I [17:08] think relevance versus latency is one of [17:09] the tradeoff trade-off which we should [17:11] consider in mind. So we can achieve [17:14] relevance by combining multiple models. [17:16] So we give a query to models. The thing [17:19] is it will take a lot of time if we want [17:22] to focus only on the relevance of the [17:23] query. So there's a trade-off between [17:26] relevance and latency. So we can achieve [17:28] this uh with a two-stage retrieval step. [17:32] So first we can just use a simple [17:34] algorithm like approximate nearest [17:35] neighbor to first get the candidate [17:38] results quickly and then we can use [17:39] another models uh like an transformer [17:42] encoder model to just to again do the [17:44] reanking of just these small terms which [17:46] we retrieve. So in this case it's a [17:48] balance between uh like how much you [17:51] want to retrieve in the first step which [17:53] will help you in getting better speed [17:55] rather than just focusing on relevance. [17:57] M grounding versus hallucination is [18:00] another trade-off. Uh like it also [18:02] focuses on making sure the LM's answer [18:04] that stay that they are always tied to [18:07] the facts that we have. So this means [18:09] like always passing the retrieve context [18:12] that we have uh from our rags into the [18:14] prompt and optionally so we want us we [18:18] want the system to do a retrieval based [18:20] uh fact uh fact check step that whatever [18:23] it uh it tries to return to the user [18:25] that is based and grounded on the actual [18:27] context that we got from the rags. So if [18:30] we just balance these tra uh trade-offs, [18:32] it will like really uh make the system [18:35] production ready versus uh building a [18:37] demo system. [18:39] I just have one minute, so let me just [18:42] skip to the last slide. [18:46] [Music] [18:49] Yeah. So rag is very powerful in itself [18:52] today. So it's more exciting where it's [18:54] heading in the enterprise AI space. So [18:57] first of all I think all the examples [18:59] that I also had they were mostly text [19:01] based models. So we are moving towards [19:04] more more multimodel retrieval where [19:06] systems they don't only want to like [19:09] pull information just from text they [19:11] want to also pull context and info from [19:13] images videos like all the modalities [19:15] that we can store and we have available. [19:17] So this will ensure that the responses [19:20] they are more richer they have more [19:22] context and not only text based. So we [19:25] also uh will see realtime knowledge [19:27] updates. So the retrieval layer layer [19:29] that we have it will always like [19:32] maintain the latest information because [19:34] we will have vector databases which is [19:36] the retrieval layer for us. Now if you [19:38] want to ingest new information in it of [19:40] course in some cases it requires whole [19:42] reindexing of the data. So real time [19:45] means without needing a whole reindexing [19:47] process the retrieval layer should be [19:49] able to produce the latest information. [19:51] Then we'll have self-improving systems. [19:54] So we have retrieval models which [19:56] already they learn from uh every [19:58] interaction that they have. So if like [20:00] they automatically if they learn to [20:02] refine the retrieval quality and [20:04] generation accuracy over time. So that [20:06] will help a lot without actually uh [20:09] retraining the model from scratch. [20:12] Again for sensitive industries we have [20:14] we will have privacy preserving rack [20:16] that will become critical. So this is to [20:19] uh like let the systems not only uh like [20:22] not expose the raw data to them but they [20:25] should be able to retrieve data like [20:27] across all organizations or departments [20:30] without needing needing the raw data. [20:32] Okay. Yeah. Just a minute. Yeah. And [20:34] finally we will have uh agentic [20:37] workflows. So rag powered AI agents that [20:40] right now in the examples also we saw [20:43] that they are just answering a question. [20:44] They are used to retrieve something. But [20:47] for agentic workflows, we want it uh to [20:49] do much more. We want it to like perform [20:52] multi-step task, go make decisions on [20:54] your own and take action based on like [20:56] whatever knowledge that you're [20:58] retrieving. So all of these um [21:00] advancement, they will help to become [21:03] rag, a central intelligence layer for [21:05] the enterprise. [21:07] Okay, I think we're right on time. [21:09] Thanks.