cloudflareAug 6, 2026

Cloudflare AI Search: give your agents a search engine for your data (opens in new tab)

Cloudflare AI Search now automates the components previously needed to build a search system, including crawling, ingestion, embeddings, vector storage, and retrieval. The update adds sitemap-free website discovery, public and custom-domain endpoints, MCP support, and integrations such as EmDash. Cloudflare is also previewing predictable pricing by including embedding and reranking costs when using select default Workers AI models. ## Easier Data Indexing - AI Search can index structured and unstructured data, including files and websites. - Website sources currently must be owned or verified through a Cloudflare zone. - The new **Discover** parsing mode crawls sites without requiring a sitemap by following links, powered by Browser Run’s `/crawl`. - A single AI Search instance can ingest, embed, and retrieve content from a website or collection of sites. ## Unified Search Across Multiple Sources - Multiple AI Search instances can be grouped into a namespace and queried together. - Users can enable public URLs to receive: - `/search` for search requests - `/mcp` for Model Context Protocol integrations - These endpoints can search across multiple websites or instances without requiring authentication. - A Worker can also bind to a namespace and perform a single multi-instance search, with results tagged and cited by source. ## Custom Domains and Access Control - Public endpoints can use custom domains such as `search.example.com/mcp`. - Cloudflare Access can be placed in front of these domains to make search private. - This supports both easily shareable public search and authenticated search for authorized users or agents. ## Pricing Model - Cloudflare is previewing a predictable, scalable pricing model for AI Search. - Embedding and reranking are included at no additional cost when using select default models from the Workers AI catalog. - Customers therefore do not need to estimate token usage for those operations. ## Cloudflare Dev Stack MCP Cloudflare uses AI Search to power its Dev Stack MCP server, which provides coding agents with current, cited documentation. - Separate instances index Cloudflare Docs, Blog, API Docs, Community, Astro, Vite, Vitest, Hono, Replicate, and OpenNext. - These sources can be combined because Cloudflare owns the underlying website data. - A Worker-based MCP server searches all relevant instances in one call. - Search results include citations and identify the originating instance. - Users can alternatively enable public namespace endpoints without writing or deploying a Worker. - The MCP server can be added to an agent with a configuration such as: ```json { "mcpServers": { "dev-stack": { "url": "https://stack.mcp.cloudflare.com/mcp" } } } ``` ## Additional Integrations - Cloudflare’s Blog, Developer Docs, and Cloudflare.com use AI Search internally. - The open-source EmDash CMS has an AI Search plugin that adds semantic search to site content. - AI Search is also used in Cloudflare’s own MCP and documentation experiences. For an existing application or MCP server, the Worker binding offers the most flexibility. For a quick, shareable search service, public `/search` and `/mcp` endpoints provide a simpler deployment path, with custom domains and Cloudflare Access available for branding and security.

semantic-searchcloudflare-workersmcpembeddings+4

awsAug 5, 2026

Amazon DynamoDB now supports real-time vector search at any scale | Amazon Web Services (opens in new tab)

Amazon DynamoDB now offers native vector search, allowing applications to store embeddings beside operational data and query them without a separate vector database. The serverless service provides single-digit millisecond latency, 99%+ recall, horizontal scaling, and support for trillions of vectors. This removes synchronization pipelines, data movement, and additional infrastructure for applications already built on DynamoDB. ## Native Vector Search in DynamoDB - Embeddings are stored directly in DynamoDB as lists of floating-point numbers. - Similarity searches use the `SearchVectors` API and return up to 100 ranked results. - Vector indexes scale horizontally without storage limits or servers to manage. - Pricing follows DynamoDB’s pay-per-request model. - Common use cases include: - Agent memory - Retrieval-augmented generation - Recommendations - Personalized experiences - Anomaly detection ## Supported Search Capabilities - Supports vectors with up to 4,096 dimensions. - Offers three distance functions: - **Cosine**: Useful for semantic text similarity. - **Euclidean**: Useful when vector magnitude is meaningful. - **Dot product**: Useful when both direction and magnitude affect relevance. - Supports optional partition keys to distribute data and scope searches. - Supports inline exact-match filters, but not range operators such as `BETWEEN` or `BEGINS_WITH`. - Search results can include operational attributes through index projections. ## Adding Embeddings to an Existing Table - Generate embeddings with a model such as Amazon Bedrock Titan Text Embeddings, Cohere Embed, or OpenAI embeddings. - Store them in a new attribute, such as `descriptionEmbedding`, using `UpdateItem` or other AWS tooling. - No new DynamoDB data type or schema migration is required because vectors use the existing `List` and `Number` types. ## Creating and Using a Vector Index - Create a vector index on the embedding attribute. - Configure: - Index name - Vector attribute - Embedding dimensions - Distance function - Optional partition key - Filter attributes - Generate a query embedding with the same model used for stored data. - Call `SearchVectors` with the query vector, result count, partition key, and filters. - Scores depend on the distance function: - Lower scores indicate greater similarity for Cosine and Euclidean distance. - Higher scores indicate greater similarity for Dot product. ## Example: Product Catalog Search - A `ProductCatalog` table stores product details such as `productId`, `name`, `description`, `category`, `marketplace`, and `price`. - Product descriptions receive embeddings stored in `descriptionEmbedding`. - A `ProductDescriptionIndex` can use: - `marketplace` as the partition key - `category` as an inline filter - Cosine distance for semantic matching - A query such as “lightweight running shoes for summer” can return the five most relevant footwear products in the US marketplace, along with attributes such as name and price. DynamoDB vector search is best suited to applications whose operational data already resides in DynamoDB and need semantic retrieval without operating a second database or synchronization system.

semantic-searchragserverlessvector-db+2

tossJul 30, 2026

LLMs Are Smart, So Why Don’t They Know How Our Company Works? (opens in new tab)

LLMs handle public knowledge well but struggle with company-specific questions because relevant evidence is scattered across documents, code, meetings, and chat—and may be outdated or contradictory. The post argues that this is not merely a search problem: organizations need a shared layer for managing trustworthy context. Topic addresses this by extracting source-aware units, linking concepts and relationships, and verifying their freshness, consistency, and evidentiary support. ## Why Search Alone Is Not Enough - Search retrieves relevant text but cannot determine whether it is current, authoritative, or consistent with other sources. - A retry-policy example might contain: - Documentation saying requests fail immediately - A meeting discussion proposing three retries - Code currently implementing two retries - Agents must still determine: - Whether the meeting produced a final decision - Which source is newer - Whether the code reflects an intentional change or an unfinished implementation - Whether different sources describe the same behavior - Topic provides a shared context layer so humans and LLMs use the same sources, relationships, freshness information, and conflict states. ## Six Dimensions of Trust Rather than compressing trust into one score, Topic evaluates six separate dimensions: - **Granularity:** Whether the context is a meaningful, independently manageable unit - **Faithfulness:** Whether the source actually supports the claim - **Staleness:** Whether the evidence remains valid - **Canonicality:** Whether different names refer to the same entity - **Consistency:** Whether sources are compatible - **Coverage:** Whether important evidence or perspectives are missing Different checks use different methods: rules and hashes for deterministic validation, LLMs for semantic interpretation, and humans for ambiguous or high-impact decisions. ## Ingesting Documents, Chat, and Code Topic normalizes information into a common `ContentUnit` containing source type, unit type, original URI, content, hashes, timestamps, and source-specific metadata. It uses different boundaries for each source rather than splitting everything into fixed-size text chunks. ### Structured Document Sections - Markdown documents are divided by heading hierarchy. - Parent headings are preserved to retain context. - Long sections are split only when necessary. - URLs, document paths, and creation or modification times remain attached to the unit. ### Conversation Threads - Entire messenger threads are treated as the semantic unit, not individual messages. - Summaries preserve: - Technical identifiers such as function names and file paths - Questions, alternatives, and final outcomes - Decisions versus unresolved issues - The system avoids inventing consensus and ignores threads containing only casual conversation. ### Code Symbols and Semantic Cards - Parsers extract functions, classes, file paths, line ranges, imports, and other symbols without using an LLM. - Multiple symbols are then grouped into **code semantic cards** describing business behavior. - Cards retain domain terms, code identifiers, source spans, and the relevant commit SHA. - LLM-generated cards are checked against actual files, line ranges, supporting spans, and duplicate-card patterns. - Cards are an intermediate layer for connecting code to business concepts, not a replacement for the code itself. ## Extracting Concepts and Relationships - Topic extracts concept candidates and supporting evidence from each content unit. - It preserves the relationship between every concept and its original evidence. - Similar names are not automatically merged merely because they appear close in meaning. - Concepts can be consolidated into canonical entities only when sufficient evidence exists. ### Human Review for Ambiguous Terminology - Normalization and embeddings can identify obvious duplicates. - Internal abbreviations and aliases may require organizational knowledge. - Topic creates synonym proposals with their supporting context. - Humans approve or reject ambiguous aliases; rejected proposals are remembered to prevent repeated suggestions. ### Typed Document–Code Relationships Topic distinguishes among: - `supported_by`: code behavior supports the document’s claim - `contradicted_by`: code behavior conflicts with the document - `mentions`: both refer to the same area, but support or contradiction is unconfirmed Embedding search first narrows possible matches, after which semantic verification is performed. Low-confidence or failed checks do not create relationships; an absent relationship means “not yet verified,” not necessarily “unrelated.” ## Incremental Verification and Change Detection - Stable identifiers and content hashes allow unchanged units to reuse previous extraction and relationship results. - Deleted sources trigger cleanup of dependent relationships. - Code anchors store the validating commit and span hash. - If an anchor disappears, it is marked orphaned. - If the span remains unchanged, semantic verification can be skipped. - If the span changes, faithfulness must be checked again. - Rule-based checks happen before LLM calls, reducing cost and limiting nondeterministic reasoning to cases that require it. Topic’s practical recommendation is to treat trustworthy internal context as a managed system rather than a search result. Preserve source structure, keep evidence attached to every claim, use automation for deterministic work, and route ambiguous organizational judgments to people.

semantic-searchllmhuman-in-the-loopknowledge-graph+4

metaApr 21, 2026

Modernizing the Facebook Groups Search to Unlock the Power of Community Knowledge (opens in new tab)

Facebook has re-architected Groups Search to make community knowledge easier to discover, understand, and validate. Its new hybrid retrieval system combines keyword matching with semantic search, while automated model-based evaluation measures relevance at scale. The result is improved search engagement and relevance without increasing error rates. ## Friction in Community Search - **Discovery:** Traditional lexical search depends on exact words, so a query for “small individual cakes with frosting” might miss posts discussing “cupcakes.” Semantic matching helps connect different phrasing with the same intent. - **Consumption:** Users often must read dozens of comments to identify consensus or useful advice, creating an “effort tax.” - **Validation:** Relevant expertise is frequently scattered across group discussions, making it difficult to evaluate purchases or decisions using community knowledge. ## Hybrid Retrieval Architecture - Queries are tokenized, normalized, and rewritten before retrieval. - The **lexical path**, powered by Facebook’s Unicorn inverted index, retrieves exact or closely matching terms and preserves precision for proper nouns and quotations. - In parallel, the **semantic path** uses a 12-layer, 200-million-parameter Search Semantic Retriever to encode queries into dense vectors. - Approximate nearest-neighbor search over a Faiss index retrieves conceptually similar posts, even when they use different words. ## Multi-Task Ranking - Results from lexical and semantic retrieval are merged for ranking. - The ranking model combines traditional signals such as TF-IDF and BM25 with semantic cosine-similarity scores. - A multi-task, multi-label model jointly optimizes for clicks, shares, and comments. - This approach balances theoretical relevance with the likelihood of meaningful community engagement. ## Automated Relevance Evaluation - Semantic similarity scores can be difficult to interpret, so evaluation was integrated into build verification testing. - Llama 3 with multimodal capabilities acts as an automated judge of search results. - Evaluation recognizes nuanced outcomes, including “somewhat relevant” results that share a broader domain or theme. - This enables scalable measurement of conceptual matching and result diversity without relying entirely on human labeling. ## Results and Future Work - The hybrid system outperformed the keyword-only baseline in offline quality and search-engagement metrics. - Facebook reports improved relevance without higher error rates. - Future plans include using LLMs directly during ranking and dynamically adapting retrieval parameters to query complexity. The approach demonstrates that combining lexical precision with neural semantic understanding can make community search more effective. Further LLM integration may help the system interpret post content and tailor retrieval more intelligently.

semantic-searchdatabase-designmachine-learningnlp+4

dropboxNov 17, 2025

How Dash uses context engineering for smarter AI (opens in new tab)

Dash evolved from a traditional RAG search system into an agentic AI that can interpret information, plan tasks, and act on users’ behalf. Dropbox’s experience shows that better agent performance comes not from adding more tools and data, but from carefully engineering context: limiting choices, filtering for relevance, and delegating complex work to specialized agents. The central conclusion is that precise, timely context improves reasoning speed, accuracy, and efficiency. ## From Search to Agentic AI - Dash initially combined semantic and keyword search to retrieve documents and generate concise answers. - Users began asking it to interpret, summarize, and act on retrieved information. - This required Dash to plan and execute multi-step tasks rather than simply search and summarize. - The resulting challenge was determining which information and tools the model actually needed at each stage. ## The Cost of Too Many Tools - Every tool adds descriptions and parameters to the model’s context window. - More tools expand the model’s decision space, potentially causing slower or less reliable choices. - Tool definitions also consume tokens, increasing cost and reducing room for reasoning. - Longer-running tasks suffered from “context rot,” where accumulated tool-call information degraded accuracy. - Model Context Protocol (MCP) standardizes tool descriptions, but does not eliminate the problem of excessive context. ## Limiting Tool Definitions - Dash found that exposing retrieval tools from many services—such as Confluence, Google Docs, and Jira—created confusion. - Instead of requiring the model to choose among numerous APIs, Dash consolidated retrieval into one purpose-built tool backed by its universal search index. - A single retrieval interface: - Simplifies planning - Reduces tool-selection errors - Keeps the context window focused - Provides consistent access across connected services - The same principle shaped Dash’s MCP server, which exposes retrieval through one lean tool to applications such as Claude, Cursor, and Goose. ## Filtering Context for Relevance - Retrieved information is not automatically useful for the task at hand. - Dash combines data from multiple sources in a unified index and uses a knowledge graph to connect people, activity, and content. - These relationships help rank results according to the query and the user’s context. - By filtering results before presenting them to the model, Dash ensures that each piece of supplied context is relevant. - Precomputing the index and graph allows runtime retrieval to remain fast and focused. ## Using Specialized Agents for Complex Tasks - Some tools require substantial instructions and examples to use correctly. - Dash Search became complex because query construction involves: - Understanding user intent - Mapping intent to index fields - Rewriting queries for semantic matching - Handling typos, synonyms, and implicit context - Adding these instructions directly to the main planning agent consumed context that could otherwise support broader reasoning. - Dash therefore moved search into a specialized agent: - The main agent decides when searching is necessary. - The search agent independently constructs the query using its dedicated prompt. - This division lets the main agent focus on the overall task while the specialist handles search details. Dash’s approach recommends treating context as a limited engineering resource. Use a small number of well-designed tools, pre-filter information for relevance, and delegate technically demanding subtasks to specialized agents rather than overwhelming one general-purpose model.

semantic-searchmodel-context-protocolagentic-airag+3

figmaOct 24, 2024

How We Built AI-Powered Search in Figma | Figma Blog (opens in new tab)

Figma’s AI search emerged from a practical problem: designers often struggled to find existing work, sometimes relying on Slack to locate files from screenshots or vague descriptions. The team initially pursued design autocomplete, but research showed that designers more often reuse and adapt prior work than create from scratch. This led Figma toward visual and semantic search, launched in 2024, using AI to help users find and reuse relevant designs. ## The Problem of Finding Existing Designs - Designers frequently knew what they wanted visually but not where the source file was located. - At Figma, hundreds of Slack messages showed designers asking colleagues to identify files from screenshots or descriptions. - Traditional keyword search was insufficient when users did not know a component’s exact name or file location. ## From Design Autocomplete to AI Search - Figma began with a three-day AI hackathon in June 2023. - One prototype, design autocomplete, suggested likely next components—for example, a “Get started” button in an onboarding flow. - The team believed AI should handle repetitive tasks so designers could focus on higher-level thinking and user needs. - Internal testing and user interviews revealed that designers commonly revisit old explorations, reuse existing work, and build on prior designs rather than starting from nothing. ## Using Search to Improve AI Suggestions - Figma built search infrastructure alongside autocomplete. - Retrieval-Augmented Generation (RAG) could improve AI responses by supplying relevant examples from existing designs. - Finding designs similar to the user’s current work could make autocomplete recommendations more useful and context-aware. - As testing continued, the team recognized that locating and reusing existing work was a more fundamental need than predicting the next component. ## Visual and Semantic Search - **Visual search** allows users to search with: - A screenshot - A selected frame - A quick sketch - **Semantic search** interprets the meaning and context of text-based queries, even when users do not know the precise component name or description. - Search results can help users discover designs and components and then open, preview, or insert them into their projects. Figma’s experience shows that successful AI features often emerge through iteration rather than from an initial prototype. The practical recommendation is to start with real user behavior, test ambitious ideas, and use AI where it removes friction—in this case, helping designers quickly find and reuse relevant existing work.

semantic-searchllmragai-search+2