aws·Aug 10, 2026·3 min readCurated summary

AWS Weekly Roundup: AWS Heroes Summit, Web Search on Amazon Bedrock, Dogwood, Kiro Crew, and more (August 10, 2026) | Amazon Web Services

The August 10, 2026 AWS Weekly Roundup highlights the AWS Heroes Summit and several launches focused on AI agents, modernization, data retrieval, and developer productivity. Major updates include web search for Amazon Bedrock, vector search in DynamoDB, dedicated AgentCore runtime instances, and faster Lambda networking. AWS also introduced Dogwood for temporal agent governance, portable Agent Plugins, and Kiro Crew for persistent multi-agent development. ## AWS Heroes Summit - AWS Heroes from around the world gathered for technical collaboration, deep dives, and feedback sessions with AWS teams. - The invite-only event featured: - A fireside chat with AWS CEO Matt Garman. - An AMA with James Hamilton. - Breakout sessions led by AWS product teams. - The summit emphasized knowledge sharing, community support, and collaboration between AWS experts and internal teams. ## New Amazon Bedrock and AI Capabilities - **Web Search on Amazon Bedrock** - OpenAI models, including GPT-5.4, GPT-5.5, and GPT-5.6 variants, can browse and retrieve current information from the internet. - Applications can use real-time web content while keeping data within a secured AWS environment with zero data egress. - **Runtime Instances for Bedrock AgentCore** - AI agents can run on dedicated runtime instances. - This provides more predictable performance, execution control, and costs. - **Vector Search for DynamoDB** - Applications can store and query vector embeddings alongside existing DynamoDB data. - This supports semantic retrieval and grounding for AI agents without deploying a separate vector database. ## Modernization and Lambda Networking - **AWS Transform continuous modernization** - Now generally available for analyzing and remediating technical debt across repositories. - Supports ongoing modernization of mainframe and legacy workloads rather than one-time migration projects. - Integrates with the AWS Transform Kiro Power and agent plugins. - **Higher Lambda bandwidth** - Lambda functions configured with at least 2 GB of memory and running outside a VPC can receive proportional network bandwidth increases. - Bandwidth ranges from 625 Mbps at 2 GB to 3,000 Mbps at 10 GB. - The change benefits data-intensive workloads and communication with other AWS services. ## Agent Governance and Portability - **Dogwood** - AWS open-sourced Dogwood, a governance language designed for AI agents. - It extends Cedar policies with temporal conditions. - AgentCore temporal policies can make decisions based on an agent’s prior actions within a session, not only the current request. - **Agent Plugins** - AWS supports an open, vendor-neutral specification for packaging agent extensions. - Developers can package an extension once and use it across compatible tools such as Kiro, VS Code, and Cursor. ## Kiro Crew - Kiro Crew provides a persistent workspace for collaborative, multi-agent development. - It is designed for work spanning multiple repositories, tools, and days rather than a single chat session. - Developers can run several efforts in parallel or delegate tasks to subagents that report results later. AWS’s latest updates point toward more capable, governed, and portable AI-agent workflows, while also improving modernization tools and infrastructure performance. Developers can explore the related documentation, AWS events, and the AWS Builder Center for further resources.

Read original(opens in new tab)

Vector DbAI AgentsAWSAmazon Bedrock+4

aws·Aug 5, 2026·3 min readCurated summary

Amazon DynamoDB now supports real-time vector search at any scale | Amazon Web Services

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.

Read original(opens in new tab)

Vector DbRAGServerlessAmazon Dynamodb+2

aws·May 28, 2026·2 min readCurated summary

Introducing the next generation of Amazon OpenSearch Serverless for building your agentic AI applications | Amazon Web Services

Amazon’s next-generation OpenSearch Serverless is a managed search and vector engine optimized for agentic AI applications. It scales from zero to thousands of requests per second, creates resources in seconds, and can reduce costs by up to 60% compared with clusters provisioned for peak demand. The release is generally available across supported AWS commercial Regions and integrates with tools such as Vercel, Kiro, Claude Code, and Cursor. ## Elastic Scaling and Cost Optimization - Scales capacity up to 20 times faster than the previous generation. - Supports scale-to-zero when idle, minimizing compute costs. - Charges separately for compute through OpenSearch Compute Units (OCUs), storage in GB-month, and GPU acceleration where applicable. - Supports capacity limits for indexing and search, with minimum capacity set to zero and configurable maximums. ## Creating Next-Generation Collections - Collections can be created through the Amazon OpenSearch Service console, AWS CLI, or SDKs. - The console’s **Express create** option automatically applies default settings and matching security policies. - At launch, supported collection types are: - Full-text search (`SEARCH`) - Vector search (`VECTORSEARCH`) - Users who need the existing infrastructure can select the classic OpenSearch Serverless generation. - Collections inherit their generation from a parent collection group. Example CLI workflows create a next-generation collection group with standby replicas and then create a search collection within it. ## Integrations for Agent Development - Vercel users can create or connect OpenSearch Serverless collections directly from the Vercel console. - OpenSearch Agent Skills bring search-specific knowledge, best practices, and multi-step workflows into agents using Claude Code, Cursor, and Kiro. - Kiro’s OpenSearch Launchpad provides guided architecture planning for building search applications. ## Availability - The next generation is generally available in all AWS commercial Regions where OpenSearch Serverless is currently offered. - AWS recommends consulting the OpenSearch Serverless documentation and pricing information for configuration and cost details. The release is intended to let developers deploy production-ready search and vector backends quickly, while avoiding the infrastructure management and peak-capacity costs associated with provisioned OpenSearch clusters.

Read original(opens in new tab)

Vector DbAI AgentsClaude CodeAws Cli+4

line·May 7, 2026·3 min readCurated summary

ODW #5: Building a RAG System with a Vector DB and Agent Skills

The workshop demonstrated how a lightweight RAG system can make large collections of technical documentation easier for developers and AI agents to use. Using ChromaDB, Swift Evolution proposals were indexed locally and exposed to Claude Code through MCP. Agent skills then simplified searches by teaching the agent which collection, metadata, and query practices to use. The approach improves document discovery and can support code generation and review. ## Why RAG Is Needed - Large application teams maintain extensive documentation and architectural guidelines. - Developers often spend significant time searching for information about: - Introducing dependencies - Resolving build errors - Following architectural rules - Asking experts can solve problems, but consumes time for both the questioner and the responder. - RAG provides AI agents with structured, searchable knowledge so they can answer questions more accurately using internal documents. ## Building a RAG System with ChromaDB - The workshop used ChromaDB, an open-source local vector database with Python and JavaScript client libraries. - Swift Evolution proposals served as the sample dataset: - Approximately 500 Markdown documents - Consistent structure and proposal IDs such as `SE-0400` - Metadata including implementation status and authors - Participants indexed the documents locally and connected the database to Claude Code through an MCP tool. - This allowed the coding agent to retrieve and reference Swift language proposals during conversations. ## Improving Search with Agent Skills - MCP exposes the available database tools, but the agent still needs to know: - Which collection contains the relevant data - Which metadata fields are useful - How to formulate effective queries - A dedicated `searching-swift-evolution` skill encoded this knowledge, including: - The `swift-evolution` collection name - Proposal ID formats such as `SE-0255` and `ST-0001` - Metadata such as `Status` and `Authors` - A recommendation to query in English - With the skill, users could issue simple requests such as “Investigate SE-0500” without explaining the database structure or MCP workflow. - The workshop also covered skill mechanics, authoring best practices, and practical skill development. - Participants later indexed their own Markdown documents, created search skills, and learned how to deploy the database to LY Corporation’s internal Flava cloud for sharing. ## Potential Applications - Natural-language document search can make internal technical knowledge significantly more accessible. - Coding agents can retrieve relevant documentation automatically before: - Generating code - Reviewing code - Checking compliance with architectural or implementation guidelines - Combining RAG with agent skills or Claude Code sub-agents can embed organizational knowledge directly into development workflows. ## Workshop Design and Results - The online workshop used demonstrations by instructors and mock participants. - More than 1,000 people attended. - Its structure balanced lectures and hands-on exercises: - Lectures explained the core concepts concisely. - Practical demonstrations showed how to apply the system to real work documents. - This balance helped participants understand both the underlying ideas and their practical use. Overall, the workshop showed that a local vector database plus MCP and well-designed agent skills can provide a simple, effective foundation for searchable engineering knowledge and AI-assisted development.

Read original(opens in new tab)

Vector DbAI AgentsModel Context ProtocolRAG+4

cloudflare·Apr 16, 2026·3 min readCurated summary

AI Search: the search primitive for your agents

AI Search is presented as a general-purpose search primitive for AI agents, handling retrieval across code, support documentation, customer history, and agent memory. It combines semantic and keyword search while providing built-in storage, indexing, and dynamically creatable search instances. The result is less infrastructure to build and the ability to maintain separate searchable contexts for agents, customers, languages, or other tenants. ## Why Agents Need Search - Agents often need access to information too large or dynamic to fit in a context window. - Common examples include: - Coding agents searching millions of repository files. - Support agents searching product documentation and ticket history. - Memory systems retrieving relevant past interactions. - Building this independently requires: - A vector index. - Document parsing and chunking. - An indexing pipeline that stays synchronized with changing data. - A separate keyword index and result-fusion layer if lexical search is also needed. ## Hybrid Search - AI Search runs vector search and BM25 keyword search in parallel. - Results are fused into a single ranking. - This supports both: - Semantic matches based on meaning. - Exact-term matches for names, identifiers, and technical terminology. - The blog’s own search is powered by AI Search. ## Built-In Storage and Dynamic Namespaces - New AI Search instances include managed storage and a vector index. - Files can be uploaded directly through an API and indexed automatically. - Developers do not need to configure R2 buckets or external data sources for every instance. - The `ai_search_namespaces` binding allows Workers to create and delete instances at runtime. - Instances can be created per: - Agent. - Customer. - Language. - Other isolated contexts. - Documents can include metadata used to boost rankings at query time. - A single query can search across multiple instances. ## Customer Support Agent Example - The example uses the Cloudflare Agents SDK and Workers AI. - A shared `product-knowledge` instance contains product documentation backed by an R2 bucket. - Each customer receives a separate instance such as `customer-abc123`. - After an issue is resolved, the agent stores a summary of the problem and its fix. - Over time, each customer’s instance becomes a searchable history of previous resolutions. ## Agent Tools and Retrieval Flow - The support agent extends `AIChatAgent` and uses Kimi K2.5 through Workers AI. - It defines tools for: - Searching shared product documentation and the current customer’s history in one call. - Saving a resolution after an issue is resolved. - The model decides when to invoke these tools based on the conversation. - Search results can prioritize recent documents using metadata, such as a descending `timestamp` boost. - The Agents SDK persists the conversation history across reconnects, while AI Search provides retrieval over larger knowledge collections. AI Search is recommended for teams that want agent-ready retrieval without separately assembling vector databases, keyword indexes, storage, and synchronization pipelines. Its dynamically isolated instances are particularly useful for multi-tenant agents and applications that need both shared knowledge and private, continuously growing context.

Read original(opens in new tab)

Vector DbDatabase DesignCloudflareAgents Sdk+4

microsoft·Feb 11, 2026·4 min readCurated summary

How we built the Microsoft Learn MCP Server

Microsoft Learn MCP Server gives AI agents direct, standardized access to current Microsoft documentation through the Model Context Protocol (MCP). Rather than requiring custom APIs, scraping, or embeddings, agents can dynamically discover and use tools for searching documentation, fetching full articles, and finding code samples. Microsoft’s experience shows that successful MCP systems depend not only on retrieval quality, but also on agent-oriented tool design, operational resilience, clear descriptions, and defensive compatibility practices. ## Purpose of Learn MCP Server - Provides trusted, up-to-date Microsoft Learn content to GitHub Copilot and other AI agents. - Uses Streamable HTTP Transport so MCP-compatible clients can connect to a remote server. - Supports three tools: - `microsoft_docs_search` for titles, relevant content sections, and source URLs. - `microsoft_docs_fetch` for retrieving complete article content. - `microsoft_code_sample_search` for locating language-specific code examples. - Grounds agent responses in official Microsoft documentation rather than relying solely on model memory. ## Why MCP Instead of a Traditional API - Conventional APIs require each client to implement: - Authentication and request formatting. - Documentation and integration logic. - Error handling and compatibility maintenance. - MCP allows clients to discover available tools and schemas at runtime. - The same server can support many agents without custom integrations. - Runtime discovery helps clients adapt to evolving tool contracts and reduces hardcoded assumptions. ## Architecture - The remote MCP server sits in front of the Microsoft Learn knowledge service. - It uses the official C# MCP SDK and runs on Azure App Service. - Clients communicate through Streamable HTTP Transport. - The server uses the same content vector store as Ask Learn, providing shared: - Freshness guarantees. - Relevance ranking. - Index coverage. - Ask Learn delivers retrieval directly to users, while Learn MCP Server exposes that capability through a protocol usable by external agents. ## Designing Tools Around Agent Workflows - Internal retrieval APIs expose many low-level options, such as `topK`, index selection, thresholds, filters, and search modes. - Learn MCP Server hides that complexity behind intuitive search-and-fetch operations. - Tool contracts should reflect how agents work rather than mirror backend APIs. - Keeping retrieval details internal prevents implementation choices from leaking into the agent-facing interface. ## Operating a Remote MCP Service - A public MCP server has distributed-systems concerns despite using JSON-RPC: - Cross-region deployment. - Dynamic scaling. - CORS. - Session affinity. - Statelessness. - Data protection. - Operational design and SDK collaboration are as important as implementing the tools themselves. ## Tool Descriptions Shape Agent Behavior - Tool and parameter descriptions act as instructions for language models. - Small wording changes can significantly affect whether agents select a tool and how successfully they use it. - Microsoft created automated evaluation tooling to test descriptions against observed agent behavior and success metrics. - Updated descriptions can be delivered when clients refresh their MCP sessions. ## Combining Search and Fetch - Search and fetch are more effective together than independently. - A typical workflow is: - Search for the most relevant Learn article or section. - Fetch the full Markdown page for additional context. - Use that content to produce a better-grounded answer with stronger citations. - Explicitly describing this follow-up pattern improved downstream results. ## Handling Hardcoded Clients - Some MCP clients treat discovered tools like fixed APIs and hardcode schemas. - Renaming the `question` parameter to `query` caused 2–5% of requests to fail. - Supporting both names during a deprecation period reduced disruption. - Public MCP services must evolve defensively, even though the protocol supports dynamic discovery. - Tools such as MCP Interviewer can help identify schema and behavioral problems before deployment. ## Using Data to Guide Improvements - Usage data showed that most requests involve: - Coding tasks. - Explanations. - Troubleshooting. - The team prioritized retrieval and description changes around these intents. - Documentation-level agent instructions also encourage use of Learn tools when Microsoft technologies are involved. Microsoft Learn MCP Server replaces the manual process of searching, opening, and copying documentation into a development environment. The practical recommendation is to connect compatible agents to the server so they can retrieve official Learn content directly, while MCP tool authors should design simple contracts, measure real agent behavior, and preserve compatibility as their services evolve.

Read original(opens in new tab)

Vector DbAI AgentsModel Context ProtocolGithub Copilot+4

aws·Dec 2, 2025Original article

Amazon OpenSearch Service improves vector database performance and cost with GPU acceleration and auto-optimization (opens in new tab)

Amazon OpenSearch Service has introduced serverless GPU acceleration and auto-optimization features designed to enhance the performance and cost-efficiency of large-scale vector databases. These updates allow users to build vector indexes up to ten times faster at a quarter of the traditional indexing cost, enabling the creation of billion-scale databases in under an hour. By automating complex tuning processes, OpenSearch Service simplifies the deployment of generative AI and high-speed search applications. ### GPU Acceleration for Rapid Indexing The new serverless GPU acceleration streamlines the creation of vector data structures by offloading intensive workloads to specialized hardware. * **Performance Gains:** Indexing speed is increased by 10x compared to non-GPU configurations, significantly reducing the time-to-market for data-heavy applications. * **Cost Efficiency:** Indexing costs are reduced to approximately 25% of standard costs, and users only pay for active processing through OpenSearch Compute Units (OCU) rather than idle instance time. * **Serverless Management:** There is no need to provision or manage GPU instances manually; OpenSearch Service automatically detects acceleration opportunities and isolates workloads within the user's Amazon VPC. * **Operational Scope:** Acceleration is automatically applied to both initial indexing and subsequent force-merge operations. ### Automated Vector Index Optimization Auto-optimization removes the requirement for deep vector expertise by automatically balancing competing performance metrics. * **Simplified Tuning:** The system replaces manual index tuning—which can traditionally take weeks—with automated configurations. * **Resource Balancing:** The tool finds the optimal trade-off between search latency, search quality (recall rates), and memory requirements. * **Improved Accuracy:** Users can achieve higher recall rates and better cost savings compared to using default, unoptimized index configurations. ### Configuration and Integration These features can be integrated into new or existing OpenSearch Service domains and Serverless collections through the AWS Console or CLI. * **CLI Activation:** Users can enable acceleration on existing domains using the `update-domain-config` command with the `--aiml-options` flag set to enable `ServerlessVectorAcceleration`. * **Index Settings:** To leverage GPU processing, users must create a vector index with specific settings, notably setting `index.knn.remote_index_build.enabled` to `true`. * **Supported Workloads:** The service supports standard OpenSearch operations, including the Bulk API for adding vector data and text embeddings. For organizations managing large-scale vector workloads for RAG (Retrieval-Augmented Generation) or semantic search, enabling GPU acceleration is a highly recommended step to reduce operational overhead. Developers should transition existing indexes to include the `remote_index_build` setting to take immediate advantage of the improved speed and reduced OCU pricing.

Vector DbAIGenerative AIAWS+4

aws·Dec 2, 2025Original article

Amazon S3 Vectors now generally available with increased scale and performance (opens in new tab)

Amazon S3 Vectors has reached general availability, establishing the first cloud object storage service with native support for storing and querying vector data. This serverless solution allows organizations to reduce total ownership costs by up to 90% compared to specialized vector database solutions while providing the performance required for production-grade AI applications. By integrating vector capabilities directly into S3, AWS enables a simplified architecture for retrieval-augmented generation (RAG), semantic search, and multi-agent workflows. ### Massive Scale and Index Consolidation The move to general availability introduces a significant increase in data capacity, allowing users to manage massive datasets without complex infrastructure workarounds. * **Increased Index Limits:** Each index can now store and search across up to 2 billion vectors, representing a 40x increase from the 50 million limit during the preview phase. * **Bucket Capacity:** A single vector bucket can now scale to house up to 20 trillion vectors. * **Simplified Architecture:** The increased scale per index removes the need for developers to shard data across multiple indexes or implement custom query federation logic. ### Performance and Latency Optimizations The service has been tuned to meet the low-latency requirements of interactive applications like conversational AI and real-time inference. * **Query Response Times:** Frequent queries now achieve latencies of approximately 100ms or less, while infrequent queries consistently return results in under one second. * **Enhanced Retrieval:** Users can now retrieve up to 100 search results per query (increased from 30), providing broader context for RAG applications. * **Write Throughput:** The system supports up to 1,000 PUT transactions per second for streaming single-vector updates, ensuring new data is immediately searchable. ### Serverless Efficiency and Ecosystem Integration S3 Vectors functions as a fully serverless offering, eliminating the need to provision or manage underlying instances while paying only for active storage and queries. * **Amazon Bedrock Integration:** It is now generally available as a vector storage engine for Bedrock Knowledge Bases, facilitating the building of RAG applications. * **OpenSearch Support:** Integration with Amazon OpenSearch allows users to utilize S3 Vectors for storage while leveraging OpenSearch for advanced analytics and search features. * **Expanded Footprint:** The service is now available in 14 AWS Regions, up from five during the preview period. With its massive scale and 90% cost reduction, S3 Vectors is a primary candidate for organizations looking to move AI prototypes into production. Developers should consider migrating high-volume vector workloads to S3 Vectors to benefit from the serverless operational model and the native integration with the broader AWS AI stack.

Vector DbAIAmazon BedrockRAG+4

dropbox·Oct 23, 2025·3 min readCurated summary

With Mobius Labs' Aana models, we're bringing deeper multimodal understanding to Dropbox Dash

Dropbox is integrating Mobius Labs’ Aana multimodal models into Dropbox Dash to improve how it understands text, images, audio, and video together. Aana is designed for efficient, large-scale processing, enabling Dash to interpret scenes, actions, speech, and relationships across media rather than relying on isolated metadata. The goal is to make rich media searchable and support future AI agents that can analyze content and act on it. ## Dropbox Dash’s Multimodal Goal - Dash combines AI assistance and search to understand a team’s work, context, and tools. - Its multimodal capabilities are intended to cover formats such as: - Text - Photos - Videos - Audio - This is especially valuable for creative, technical, media, and marketing teams whose work is distributed across many applications and content repositories. ## Why Multimedia Understanding Is Difficult - A video may require analysis of: - Scene changes - Speaker shifts - On-screen text - Objects and actions - Audio cues and dialogue - Images require systems to understand people, locations, events, and visual context. - Each modality has different timelines and semantic boundaries; transcripts, shots, visuals, and audio do not automatically align. - Effective understanding requires connecting modalities—for example, linking what someone says to the diagram they are showing. - Processing this information across exabytes of content would be prohibitively expensive without highly efficient infrastructure. ## How Aana Combines Models and Context - Aana analyzes images, audio, video, and related text as a connected system instead of separate data streams. - It combines fine-tuned, open-source foundation models for: - Speech, including optimized Whisper-based models such as `faster-whisper-large-v3-turbo` - Vision - Language - Transformer and mixture-of-experts architectures support fast inference on standard GPUs. - Aana tracks how scenes evolve over time, including: - Object movement - Actions - Changing layouts - Cross-modal events - Insights are stored in a shared vector space, enabling searches such as “the part where the presenter explains the API flow” rather than requiring users to scrub through a video manually. ## Efficiency at Dropbox Scale - Aana uses low-bit 8-bit and 4-bit inference through its HQQ system to reduce memory and compute requirements. - Gemlite provides custom GPU kernels to accelerate matrix multiplication and attention operations. - The Aana SDK coordinates models, batching, GPU utilization, and production pipelines. - Teams can configure and deploy different combinations of models while experimenting with new workflows. - These optimizations are intended to make analysis of exabytes of media possible with a much smaller compute footprint than conventional approaches. ## Future Applications in Dash - Aana could help users find specific visual elements across large creative archives. - It could summarize years of client meetings into searchable highlights. - Its capabilities may support agentic workflows that: - Analyze multimedia - Surface relevant insights automatically - Generate ideas - Take actions for teams Dropbox’s integration of Aana is intended to make Dash a more context-aware search and AI assistant for rich media. The practical outcome is less time spent organizing and manually reviewing content, and more time spent creating and acting on information.

Read original(opens in new tab)

Vector DbMultimodal AITransformerAgentic Workflows+4

line·Jul 23, 2025Original article

Milvus: Building a Large-Scale (opens in new tab)

LINE VOOM transitioned its recommendation system from a batch-based offline process to a real-time infrastructure to solve critical content freshness issues. By adopting Milvus, an open-source vector database, the team enabled the immediate indexing and searching of new video content as soon as it is uploaded. This implementation ensures that time-sensitive posts are recommended to users without the previous 24-hour delay, significantly enhancing user engagement. ### Limitations of the Legacy Recommendation System * The original system relied on daily offline batch processing for embedding generation and similarity searches. * New content, such as holiday greetings or trending sports clips, suffered from a "lack of immediacy," often taking up to a full day to appear in user feeds. * To improve user experience, the team needed to shift from offline candidate pools to an online system capable of real-time Approximate Nearest Neighbor (ANN) searches. ### Selecting Milvus as the Vector Database * The team evaluated Milvus and Qdrant based on performance, open-source status, and on-premise compatibility. * Milvus was selected due to its superior performance, handling 2,406 requests per second compared to Qdrant's 326, with lower query latency (1ms vs 4ms). * Key architectural advantages of Milvus included the separation of storage and computing, support for both stream and batch inserts, and a diverse range of supported in-memory index types. ### Reliability Verification via Chaos Testing * Given the complexity of Milvus clusters, the team performed chaos testing by intentionally injecting failures like pod kills and scaling events. * Tests revealed critical vulnerabilities: killing the `Querycoord` led to collection release and search failure, while losing the `Etcd` quorum caused total metadata loss. * These findings highlighted the need for robust high-availability (HA) configurations to prevent service interruptions during component failures. ### High Availability (HA) Implementation Strategies * **Collection-Level HA:** To prevent search failures during coordinator issues, the team implemented a dual-writing system where embeddings are recorded in two separate collections simultaneously. * **Alias Switching:** Client applications use an "alias" to reference collections; if the primary collection becomes unavailable, the system instantly switches the alias to the backup collection to minimize downtime. * **Coordinator-Level HA:** To eliminate single points of failure, coordinators (such as `Indexcoord`) were configured in an Active-Standby mode, ensuring a backup is always ready to take over management tasks. To successfully deploy a large-scale real-time recommendation engine, it is critical to select a vector database that decouples storage from compute and to implement multi-layered high-availability strategies, such as dual-collection writing and active-standby coordinators, to ensure production stability.

Vector DbHigh AvailabilityEmbeddingChaos Testing+3

line·May 23, 2025Original article

Implementing a RAG-based (opens in new tab)

To address the operational burden of handling repetitive user inquiries for the AWX automation platform, LY Corporation developed a support bot utilizing Retrieval-Augmented Generation (RAG). By combining internal documentation with historical Slack thread data, the system provides automated, context-aware answers that significantly reduce manual SRE intervention. This approach enhances service reliability by ensuring users receive immediate assistance while allowing engineers to focus on high-priority development tasks. ### Technical Infrastructure and Stack * **Slack Integration**: The bot is built using the **Bolt for Python** framework to handle real-time interactions within the company’s communication channels. * **LLM Orchestration**: **LangChain** is used to manage the RAG pipeline; the developers suggest transitioning to LangGraph for teams requiring more complex multi-agent workflows. * **Embedding Model**: The **paraphrase-multilingual-mpnet-base-v2** (SBERT) model was selected to support multi-language inquiries from LY Corporation’s global workforce. * **Vector Database**: **OpenSearch** serves as the vector store, chosen for its availability as an internal PaaS and its efficiency in handling high-dimensional data. * **Large Language Model**: The system utilizes **OpenAI (ChatGPT) Enterprise**, which ensures business data privacy by preventing the model from training on internal inputs. ### Enhancing LLM Accuracy through RAG and Vector Search * **Overcoming LLM Limits**: Traditional LLMs suffer from "hallucinations," lack of up-to-date info, and opaque sourcing; RAG fixes this by providing the model with specific, trusted context during the prompt phase. * **Embedding and Vectorization**: Textual data from wikis and chats are converted into high-dimensional vectors, where semantically similar phrases (e.g., "Buy" and "Purchase") are stored in close proximity. * **k-NN Retrieval**: When a user asks a question, the bot uses **k-Nearest Neighbors (k-NN)** algorithms to retrieve the top *k* most relevant snippets of information from the vector database. * **Contextual Generation**: Rather than relying on its internal training data, the LLM generates a response based specifically on the retrieved snippets, leading to higher accuracy and domain-specific relevance. ### AWX Support Bot Workflow and Data Sources * **Multi-Source Indexing**: The bot references two main data streams: the official internal AWX guide wiki and historical Slack inquiry threads where previous solutions were discussed. * **Automated First Response**: The workflow begins when a user submits a query via a Slack workflow; the bot immediately processes the request and provides an initial AI-generated answer. * **Human-in-the-Loop Validation**: After receiving an answer, users can click "Issue Resolved" to close the ticket or "Call AWX Admin" if the AI's response was insufficient. * **Efficiency Gains**: This tiered approach filters out "RTFM" (Read The F***ing Manual) style questions, ensuring that human administrators only spend time on unique or complex technical issues. Implementing a RAG-based support bot is a highly effective strategy for SRE teams looking to scale their internal support without increasing headcount. For the best results, organizations should focus on maintaining clean internal documentation and selecting embedding models that reflect the linguistic diversity of their specific workforce.

Vector DbAIPythonRAG+5

figma·Oct 14, 2024·2 min readCurated summary

The Infrastructure Behind AI Search in Figma | Figma Blog

Figma’s AI search lets users find designs and components through text, screenshots, or layer selections. It relies on multimodal embeddings, vector nearest-neighbor search, and large-scale indexing of frames and components. The main infrastructure challenge was generating and indexing billions of embeddings efficiently while controlling costs. ## AI-Powered Search Flows - **Search for designs** indexes frames across users’ files, including unlabeled frames buried in complex files. - Users can search designs: - Lexically with a text description - Visually with a screenshot - By selecting similar Figma layers - **Search for components** enhances the Assets panel with semantic matching. - A component representing 😀 can be found with terms such as “smiley,” “happy,” “face,” or “grin.” - Designers no longer need to manually add every possible keyword to component descriptions. - Components can also be found using visual queries. ## Multimodal Embeddings - An embedding model converts text or images into numerical vectors that represent their meaning. - Figma uses the open-source **CLIP** model, which places text and images in the same embedding space. - The embedding for the word “cat” should be numerically close to an embedding generated from an image of a cat. - Figma’s models were not trained on private customer files or data. - Fine-tuning used interface images from public, free Community files. - Search works by: - Generating embeddings for indexed content - Creating an embedding for the user’s query - Finding indexed vectors that are nearest to the query vector - Figma tested embeddings based on textual representations such as JSON, but image-based embeddings produced better results and supported the same workflow as screenshot search. - Layer selections are converted into screenshots before being passed to the embedding model. ## Populating the Vector Search Index - Each searchable item requires: - A thumbnail or rendered screenshot - An embedding - Metadata stored in the search index - Figma uses DynamoDB for metadata and embeddings because the workload primarily requires high-throughput key-value reads and writes. - Identifying searchable frames is difficult because unpublished frames are not directly enumerable. - Figma runs a headless, server-side version of its C++ editor in asynchronous jobs to discover frames within files. - These jobs use server-side sandboxing techniques to safely run the editor. Figma’s approach combines CLIP-based multimodal representations, server-side rendering, asynchronous processing, and scalable vector storage to make visual and semantic search practical across large design systems.

Read original(opens in new tab)

Vector DbMultimodal AIC++Embeddings+2