325 articles
325 ARTICLES
A three-person agency received a $14,000 AWS bill in one day after attackers extracted static access keys and burned Claude invocations on Bedrock. Combined with May’s DN42 incident, where an autonomous agent provisioned $6,531 of oversized infrastructure in 24 hours, practitioners warn that cloud billing lags roughly a day behind agent-speed spend. By Steef-Jan Wiggers
Owen Flowers and Thalha Jubair, the hackers behind the 2024 TfL cyber attack, have been sentenced to five-year prison terms at Woolwich Crown Court
While support ended in October 2025, community-driven insights from Lansweeper has found that smaller businesses are still using Windows 10
Microsoft promised “infinite” cloud scalability, but signs of capacity strain and regional rollbacks suggest it may be overstretched, forcing customers to rethink vendor lock-in
To fix grid crisis caused by mismanagement under her previous administrations, Danish prime minister opens third term in office with laws against datacentres
The CNCF Technical Oversight Committee (TOC) has voted to accept HAMi as a CNCF incubating project. About HAMi Modern AI infrastructure teams run into the same problem over and over: expensive GPUs often sit fragmented and…
Deploying the Gemini Enterprise app across an organization marks a transformative leap forward in workforce productivity, providing employees with an amazing, high-performance suite of agentic AI tools, search-grounded assistants, and specialized solutions like NotebookLM. As adoption grows to a large scale, it can introduce a critical administrative scale challenge: how to audit, govern, and extract insights from a massive volume of telemetry without getting bogged down in manual overhead. To help administrators succeed, Google Cloud provides comprehensive, out-of-the-box analytics via pre-computed dashboards to track day-to-day adoption, user engagement, and active user metrics. While this provides a product-centric lens to look at Gemini Enterprise app’s usage, to understand the impact of agentic AI, administrators might need a more nuanced, organization-centric perspective tailored to their own internal context. This is where using Google BigQuery becomes a crucial tool in the administrator’s arsenal to run deep-dive forensics across their organization to analyze and govern the adoption of agentic AI. Why Gemini Enterprise app + BigQuery is a game-changer Augmenting the Gemini Enterprise app with BigQuery through log sinks allows a lean administrative team to analyze and govern a large-scale deployment. Specifically, it empowers IT, Data, and Security teams to: Profile nuanced adoption and behaviors: Segment usage patterns by department to see which teams are building custom agents, track NotebookLM utilization, and calculate agent-to-employee ratios. Quantify organizational value: Combine conversational logs with HR or line-of-business datasets to calculate actual employee hours saved, trace value creation, and build executive Looker dashboards. Execute precision compliance audits: Audit grounding queries across Google Drive folders and enterprise directories to prevent data leaks and protect corporate IP. Investigate safety alerts instantly: Query historical logs when security filters flag a prompt, identifying the exact text that triggered a Model Armor block to resolve compliance alerts. To support these use cases, the telemetry is partitioned into five distinct log tables in BigQuery, capturing unique data fields: BigQuery Destination Table Telemetry Captured Gen AI User Messages discoveryengine_googleapis_com_g en_ai_user_message Verbatim prompt inputs typed by users Gen AI Choices discoveryengine_googleapis_com_g en_ai_choice Verbatim model responses, finish reasons, and LLM reasoning steps User Activity Telemetry discoveryengine_googleapis_com_g emini_enterprise_user_activity Corporate identity (IAM emails) and grounding file access paths Cloud Audit Activity cloudaudit_googleapis_com_activity Control plane configuration changes and administrative user logs Cloud Audit Data Access cloudaudit_googleapis_com_data_ac cess High-volume data plane interactions and search queries Aggregate OOB Metrics (Batch Export Table) Pre-aggregated seats claimed, seat purchases, and engagement metrics from the past 30 days. To be pulled asynchronously via custom daily batch runs of the analytics:exportMetrics API to build high-level adoption and cost dashboards. Ingestion pipeline and architecture To implement scale-ready observability, administrators establish an automated telemetry pipeline. Moving your Gemini Enterprise data to BigQuery does not require complex custom software development; instead, it leverages a continuous Cloud Logging Log Router Sink for conversational logs and an asynchronous batch export API for high-level aggregate seat metrics. The diagram below illustrates the ingestion pipeline and how telemetry is mapped to BigQuery: Here is your blueprint for connecting Gemini Enterprise to BigQuery to build the ultimate analytics and governance foundation for your organization. Routing pipelines: Continuous logging and audit sinks To capture your telemetry, establish log sinks within Cloud Logging to intercept and route runtime events to BigQuery: The streaming pipeline (detailed logs): Streams row-by-row conversational data (user prompts, model choices, and grounding events). Ensure prompt and response logging is enabled in your Gemini Enterprise Admin Console (see Set Up Usage & Audit Logs). Inclusion Filter (replace [PROJECT_ID] with your Google Cloud Project ID): code_block <ListValue: [StructValue([(‘code’, ’logName=“projects/[PROJECT_ID]/logs/discoveryengine.googleapis.com%2Fgemini_enterprise_user_activity” OR\r\nlogName=“projects/[PROJECT_ID]/logs/discoveryengine.googleapis.com%2Fgen_ai.user.message” OR\r\nlogName=“projects/[PROJECT_ID]/logs/discoveryengine.googleapis.com%2Fgen_ai.choice”’), (’language’, ‘’), (‘caption’, <wagtail.rich_text.RichText object at 0x7fbfc3da1790>)])]> The governance pipeline (audit logs): Captures administrative actions (Admin Activity) and data plane operations (Data Access, such as grounding data connector lookups). Inclusion Filter (replace [PROJECT_ID] with your Google Cloud Project ID): code_block <ListValue: [StructValue([(‘code’, ’logName:“projects/[PROJECT_ID]/logs/cloudaudit.googleapis.com” AND \r\nprotoPayload.serviceName=“discoveryengine.googleapis.com”’), (’language’, ‘’), (‘caption’, <wagtail.rich_text.RichText object at 0x7fbfc3da1a90>)])]> Admin Activity Logs: Always enabled by default; tracks resource changes (e.g., custom agent creation, updates, deletions). Data Access Logs: Off by default; must be enabled in GCP IAM settings for the Discovery Engine API to log user-level data read/write interactions during chats. Unlock advanced intelligence in BigQuery Transform raw telemetry into insights BigQuery provides AI-powered analysis tools that make understanding and navigating telemetry effortless. By leveraging Gemini in BigQuery, administrators can translate raw log streams into visual insights and clear documentation without manual guesswork. No-Code Conversational Analytics (BigQuery CA) Querying nested JSON schemas is made simple with Conversational Analytics in BigQuery (BQ CA). BQ CA acts as an intelligent agent within BigQuery Studio, automatically generating and executing SQL grounded in your schema, business metadata, and verified queries/UDFs to ensure metrics consistency. It also surfaces its “thinking process” alongside the generated code to build administrative trust. For example, as shown in the screenshot below, asking “Compare the usage of notebooklm, deep research and custom agents using oob_metrics?” generates the correct SQL, runs the query and outputs the result in seconds: As shown in the screenshot below, BQ CA goes beyond traditional querying and standard SQL generation by allowing users to execute sophisticated AI and machine learning tasks directly within the console. Administrators can leverage these native capabilities to run advanced analysis, such as classification of user prompt sentiment or forecasting future adoption trends, streamlining the governance process. Auto-generated schema documentation and insights Understanding telemetry fields like useriamprincipal, finish_reason, or groundedContent is crucial for extracting the right insights. BigQuery simplifies this through automated schema documentation and AI-powered context: Automated profiling and metadata: By pairing Knowledge Catalog Data Profiling with Gemini, you can evaluate unique value counts, null rates, and data distributions in raw tables. With a single click, Data Insights generates descriptive metadata for both tables and individual nested columns. Unified data insights: Gemini leverages this rich context to surface insights across your entire data estate. It automatically recommends queries to find anomalies or safety failures within a single table (like gen_ai_user_message). At the dataset level (Preview), it generates an interactive relationship graph to map cross-table join paths and suggests queries that combine data—like user activity and model outputs—to calculate task complexity. Seamless agent integration and glossaries: Table and data insights integrate directly into the BigQuery Conversational Analytics (BQ CA) agent UI, giving agents immediate access to enriched metadata and few-shot examples. To ensure agents accurately interpret domain-specific prompts, BQ CA also supports business glossaries. You can define custom terms directly for your agents or import existing glossaries from Knowledge Catalog to establish a standardized vocabulary. Administrators can then leverage the profiling, enriched metadata and insights to navigate logged fields, understand the telemetry structure, and catalog data for compliance audits. As shown in the screenshots below, the output of Gemini-powered auto generation of schemas, descriptions and linkages makes it easy to make sense of the complex relationships and telemetry data output by agentic interactions on the Gemini Enterprise app. Visualizing with Data Studio dashboards For executive stakeholders, raw log tables can be transformed into interactive, high-impact business intelligence dashboards. By connecting Data Studio directly to BigQuery, you can build dashboards that monitor: User adoption and seat ROI: Segment usage trends by department, highlighting the ratio of custom agents built relative to employee headcount. Data grounding traffic: Map which enterprise connectors—such as SharePoint, Google Drive, or Gmail—experience the highest utilization. Content safety and violations: Track Model Armor sanitization blocks and sentiment feedback loops over time to maintain safety standards. Share BQ Conversational Analytics agent: Share the BQ CA agents you built via Data Studio to give business users the ability to ask more questions of the data. Empower your organization with the Gemini Enterprise app and your administrators with BigQuery Deploy the Gemini Enterprise App: Bring the best of Google AI to every employee. Enable Prompt & Response Logging: Turn on prompt and response logging in the Admin Console to begin recording user activity telemetry. Configure Log Router Sinks: Establish sinks to stream telemetry into BigQuery. Track Metrics & Export Analytics: Access pre-computed, out-of-the-box dashboards on the console and export historical aggregate statistics. Extract Table-Level & Dataset-Level Insights: Explore unfamiliar log tables and discover relationship join paths automatically. Query with Conversational Analytics: Build data reasoning agents and leverage natural language querying inside BigQuery Studio. Visualize with Data Studio: Connect Data Studio to BigQuery to build executive-level dashboards & give access to BQCA agents to business users. Consult a Google Cloud Customer Engineer for the most cost-effective and secure configuration for the analytics setup described above. The authors would like to acknowledge and thank the Google Forge team, especially Vicky Falconer, Dharini Chandrashekhar and Adhaar Gupta, for contributing to the core work that led to this article.
AlloyDB powers enterprise-grade search for some of the largest organizations, providing robust hybrid search capabilities that combine text, vector, and keyword searches into a simple ranked SQL query. And with our recent launch of RUM index support, AlloyDB customers now have even more powerful full-text search capabilities at their fingertips. However, database developers often face limitations when indexing continuous text in logographical languages like Chinese, Japanese, and Korean, where traditional whitespace-based tokenization fails. Gemini’s multilingual capabilities enable you to intelligently parse text in these languages to implement intelligent word segmentation and stop-word removal, but orchestrating row-wise API calls on massive datasets is slow and fragile. Now you can integrate the world knowledge of Gemini models natively into your database using AlloyDB AI Functions, enabling highly accurate full-text search for logographical languages without the administrative overhead of complex ETL pipelines. Continuous text and logographical languages To understand why this native integration is such a significant advancement, we must first examine the underlying mechanics of text search and why traditional indexing methods fail when processing continuous text. To build an effective full-text search index in PostgreSQL, the engine must parse text into search tokens (lexemes) using the to_tsvector function. By default, standard text search configurations like simple or english assume that words are separated by whitespace. The database engine extracts search terms by splitting the input string at these spaces. However, Chinese and other logographical languages do not use spaces between words. Words are written continuously, with punctuation serving as the only boundaries. Because of this, standard PostgreSQL parsers fail to extract individual keywords. Instead, they treat entire sentences or long clauses as a single, continuous lexeme. For example, consider this input string: “你们研究所有十个图书馆” (Your research institute has ten libraries) Without spaces, passing this to to_tsvector(‘simple’, …) produces a single, massive lexeme: ‘你们研究所有十个图书馆’ If you search for “研究所” (research institute) or “图书馆” (library), the query fails to return a match. The keywords are trapped inside the larger string, forcing you to search for the exact, long-form sentence to get a result. Traditional workarounds and their limits You might try to resolve this using traditional tools and pipelines, each of which introduces significant operational friction or accuracy limits: Third-party database extensions: Extensions like zhparser or pg_jieba add Chinese tokenization to PostgreSQL. However, these are often not supported in fully-managed database environments. They also rely on static dictionaries, which frequently fail to parse modern jargon, brand names, or context-dependent terms correctly. External preprocessing pipelines: Exporting text to an external application (such as a Python microservice running jieba or spaCy) to insert spaces before saving it to the database. This pattern introduces substantial ETL complexity, network latency, and data exposure risks by moving your data out of the database tier. Inadequacy of rule-based and dictionary-driven segmentation: Traditional tokenizers rely on static dictionaries and hand-coded syntactic rules to split text. They often struggle to resolve semantic ambiguity, where the exact same sequence of characters must be segmented differently depending on the context. To perform accurate segmentation, you need the world knowledge and contextual intelligence of a large language model like Gemini. In-database pre-processing with Gemini AlloyDB AI bypasses these workarounds — and their limits — by introducing native, in-database AI Functions like ai.generate(). This allows you to call Gemini directly from SQL, keeping your data and intelligence in one place. This approach provides three core advantages: No data movement: All text preprocessing and segmentation happen directly within the database engine. This minimizes network latency and keeps your data protected within your database boundaries. In-database intelligence: You do not need to build, deploy, or maintain external microservices or orchestration frameworks. The database engine coordinates the model calls natively. Stored procedure-based batching: By using a PL/pgSQL stored procedure with array aggregation, you can process rows in parallel batches, unpack the results safely using GENERATE_SERIES, and commit each batch immediately. This prevents database memory exhaustion, bypasses row lock contention, and supports stable, performant execution even when handling massive tables. Implementing semantic word segmentation To implement this solution, we will create a database table where the raw content, the segmented text, the search vector, and the vector embeddings are stored together. code_block <ListValue: [StructValue([(‘code’, “CREATE TABLE documents (\r\n id SERIAL PRIMARY KEY,\r\n title TEXT NOT NULL,\r\n original_content TEXT NOT NULL,\r\n content_segmented TEXT,\r\n search_vector tsvector GENERATED ALWAYS AS (to_tsvector(’english’, content_segmented)) STORED,\r\n embedding vector(3072) GENERATED ALWAYS AS (embedding(‘gemini-embedding-001’, content_segmented)) STORED\r\n);”), (’language’, ‘’), (‘caption’, <wagtail.rich_text.RichText object at 0x7fbfc3172f10>)])]> By defining search_vector and embedding as generated columns, AlloyDB automatically updates both the full-text search index and the vector embeddings whenever the content_segmented column is updated. This reduces your application-side logic to a single update statement. Step 1: Document batch segmentation If you consult the AlloyDB AI documentation, it recommends using cursor-based processing when dealing with large datasets (10,000 to millions of rows) to avoid memory bottlenecks. However, the documentation’s cursor examples focus on append-only operations — streaming text into a new, empty table using INSERT. Our use case requires an in-place UPDATE on our live documents table. Implementing this with a raw cursor loop in a standard anonymous block (DO $$) introduces three important production hazards: excessive row locking that freezes live applications, a rollback risk if a network blip occurs, and alignment risks where parallel cursors fall out of step. To mitigate these challenges and accelerate performance, we use a stored procedure configured with high-throughput array-based batching: code_block <ListValue: [StructValue([(‘code’, “CREATE OR REPLACE PROCEDURE segment_all_documents(p_batch_size INT DEFAULT 100)\r\nLANGUAGE plpgsql AS $$\r\nDECLARE\r\n v_processed_count INT;\r\nBEGIN\r\n LOOP\r\n – 1. Grab a single isolated batch, aggregate into arrays, and call Gemini.\r\n – We explicitly ORDER BY id during aggregation to guarantee the arrays match perfectly.\r\n WITH batch_raw AS (\r\n SELECT id, original_content\r\n FROM documents\r\n WHERE content_segmented IS NULL OR content_segmented = ‘’\r\n ORDER BY id\r\n LIMIT p_batch_size\r\n ),\r\n batch_processed AS (\r\n SELECT \r\n ARRAY_AGG(id ORDER BY id) AS target_ids,\r\n ai.generate(\r\n prompts => ARRAY_AGG(‘Perform Chinese word segmentation (分词) on the provided text to prepare it for full-text search indexing.\r\nRules:\r\n- Insert a single space between every atomic, meaningful word.\r\n- Separate all punctuation marks (both full-width and half-width) with spaces.\r\n- Preserve the original structure, line breaks, and non-Chinese characters (e.g., English words, numbers).\r\n- Output ONLY the processed text. Do not include any greetings, explanations, or formatting wrappers like markdown code blocks unless they exist in the original text.\r\nText to process: ’ || original_content ORDER BY id),\r\n model_id => ‘gemini-2.5-flash-lite’\r\n ) AS ai_outputs\r\n FROM batch_raw\r\n ),\r\n – 2. Use GENERATE_SERIES to unpack the paired array indexes safely\r\n unpivoted_results AS (\r\n SELECT \r\n b.target_ids[i] AS doc_id,\r\n b.ai_outputs[i] AS segmented_text\r\n FROM batch_processed b,\r\n GENERATE_SERIES(1, COALESCE(ARRAY_LENGTH(b.target_ids, 1), 0)) i\r\n )\r\n – 3. Execute the batch update for this chunk\r\n UPDATE documents d\r\n SET content_segmented = r.segmented_text\r\n FROM unpivoted_results r\r\n WHERE d.id = r.doc_id;\r\n\r\n – Check how many rows were updated in this pass\r\n GET DIAGNOSTICS v_processed_count = ROW_COUNT;\r\n\r\n – If the update affected 0 rows, it means the whole table is finished\r\n EXIT WHEN v_processed_count = 0;\r\n\r\n – 4. Commit immediately to save progress and release row locks!\r\n COMMIT;\r\n \r\n RAISE NOTICE ‘Successfully processed and committed a batch of % rows.’, v_processed_count;\r\n END LOOP;\r\nEND $$;”), (’language’, ‘’), (‘caption’, <wagtail.rich_text.RichText object at 0x7fbfc3172df0>)])]> To run this preprocessing pipeline across your entire table, simply call the stored procedure: code_block <ListValue: [StructValue([(‘code’, ‘CALL segment_all_documents(100);’), (’language’, ‘’), (‘caption’, <wagtail.rich_text.RichText object at 0x7fbfc31728b0>)])]> This stored procedure approach provides three benefits that directly solve your production challenges: Parallelized array aggregation (solving the sequential bottleneck): By aggregating the batch into arrays and calling ai.generate(prompts => …) with the array, AlloyDB batches the model requests and executes them in parallel. This is faster than processing rows one-by-one sequentially. Safe index-based unpacking (solving cursor desync): Using GENERATE_SERIES to unpack the array indexes maps the model output back to the correct document ID, reducing the risk of parallel streams falling out of step. Immediate commits and lock release (solving blocking and rollback risks): Committing the transaction at the end of each loop iteration (COMMIT;) is an essential optimization. It immediately saves progress to disk and releases row locks, preventing long-running transactions from freezing your live application and ensuring a network blip won’t roll back hours of work. Once this pipeline runs, our example sentence is stored in content_segmented as: “你们 研究所 有 十个 图书馆” Step 2: Choosing simple vs. english When defining your tsvector generated column, you must choose the appropriate PostgreSQL text search configuration. This choice depends on your dataset: When to use simple: If your database contains only Chinese text, the simple configuration is ideal. It converts text to lowercase but does not perform stemming or default stop-word removal. Since the model prompt already handles semantic segmentation and custom stop-word filtering, the simple configuration maps directly to the model’s optimized output without further modification. When to use english: In modern enterprise applications, Chinese documentation and user queries frequently contain embedded English terms (e.g., product codes, brand names, or technical terms). In these bilingual scenarios, the english configuration is superior. The English Porter stemmer leaves non-ASCII Chinese characters completely intact as exact lexemes, while automatically normalizing the English terms (e.g., stemming “running” to “run”) and filtering out generic English stop words (“the”, “and”). This achieves unified bilingual search capabilities without requiring separate columns or complex routing logic. Step 3: Query-time preprocessing Segmenting the document content is only half the battle. To match the indexed data, the incoming search queries must be pre-processed using the same Gemini-based segmentation logic. We can take this a step further to improve search precision. We can instruct the model to act as an intelligent stop-word filter, stripping away low-value grammatical noise that would otherwise clutter your search results: Grammatical particles (e.g., 的, 了) Pronouns (e.g., 你, 我们) Comparison words (e.g., 比, 最) Question words (e.g., 怎么, 为什么) For example, we can process a user query on the fly using a SQL query: code_block <ListValue: [StructValue([(‘code’, “SELECT ai.generate(\r\n ‘Perform Chinese word segmentation (分词) on the provided search query.\r\n Additionally, remove low-value grammatical noise such as particles (e.g., 的, 了), pronouns (e.g., 你, 我们), comparison words (e.g., 比, 最), and question words (e.g., 怎么, 为什么).\r\n Rules:\r\n - Insert a single space between every remaining meaningful word.\r\n - Output ONLY the processed keywords. Do not include greetings or explanations.\r\n Query to process: 你们研究所的图书馆在哪里？’\r\n);”), (’language’, ‘’), (‘caption’, <wagtail.rich_text.RichText object at 0x7fbfc1bd4e80>)])]> The model processes this query and returns the keyword string: “研究所 图书馆” Step 4: executing the search with RUM With your documents segmented and indexed, you can create a RUM index on your generated search_vector column. A RUM index is an index type that stores lexeme positions directly. This helps AlloyDB calculate search relevance and word distance directly within the index, avoiding the slow re-scan operations required by traditional GIN indexes. code_block <ListValue: [StructValue([(‘code’, ‘CREATE INDEX idx_docs_rum\r\nON documents\r\nUSING rum (search_vector rum_tsvector_ops);’), (’language’, ‘’), (‘caption’, <wagtail.rich_text.RichText object at 0x7fbfc1bd44f0>)])]> To run a search, you convert your preprocessed query string (“研究所 图书馆”) into a search query using plainto_tsquery and execute it against the RUM index. You can use the RUM distance operator (<=>) to sort the results by relevance: code_block <ListValue: [StructValue([(‘code’, “SELECT id, title, original_content,\r\n search_vector <=> plainto_tsquery(’english’, ‘研究所 & 图书馆’) AS distance\r\nFROM documents\r\nWHERE search_vector @@ plainto_tsquery(’english’, ‘研究所 & 图书馆’)\r\nORDER BY distance ASC;”), (’language’, ‘’), (‘caption’, <wagtail.rich_text.RichText object at 0x7fbfc1bd42b0>)])]> Because the RUM index calculates the distance score directly, this query executes with high efficiency, returning relevant matches in milliseconds. Extending to hybrid search While keyword-based text search is excellent for finding exact matches, it can miss relevant documents that use different terminology. To solve this, you can combine your segmented full-text search with semantic vector search using the multilingual gemini-embedding-001 model. This pattern, known as hybrid search, retrieves results that are both lexically and semantically relevant. AlloyDB makes it easy to run hybrid search. You can create a ScaNN index (Google’s vector index technology) on your embedding column and combine it with your RUM index. Creating the ScaNN index To accelerate your vector search, you create a ScaNN index on the embedding column: code_block <ListValue: [StructValue([(‘code’, ‘CREATE EXTENSION IF NOT EXISTS alloydb_scann;\r\n\r\nCREATE INDEX idx_docs_scann\r\nON documents\r\nUSING scann (embedding cosine);’), (’language’, ‘’), (‘caption’, <wagtail.rich_text.RichText object at 0x7fbfc1bd41f0>)])]> Running the hybrid search query To combine the results of your vector and text searches, you can use a SQL query that implements Reciprocal Rank Fusion (RRF). RRF is a rank-based algorithm that merges multiple search result lists into a single, unified list by assigning a score to each document based on its rank in the individual lists. The following query performs both searches in parallel using Common Table Expressions (CTEs), joins the results using a FULL OUTER JOIN, and calculates the final RRF score: code_block <ListValue: [StructValue([(‘code’, “WITH vector_search AS (\r\n SELECT id,\r\n RANK() OVER (ORDER BY embedding <=> ai.embedding(‘gemini-embedding-001’, ‘研究所 图书馆’)::vector) AS rank\r\n FROM documents\r\n ORDER BY embedding <=> ai.embedding(‘gemini-embedding-001’, ‘研究所 图书馆’)::vector\r\n LIMIT 10\r\n),\r\ntext_search AS (\r\n SELECT id,\r\n RANK() OVER (ORDER BY search_vector <=> plainto_tsquery(’english’, ‘研究所 & 图书馆’)) AS rank\r\n FROM documents\r\n WHERE search_vector @@ plainto_tsquery(’english’, ‘研究所 & 图书馆’)\r\n ORDER BY search_vector <=> plainto_tsquery(’english’, ‘研究所 & 图书馆’)\r\n LIMIT 10\r\n)\r\nSELECT\r\n COALESCE(vector_search.id, text_search.id) AS id,\r\n COALESCE(1.0 / (60 + vector_search.rank), 0.0) + COALESCE(1.0 / (60 + text_search.rank), 0.0) AS rrf_score\r\nFROM vector_search\r\nFULL OUTER JOIN text_search ON vector_search.id = text_search.id\r\nORDER BY rrf_score DESC\r\nLIMIT 5;”), (’language’, ‘’), (‘caption’, <wagtail.rich_text.RichText object at 0x7fbfc1bd4190>)])]> In this query: The vector_search CTE uses the ScaNN index to find the top 10 documents that are semantically closest to your query, using the gemini-embedding-001 model. The text_search CTE uses the RUM index to find the top 10 documents that match your segmented keywords, using the RUM distance operator for ranking. The final select statement joins these lists and calculates the RRF score using the standard constant of 60. The top 5 results are returned, providing a precise blend of exact keyword matches and semantic matches. Why AlloyDB AI is ideal for search By using AlloyDB AI to solve the challenges of multilingual and hybrid search, you build a robust, scalable, and cost-effective foundation for your enterprise AI applications. Native, in-database intelligence: By running model processing directly within AlloyDB AI, you avoid the cost, latency, and data exposure risks of moving transactional data to external AI services. Enterprise-grade search performance: Combining ScaNN vector search (built on Google’s search technology) and RUM full-text search in a single relational database delivers fast, accurate search outcomes without needing to maintain separate, complex search engines. High context-aware accuracy: Unlike static, rule-based dictionaries that struggle with modern terminology, Gemini’s world knowledge brings deep semantic understanding to word segmentation, providing high search precision. Operational simplicity: You get robust bilingual and hybrid search capabilities using standard SQL. This means you can build and scale AI applications using the database skills you already have, without learning new APIs or managing complex external pipelines. What’s next Giving your applications the ability to safely and efficiently interact with transactional data moves us away from fragmented data silos and toward an architecture where AI can reliably access enterprise truth. Ready to build? Discover AlloyDB with a 30-day free trial, and dive into the Getting started with hybrid search in AlloyDB Codelab to start creating intelligent search experiences in your applications today.
Editor’s note: Today we hear from IDC on the results of its 2026 AI in Networking Special Report Survey exploring the enterprises’ concerns about networking infrastructure to support the rise of agentic AI in their organizations. The survey was sponsored by Google Cloud. Enterprises are moving quickly on AI pilots, but the move from pilot to production remains uneven. While AI models remain important, IDC research indicates that the pilot-to-production bottleneck is primarily infrastructure-centric, with core networking concerns emerging as one of the leading drivers of AI project delays and abandonment. In IDC’s 2026 AI in Networking Special Report Survey: 32.6% of respondents cite security concerns: As AI workflows become more distributed and autonomous, enforcing consistent security and governance becomes more difficult. 26.8% of respondents cite challenges in automation: Manual operations and fragmented controls can slow deployment and make AI environments harder to scale. 24.7% of respondents cite staff time and talent restrictions: Limited skills and operational bandwidth can constrain an organization’s ability to move AI initiatives into production. Agentic AI specifically heightens these concerns by introducing more distributed and dynamic interactions across applications, services, APIs, tools, and data sources. In production environments, these interactions often span different agent frameworks, model providers, clouds, open-source tools, SaaS APIs, and internal applications, expanding both the operational scope and the security and governance surface area. Networking for operational control, security, and governance at scale Networking is the primary enabler of agentic interactions and plays a foundational role for intracloud and intercloud network- and services-layer connectivity, end-to-end security, and consistent governance. In agentic systems, networking increasingly extends into tighter service-centric controls that govern how distributed services identify one another, communicate, and exchange data securely. While AI workloads in general are increasing east-west traffic demands, agentic AI adds an additional layer of complexity by creating dynamic interactions that require tighter policy, visibility, and control closer to the application workflow. From an infrastructure perspective, networking is much more than just a connectivity function. It is part of the infrastructure platform control plane that applies policy-based controls, supports observability, and helps maintain consistent security and governance across an AI agent’s activity. This is significant because framework-level controls alone become insufficient in environments where agents and services span different runtimes, clouds, deployment models, and operating domains. That is why an infrastructure-level approach becomes key. It does not replace application frameworks or orchestration environments, but it provides broader and more consistent policy implementation across a complex architectural landscape. As agentic AI becomes more autonomous and distributed, organizations need these controls built in as part of the infrastructure to reduce fragmented observability, inconsistent policy application, and unmanaged shadow agent activities. From a cloud infrastructure standpoint, this is where cloud network services become strategically important. Balancing act: A platform vs. best-of-breed approach Agentic AI systems are inherently fragmented because of underlying distributed workflows. Enterprises are already navigating a rapidly evolving landscape of business requirements, open-source components, emerging protocol standards, and new architecture patterns. In this context, choices between best-of-breed point solutions and platform-based approaches should be strategic rather than ideological. Best-of-breed capabilities may be necessary to address specific technical requirements. But it is also true that point solutions introduced across a distributed agentic AI landscape can create inconsistent policies, operational complexity, and governance gaps. IDC research reflects this tension. In IDC’s 2026 AI in Networking Special Report Survey, organizations remained divided between platform and best-of-breed preferences for AI workloads; among respondents who favored platforms, the main reasons cited were stronger security (32.9%), reduced complexity (27.7%), and faster deployment (24.2%). In IDC’s view, a balance is important. Platforms can provide a consistent operational and policy foundation for AI deployments, but at the same time, they need to be modular and extensible to allow the inclusion of best-of-breed functionality as part of the platform toolset. The right platform for agentic AI should be open, flexible, and able to evolve. It should support integration with third-party and open-source tools, allow insertions of needed security and observability functions, and adapt without complete architectural rework. This is a period of technology disruption. Businesses must meet their AI objectives while carefully managing dynamic agentic AI systems. In this environment, networking not only remains a connectivity piece of the AI infrastructure but becomes foundational to how organizations establish operational control, apply policy consistently, and maintain end-to-end trust across agentic workflows. As agentic AI systems continue to evolve, the demands they place are unlikely to be addressed through best-of-breed point solutions alone. Operationalizing agentic AI at scale will require organizations to leverage the right networking approach, supported by infrastructure platforms that are open, flexible, and extensible, enabling a cohesive and adaptable security and governance framework. Message from the sponsor The autonomous and non-deterministic communications of agentic applications pose challenges for which the infrastructure and governance models of the cloud-native era are not prepared. In the agent-native era, an infrastructure-led approach is required to enable agentic applications at scale in production with effective governance and observability. An extensible platform based on open standards is critical in enabling the agentic journey today and through its maturity. Learn about the infrastructure imperatives and open standards that make a viable agentic infrastructure here.
When 121 million mobile devices establish persistent gRPC connections to your origin infrastructure within seconds of a live broadcast, the routing policy behind your DNS records matters far more than it does at normal traffic levels. The wrong policy can concentrate all your connections onto a single origin endpoint, turning a scaling success into an
Microsoft Azure Databricks delivers the first-party advantage of Databricks on Microsoft—and for customers, that advantage shows up as real, measurable value. It is the same Databricks platform your teams already know, co-engineered with Microsoft and delivered as a native Azure service, so it fits naturally into the Microsoft tools, identity, and governance your organization already runs. The post Azure Databricks delivers proven business value appeared first on Microsoft Azure Blog.
Stripe introduces a benchmark suite to evaluate whether AI agents can build real-world Stripe integrations across backend, frontend, and browser-based checkout workflows. The study examines end-to-end software engineering capability, focusing on execution, testing, and validation gaps in agentic systems under production-like constraints. By Leela Kumili