DataStax’s real-time data architecture ensures that agents have immediate access to relevant information.

How DataStax is Simplifying AI Agent Development

Nvidia and DataStax launch new AI tool that reduces enterprise data storage costs by 35x while enabling multilingual retrieval, transforming how companies like Wikimedia process and access massive datasets.

Nvidia and DataStax just made generative AI smarter and leaner - here’s how

Chet Kapoor talked Nvidia, regulation, and building out enterprise generative AI in the latest episode of Quartz AI Factor

AI regulation will slow innovation to speed it up: DataStax CEO

Reduces AI Development Time by 60%; Handles AI Workloads 19x Faster;Enterprises Can Create AI That Increases In Accuracy As Customers Engage

DataStax Announces DataStax AI Platform Built with NVIDIA AI

DataStax looks to improve enterprise AI production deployment with Nvidia, using Langflow as the center for building agentic AI workflows.

DataStax looks to help enterprises stuck in AI 'development hell', with a little help from Nvidia

DataStax CEO Chet Kapoor says current challenges in AI are a normal part of technological revolution and 2025 will see true transformation.

DataStax CEO: 2025 will be the year we see true AI transformation

DataStax debuts a series of tools to improve enterprise RAG including Langflow 1.0, Vectorize and RAGStack 1.0.

DataStax looks to help enterprises escape RAG 'Hell' with AI tools update

DataStax introduces Hyper Converged Data Platform that can be deployed on-premises, in the cloud or at the edge, to support enterprise AI and database requirements.

DataStax previews new Hyper Converged Data Platform for enterprise AI

The CPO from DataStax joins the AI Impact tour to dive into the challenges of going beyond ideation and putting gen AI into production.

AI Impact Tour: How companies are going from ideation to real-world implementation

DataStax acquires Langflow, an open-source platform for building retrieval-augmented generation applications, to accelerate enterprise adoption of generative AI and simplify AI app development.

DataStax acquires Langflow to accelerate enterprise generative AI app development

DataStax

datastax

A look at two databases that have made claims to the Kubernetes native label: TiDB and DataStax Astra DB. The cloud computing revolution has inspired and benefitted from multiple interrelated trends. The availability of self-service, public cloud infrastructure has helped to drive the adoption of microservice architectures and DevOps practices, including automation and observability. The drive toward containerization and container orchestration has led to the widespread adoption of Kubernetes as an environment for managing cloud-native applications. But one of the lagging areas in this revolution has been data and data infrastructure. For too long, data has been something that has lived outside of Kubernetes, leading to a lot of extra effort and complexity for developers in deploying cloud-native applications. One oft-repeated axiom in the early years of Kubernetes was that it was not yet ready for stateful workloads. Thankfully, a major shift has been quietly underway and has reached a point of maturity. The transformation happened slowly initially, beginning with efforts to containerize existing databases. This worked relatively well in small databases that ran on a single compute node, or databases that had been designed in a cloud-native world, like Apache Cassandra and DynamoDB, but challenges remained. Over the past two to three years, a new generation of databases has emerged. These “Kubernetes native” databases have been designed from the ground up to run on this open-source orchestration system. Here, we’ll define the qualities that make a database Kubernetes native and the benefits of adopting a Kubernetes native database. To do that, we’ll look at two databases claiming the Kubernetes native label: TiDB and DataStax Astra DB. Kubernetes Native MySQL with TiDB First, let’s examine a database with a relational emphasis: (short for Titanium Database). TiDB is an open-source system built by PingCAP that provides a and a columnar database to support hybrid transactional and analytic processing (known as HTAP, for short). TiDB MySQL-compatible database As shown in Figure 1 below, TiDB has a microservice design. The TiDB query layer, TiKV MySQL databases, TiFlash columnar databases, Spark nodes, and metadata management are each deployed as scalable microservices in their clusters. This design separates compute-intensive work from storage-intensive work, as the query and database layers are independently scalable. One critical commitment the TiDB creators made was that the database only runs on Kubernetes. Is that enough to make it Kubernetes native? Let’s dig a bit deeper. First, TiDB is deployed and managed by a Kubernetes operator using (CRDs). The TiDB CRDs include the TiDBCluster, which enables you to specify the scaling and configuration of each microservice and how the database layer components use storage through Kubernetes Persistent Volumes. Additional CRDs are used to deploy monitoring tools and manage operational tasks like backup and restore. custom resources that interfaces with the default K8s scheduler to make more application-aware scheduling decisions. This emphasis on using existing Kubernetes capabilities where available is the mark of a Kubernetes native database. TiDB also has an optional scheduler extension Kubernetes Native Cassandra with DataStax Astra DB Now, look at another Kubernetes native database and note some similarities and differences. that was one of the first to claim to be cloud native, but what does it look like to deploy Cassandra in Kubernetes? is a highly scalable NoSQL database Cassandra that has been factored into microservices, as shown in Figure 2. is a version of Cassandra DataStax Astra DB Like TiDB, the database includes microservices concerned with query processing and data storage, as well as services for identity and access control, data repair, and backup/restore. The data services are particularly interesting in their use of , with Kubernetes Persistent Volumes used only for caching and object storage used for longer-term persistence. Separating compaction into its service enables this compute-intensive processing to happen in the background without affecting the performance of data services serving read and write traffic. storage Astra DB is offered as a managed service available in multiple cloud regions. Each region contains a data plane consisting of the services mentioned above, managed by a Kubernetes operator, as well as infrastructure services, including the stack for observability and for metadata management. Kube-Promethus etcd The data planes are managed by a control plane that can run in one or more clouds to manage customer accounts and databases and provision Kubernetes clusters in new regions. in which multiple user databases can share the same microservices and supporting infrastructure, lowering unit economics for smaller-scale users. One novel aspect of Astra DB is its multi-tenant architecture As users grow their applications, they can move to dedicated resources to achieve optimal performance at scale, all on a “ ” basis. pay-as-you-go Kubernetes Native Database Principles Based on our observations of TiDB and Astra DB, we can derive some ideas of what makes a database Kubernetes native. Many of these correspond to a list of principles for cloud-native data, which I described in an : earlier article First, a database broken into constituent microservices enables each service to be scaled independently. Some types of compute-intensive processing may even be scaled to zero for a true serverless solution, especially when combined with a multitenant design. Composable microservice architecture: Microservices composed of a Kubernetes native database should make maximum usage of Kubernetes APIs for managing the fundamental resources of cloud-native applications: compute resources such as , Kubernetes ingress and services for exposing network access to data and more. This includes leveraging capabilities already present in Kubernetes, such as etcd for metadata management, instead of bringing along components with duplicative functionality. Treat compute, network, and storage as commodities: StatefulSets and deployments for managing workloads, the Persistent Volume subsystem for storage Following common patterns for Kubernetes applications will yield multiple operational benefits, for example, . By default, Kubernetes itself sets a great example that databases should follow for how to be secure: using Kubernetes Secrets to distribute security credentials, only exposing ports as needed, and so on. Leverage Kubernetes best practices: exposing liveness and readiness checks on each microservice to help availability and exposing metrics via the Prometheus PromQL API for observability A Kubernetes native database should embody the Kubernetes principles of declarative management via operators and custom resources, rather than relying on legacy database management UIs and CLIs. When necessary, . The goal is a clean separation of data plane functionality (managing data) from control plane functionality (managing the database). Declarative management via operators: Kubernetes extension points, such as scheduler extensions, can be used to add application-specific behavior Databases and other data infrastructures that faithfully adopt these principles will yield benefits, including a , lower operational complexity resulting in faster time to market, and standards-compliant solutions meeting today’s high availability and security demands. high performance for optimal cost at all scales The Future of Kubernetes Native Data Infrastructure Much progress is still to be made, and it’s not limited to databases alone. Kubernetes native principles can be applied to other types of data infrastructure, including streaming, analytics, and machine learning. Kubernetes native solutions will continue to make strides in multicluster and multi-cloud deployments to scale globally and will adopt multitenancy and serverless principles for better cost optimization. Kubernetes itself has room for improvement in adding more flexibility to StatefulSets and support for multicluster federation. The key to continued progress is open collaboration. The is a highly active group of data geeks bringing together builders of data-intensive applications and the infrastructure that supports them. Data on Kubernetes Community Join us to talk about ideas like developing reusable operators that can manage multiple databases or defining a common set of CRDs for concepts like backup/restore and data loading. Together we’ll continue to push the horizon of cloud computing for the benefit of all. Learn more about Kassandra native databases and more at the digital summit on March 14, 2023. Cassandra Forward This article is based on Chapter 7, “The Kubernetes Native Database,” from the O’Reilly book “ Managing Cloud Native Data on Kubernetes ” by Jeff Carpenter and Patrick McFadin. [ By Jeff Carpenter, DataStax Jeff Carpenter has worked as a software engineer and architect in multiple industries and as a developer advocate at DataStax, helping engineers succeed with Apache Cassandra. He's involved in multiple open source projects in the Cassandra and Kubernetes ecosystems, including Stargate and K8ssandra. He is co-author of the O’Reilly books "Cassandra: The Definitive Guide" and "Managing Cloud Native Data on Kubernetes."

Kubernetes-Native Database: TiDB Vs. DataStax Astra DB

Base de datos nativa de Kubernetes: TiDB vs. Base de datos DataStax Astra

Base de données native Kubernetes : TiDB Vs. DataStax Astra DB

कुबेरनेट्स-नेटिव डेटाबेस: TiDB बनाम। डेटास्टैक्स एस्ट्रा डीबी

Kubernetes ネイティブ データベース: TiDB Vs. DataStax アストラ DB

Banco de dados nativo do Kubernetes: TiDB vs. Data Stax Astra DB

Cơ sở dữ liệu gốc Kubernetes: TiDB Vs. DataStax Astra DB

Kubernetes 原生数据库：TiDB 对比。 DataStax Astra 数据库

When people think of generative AI, many envision it working as part of a “system of engagement” — a customer service agent, a supply chain management tool, or a way to intelligently interact with and search an organization’s PDFs and other proprietary data. That’s an accurate view – for the next year or two, applications that intelligently create content by leveraging large language models (LLMs) will remain a primary AI focus for enterprises. But consider this: Most of the code written at enterprises sits within business processes — systems like inventory planning, which sit between the engagement layer and the more rigid systems of record (an organization’s data, etc.) How will GenAI benefit that layer? How can an organization improve its business processes with this pervasive technology? Agentic AI is the answer. While AI agents are built to do specific tasks or automate specific, often repetitive tasks (like updating your calendar), they generally require human input. Agentic AI is all about autonomy (think self-driving cars), employing a system of agents to constantly adapt to dynamic environments and independently create, execute, and optimize results. When agentic AI is applied to business process workflows, it can replace fragile, static business processes with dynamic, context-aware automation systems. Let’s take a look at why integrating AI agents into enterprise architectures marks a transformative leap in the way organizations approach automation and business processes, and what kind of platform is required to support these systems of automation. What Agents Are Doing Now When you provide an agent with context, the agent then feeds that context to an LLM and asks it to complete and respond to it. AI agents can also use capabilities to complete tasks on behalf of users. These AI agents can perform several key functions guided by instructions and information derived from context: Tool use — The agent uses external functions, APIs, or tools to extend its capabilities and perform specific tasks. This can include calling predefined functions or interfacing with external services (like making web requests using cURL or accessing RESTful APIs) to obtain context or execute actions beyond its inherent functionalities. Decision-making — The agent evaluates available information and selects the most appropriate action to achieve its goals. This involves analyzing context, weighing possible outcomes, and choosing a course of action that aligns with the desired objectives. Planning — The agent formulates a sequence of actions or strategies to achieve a specific goal. Reasoning — The agent analyzes the available context, draws conclusions, predicts outcomes of actions, and makes informed decisions about the optimal steps to take to reach the desired outcome. These latter kinds of functions – decision-making, planning, and reasoning – often involve multiple agents working together toward a goal. The agents could seek to refine generated code for correctness, debate whether an agentic decision is biased, or plan the use of other agentic capabilities to complete a task. Orchestrating an Agentic Network Models that power networks of agents are essentially stateless functions that take context as an input and output a response, so some kind of framework is necessary to orchestrate them. Part of that orchestration could be simple refinements (the model requests more information). This might sound analogous to retrieval-augmented generation (RAG) – and it should, because RAG is essentially a simplified form of agent architecture: It provides the model with a single tool that gets it additional information, often from a vector database. But multiagentic model frameworks take this further; they broker requests for additional information or provide a response that’s designed to be fed to another agent for refinements. One agent could, say, write some Python, while another then reviews it. Or an agent could express a goal or idea, and then a second agent’s job could be to break that up into a set of tasks or review the idea to find problems that the first agent can review, and then refine the idea. Your results start to get better and better. OK, but How Do I Build Agentic AI? In the near future, a lot of software engineers will become agentic process authors. They’ll build these processes by mixing and matching components: models, user input, goals – and critical business services. An example of one of these components is the stock in an inventory management system. What if you connected that system to an agent that could help optimize inventory levels during the holiday season? With the help of another agent who has done some historical inventory level analysis, you could ensure that there is just enough inventory to meet seasonal demand yet leave little inventory after the holiday rush. This might disappoint fervent after-Christmas sale shoppers, but it would also help prevent retailers from selling their wares at a loss. But how will developers build these systems? Agentic processes can, of course, be expressed with code, but it also helps to visualize them as “agentic flows” – one agent’s output becomes the input of another agent, and so on. Tools available now are already providing a lot of value in this effort to simplify building agentic systems. One such solution is Langflow, a visual, low-code builder for creating agentic AI applications and complex AI workflows by dragging and dropping different components, without the need for much coding. Langflow enables developers to define anything as a tool, including components like a prompt, data source, model, APIs, tools, or any other agents. We’ve recently seen significant demand for building “flows” with agents, as developers are creating a lot of applications that include several multiagent capabilities: Agents are the most popular type of component that developers are inserting into flows with Langflow. Wrapping up: From copilot to Pilot Agentic workflows bring together enterprise data, AI, and APIs, forming systems of automation that empower domain experts to scale their abilities and make enterprises work better through AI. Integrating AI agents into enterprise architectures marks a big leap in how organizations approach automation and business processes. These agents, empowered by LLMs and agentic frameworks, transcend traditional boundaries by seamlessly operating across processes, workflows, and code. Adopting agentic workflows promises to enhance efficiency, scalability, and responsiveness across business operations. They’ll manage entire workflows, handle complex tasks with greater adaptability, and improve customer experiences by providing more personalized and timely interactions. As automation becomes embedded in enterprise systems, AI copilots will graduate to pilots, and organizations that employ agentic AI will be better positioned to innovate, compete, and deliver value. For more details on agentic AI, read the free whitepaper, “Systems of Automation: The Future of Enterprise Architecture Is Agentic.” And check out this page to learn more about Langflow. Written by Ed Anuff, chief product officer, DataStax When people think of generative AI, many envision it working as part of a “system of engagement” — a customer service agent, a supply chain management tool, or a way to intelligently interact with and search an organization’s PDFs and other proprietary data. That’s an accurate view – for the next year or two, applications that intelligently create content by leveraging large language models (LLMs) will remain a primary AI focus for enterprises. leveraging large language models (LLMs) leveraging large language models (LLMs) But consider this: Most of the code written at enterprises sits within business processes — systems like inventory planning, which sit between the engagement layer and the more rigid systems of record (an organization’s data, etc.) How will GenAI benefit that layer? How can an organization improve its business processes with this pervasive technology? Agentic AI is the answer. While AI agents are built to do specific tasks or automate specific, often repetitive tasks (like updating your calendar), they generally require human input. Agentic AI is all about autonomy (think self-driving cars), employing a system of agents to constantly adapt to dynamic environments and independently create, execute, and optimize results. When agentic AI is applied to business process workflows, it can replace fragile, static business processes with dynamic, context-aware automation systems. Let’s take a look at why integrating AI agents into enterprise architectures marks a transformative leap in the way organizations approach automation and business processes, and what kind of platform is required to support these systems of automation. What Agents Are Doing Now When you provide an agent with context, the agent then feeds that context to an LLM and asks it to complete and respond to it. AI agents can also use capabilities to complete tasks on behalf of users. These AI agents can perform several key functions guided by instructions and information derived from context: Tool use — The agent uses external functions, APIs, or tools to extend its capabilities and perform specific tasks. This can include calling predefined functions or interfacing with external services (like making web requests using cURL or accessing RESTful APIs) to obtain context or execute actions beyond its inherent functionalities. Decision-making — The agent evaluates available information and selects the most appropriate action to achieve its goals. This involves analyzing context, weighing possible outcomes, and choosing a course of action that aligns with the desired objectives. Decision-making — Planning — The agent formulates a sequence of actions or strategies to achieve a specific goal. Planning — Reasoning — The agent analyzes the available context, draws conclusions, predicts outcomes of actions, and makes informed decisions about the optimal steps to take to reach the desired outcome. Reasoning — These latter kinds of functions – decision-making, planning, and reasoning – often involve multiple agents working together toward a goal. The agents could seek to refine generated code for correctness, debate whether an agentic decision is biased, or plan the use of other agentic capabilities to complete a task. Orchestrating an Agentic Network Models that power networks of agents are essentially stateless functions that take context as an input and output a response, so some kind of framework is necessary to orchestrate them. Part of that orchestration could be simple refinements (the model requests more information). This might sound analogous to retrieval-augmented generation (RAG) – and it should, because RAG is essentially a simplified form of agent architecture: It provides the model with a single tool that gets it additional information, often from a vector database. retrieval-augmented generation (RAG) retrieval-augmented generation (RAG) But multiagentic model frameworks take this further; they broker requests for additional information or provide a response that’s designed to be fed to another agent for refinements. One agent could, say, write some Python, while another then reviews it. Or an agent could express a goal or idea, and then a second agent’s job could be to break that up into a set of tasks or review the idea to find problems that the first agent can review, and then refine the idea. Your results start to get better and better. OK, but How Do I Build Agentic AI? In the near future, a lot of software engineers will become agentic process authors. They’ll build these processes by mixing and matching components: models, user input, goals – and critical business services. An example of one of these components is the stock in an inventory management system. What if you connected that system to an agent that could help optimize inventory levels during the holiday season? With the help of another agent who has done some historical inventory level analysis, you could ensure that there is just enough inventory to meet seasonal demand yet leave little inventory after the holiday rush. This might disappoint fervent after-Christmas sale shoppers, but it would also help prevent retailers from selling their wares at a loss. But how will developers build these systems? Agentic processes can, of course, be expressed with code, but it also helps to visualize them as “agentic flows” – one agent’s output becomes the input of another agent, and so on. Tools available now are already providing a lot of value in this effort to simplify building agentic systems. One such solution is Langflow , a visual, low-code builder for creating agentic AI applications and complex AI workflows by dragging and dropping different components, without the need for much coding. Langflow Langflow Langflow enables developers to define anything as a tool, including components like a prompt, data source, model, APIs, tools, or any other agents. We’ve recently seen significant demand for building “flows” with agents, as developers are creating a lot of applications that include several multiagent capabilities: Agents are the most popular type of component that developers are inserting into flows with Langflow. Wrapping up: From copilot to Pilot Agentic workflows bring together enterprise data, AI, and APIs, forming systems of automation that empower domain experts to scale their abilities and make enterprises work better through AI. Integrating AI agents into enterprise architectures marks a big leap in how organizations approach automation and business processes. These agents, empowered by LLMs and agentic frameworks, transcend traditional boundaries by seamlessly operating across processes, workflows, and code. Adopting agentic workflows promises to enhance efficiency, scalability, and responsiveness across business operations. They’ll manage entire workflows, handle complex tasks with greater adaptability, and improve customer experiences by providing more personalized and timely interactions. As automation becomes embedded in enterprise systems, AI copilots will graduate to pilots, and organizations that employ agentic AI will be better positioned to innovate, compete, and deliver value. For more details on agentic AI, read the free whitepaper, “Systems of Automation: The Future of Enterprise Architecture Is Agentic.” And check out this page to learn more about Langflow. For more details on agentic AI, read the free whitepaper, “ Systems of Automation: The Future of Enterprise Architecture Is Agentic. ” And check out this page to learn more about Langflow . Systems of Automation: The Future of Enterprise Architecture Is Agentic. Systems of Automation: The Future of Enterprise Architecture Is Agentic. this page this page to learn more about Langflow Written by Ed Anuff, chief product officer, DataStax Written by Ed Anuff, chief product officer, DataStax

AI Agents: How They're Getting Ready to Blow Up the Business Process Layer

وكلاء الذكاء الاصطناعي: كيف يستعدون لتفجير طبقة العمليات التجارية

Agents d'IA: com s'estan preparant per explotar la capa de processos empresarials

AI-agenter: Sådan bliver de klar til at sprænge forretningsproceslaget

Agentes de IA: cómo se están preparando para hacer estallar la capa de procesos de negocios

Agents IA : comment ils se préparent à faire exploser la couche des processus métier

AI エージェント: ビジネス プロセス層を爆破する準備

AI agentai: kaip jie ruošiasi susprogdinti verslo procesų sluoksnį

Agenci AI: Jak przygotowują się do wysadzenia warstwy procesów biznesowych

Agenti AI: Ako sa pripravujú vyhodiť do vzduchu vrstvu obchodných procesov

AI Agents: ከመይ ጌሮም ነቲ ናይ ቢዝነስ መስርሕ ንጣብ ንምፍንፋሕ ይዳለዉ ኣለዉ።

AI agentlari: ular biznes-jarayon qatlamini portlatish uchun qanday tayyorlanishmoqda

Ama-AI Agents: Balungela Kanjani Ukuqhumisa Isendlalelo Senqubo Yebhizinisi

Behind AI Agents: The Infrastructure That Supports Autonomy

Зад AI агентите: Инфраструктурата, която поддържа автономност

Darrere dels agents d'IA: la infraestructura que dóna suport a l'autonomia

Hinter KI-Agenten: Die Infrastruktur, die Autonomie unterstützt

Detrás de los agentes de IA: la infraestructura que sustenta la autonomía

AIエージェントの背後にあるもの：自律性を支えるインフラストラクチャ

AI აგენტების უკან: ინფრასტრუქტურა, რომელიც მხარს უჭერს ავტონომიას

Aiz AI aģentiem: infrastruktūra, kas atbalsta autonomiju

Зад агентите со вештачка интелигенција: Инфраструктурата што ја поддржува автономијата

AI Agentekuna qhipanpi: Autonomía Yanapakuq Infraestructura

Иза АИ агената: инфраструктура која подржава аутономију

ብድሕሪ ወኪላት ኤ.ኣይ.፡ ርእሰ-ምሕደራ ዝድግፍ ትሕተ-ቅርጺ

Ngasemva kweearhente ze-AI: Izibonelelo ezixhasa ukuzimela

A look at the application architecture of wealthAPI, a data analytics provider for the financial sector that has created a highly accurate way to identify recurring payment entries. At wealthAPI, we’ve always believed financial analytics should be smarter and faster, especially when identifying recurring payments hidden in transaction data. We’ve built a solution that transforms raw transaction data into actionable insights by leveraging AI. Our system uses vector embeddings to group transactions into recurring payment patterns, ensuring accuracy even when recurring payment entries contain subtle wording differences. From subscriptions to insurance payments, our platform delivers reliable results while maintaining the speed and scalability financial companies need. Here, we’ll show how we designed our architecture to solve these challenges, from data ingestion and vector embeddings to clustering transactions into meaningful groups. We’ll also explore how AI powers advanced features like semantic search, allowing users to find and analyze financial data effortlessly. What The Application Does wealthAPI tackles a common yet challenging problem for financial companies: identifying recurring payments, such as subscriptions, in bank transaction histories. Traditional methods struggled with scaling and often relied on exact matches, missing subtle differences (e.g., “Spotify” vs. “Spotify AB”). wealthAPI addresses this problem with an AI-driven approach that delivers accuracy and speed. At the heart of this solution lies DataStax Astra DB, a database platform purpose-built for modern, scalable, and AI-integrated workflows. Architecture wealthAPI’s system takes raw bank transactions, processes them into embeddings, and groups them into recurring payment patterns — all powered by Astra DB’s vector similarity search capabilities. The architecture ensures scalability and responsiveness at each stage, even under high data volumes. Here’s a simplified flow of the process: Data ingestion - When bank transactions are received, the wealthAPI backend publishes them on a message queue for asynchronous processing.


Embedding creation - Each transaction (e.g., “Spotify, -10€, 22.10.24”) is transformed into a numeric vector (e.g., [0.12, 0.65, 0.78, ..., 0.23]) using Astra DB’s vectorize feature.


Vector storage and search in Astra DB - The embeddings are stored in Astra DB, where lightning-fast vector similarity searches allow the system to find and cluster similar transactions.


Regularity analysis - The clusters are analyzed to identify recurring payments, categorizing them as contracts like “Spotify - music service - monthly" or "Health insurance - Health - yearly." Astra DB ensures the entire process is scalable and responsive, even with high volumes of data. The process also adheres to strict data security measures to ensure that end users and their transactions remain anonymous and protected from external access. Technical Implementation Clustering transactions into contracts Grouping transactions has always been a core challenge. Previous tools depended on exact matches (e.g., vendor name or payment amount), which often failed to capture variations and were slow to scale. At wealthAPI, we tried searching for patterns among millions of transactions with traditional databases in the past, which was both slow and prone to errors. Even small variations in transaction details broke the clustering logic. Because we’re using Astra DB, we can store embeddings and efficiently search for similar transactions, even with minor variations in details. Here’s an example: A payment labeled “Spotify AB” for €10 on one day and “Spotify” for €10 the next is correctly grouped as the same recurring payment. Handling Large Data Volumes With thousands of transactions processed daily, wealthAPI required a database that could scale seamlessly while maintaining speed and accuracy. Astra DB’s foundation is Apache Cassandra, so it’s built for scalability. It also integrates with AI workflows, enabling wealthAPI to maintain fast queries without compromising precision. Transaction Search Engine Because embeddings capture the underlying meaning of transactions, wealthAPI can also implement a search feature. Users can type a keyword like “health” to retrieve all health-related transactions without relying on predefined tags or categories. The system generates an embedding from the user query and runs a simple similarity search using Astra DB; its vector search capability makes this kind of semantic search fast and accurate. A user typing “health,” for example, will see all payments for health-related services, like insurance or gym memberships, even if the vendor names differ. Wrapping Up wealthAPI’s use of Astra DB demonstrates how advanced database technology can drive innovation in financial analytics. From precise transaction clustering to enabling a cutting-edge semantic search engine, Astra DB’s vector search and scalability empower wealthAPI to deliver faster, smarter solutions to its clients. By integrating AI workflows directly into Astra DB’s architecture, wealthAPI has enhanced financial data processing and introduced a valuable new capability for contract analytics. By Belkacem Berchiche, machine learning engineer, wealthAPI, and Dieter Flick, solution engineer, DataStax Learn more about Astra DB and wealthAPI. A look at the application architecture of wealthAPI, a data analytics provider for the financial sector that has created a highly accurate way to identify recurring payment entries. A look at the application architecture of wealthAPI, a data analytics provider for the financial sector that has created a highly accurate way to identify recurring payment entries. A look at the application architecture of wealthAPI, a data analytics provider for the financial sector that has created a highly accurate way to identify recurring payment entries. At wealthAPI , we’ve always believed financial analytics should be smarter and faster, especially when identifying recurring payments hidden in transaction data. We’ve built a solution that transforms raw transaction data into actionable insights by leveraging AI. Our system uses vector embeddings to group transactions into recurring payment patterns, ensuring accuracy even when recurring payment entries contain subtle wording differences. wealthAPI From subscriptions to insurance payments, our platform delivers reliable results while maintaining the speed and scalability financial companies need. Here, we’ll show how we designed our architecture to solve these challenges, from data ingestion and vector embeddings to clustering transactions into meaningful groups. We’ll also explore how AI powers advanced features like semantic search, allowing users to find and analyze financial data effortlessly. What The Application Does wealthAPI tackles a common yet challenging problem for financial companies: identifying recurring payments, such as subscriptions, in bank transaction histories. Traditional methods struggled with scaling and often relied on exact matches, missing subtle differences (e.g., “Spotify” vs. “Spotify AB”). wealthAPI addresses this problem with an AI-driven approach that delivers accuracy and speed. At the heart of this solution lies DataStax Astra DB , a database platform purpose-built for modern, scalable, and AI-integrated workflows. DataStax Astra DB Architecture wealthAPI’s system takes raw bank transactions, processes them into embeddings, and groups them into recurring payment patterns — all powered by Astra DB’s vector similarity search capabilities. The architecture ensures scalability and responsiveness at each stage, even under high data volumes. Here’s a simplified flow of the process: Data ingestion - When bank transactions are received, the wealthAPI backend publishes them on a message queue for asynchronous processing. Embedding creation - Each transaction (e.g., “Spotify, -10€, 22.10.24”) is transformed into a numeric vector (e.g., [0.12, 0.65, 0.78, ..., 0.23]) using Astra DB’s vectorize feature. Vector storage and search in Astra DB - The embeddings are stored in Astra DB, where lightning-fast vector similarity searches allow the system to find and cluster similar transactions. Regularity analysis - The clusters are analyzed to identify recurring payments, categorizing them as contracts like “Spotify - music service - monthly" or "Health insurance - Health - yearly." Data ingestion - When bank transactions are received, the wealthAPI backend publishes them on a message queue for asynchronous processing. Data ingestion - When bank transactions are received, the wealthAPI backend publishes them on a message queue for asynchronous processing. Data ingestion - Embedding creation - Each transaction (e.g., “Spotify, -10€, 22.10.24”) is transformed into a numeric vector (e.g., [0.12, 0.65, 0.78, ..., 0.23]) using Astra DB’s vectorize feature. Embedding creation - Each transaction (e.g., “Spotify, -10€, 22.10.24”) is transformed into a numeric vector (e.g., [0.12, 0.65, 0.78, ..., 0.23]) using Astra DB’s vectorize feature. Embedding creation - Vector storage and search in Astra DB - The embeddings are stored in Astra DB, where lightning-fast vector similarity searches allow the system to find and cluster similar transactions. Vector storage and search in Astra DB - The embeddings are stored in Astra DB, where lightning-fast vector similarity searches allow the system to find and cluster similar transactions. Vector storage and search in Astra DB - Regularity analysis - The clusters are analyzed to identify recurring payments, categorizing them as contracts like “Spotify - music service - monthly" or "Health insurance - Health - yearly." Regularity analysis - The clusters are analyzed to identify recurring payments, categorizing them as contracts like “Spotify - music service - monthly" or "Health insurance - Health - yearly." Regularity analysis - Astra DB ensures the entire process is scalable and responsive, even with high volumes of data. The process also adheres to strict data security measures to ensure that end users and their transactions remain anonymous and protected from external access. Technical Implementation Clustering transactions into contracts Grouping transactions has always been a core challenge. Previous tools depended on exact matches (e.g., vendor name or payment amount), which often failed to capture variations and were slow to scale. At wealthAPI, we tried searching for patterns among millions of transactions with traditional databases in the past, which was both slow and prone to errors. Even small variations in transaction details broke the clustering logic. Because we’re using Astra DB, we can store embeddings and efficiently search for similar transactions, even with minor variations in details. Here’s an example: A payment labeled “Spotify AB” for €10 on one day and “Spotify” for €10 the next is correctly grouped as the same recurring payment. Handling Large Data Volumes With thousands of transactions processed daily, wealthAPI required a database that could scale seamlessly while maintaining speed and accuracy. Astra DB’s foundation is Apache Cassandra, so it’s built for scalability. It also integrates with AI workflows, enabling wealthAPI to maintain fast queries without compromising precision. Transaction Search Engine Because embeddings capture the underlying meaning of transactions, wealthAPI can also implement a search feature. Users can type a keyword like “health” to retrieve all health-related transactions without relying on predefined tags or categories. The system generates an embedding from the user query and runs a simple similarity search using Astra DB; its vector search capability makes this kind of semantic search fast and accurate. A user typing “health,” for example, will see all payments for health-related services, like insurance or gym memberships, even if the vendor names differ. Wrapping Up wealthAPI’s use of Astra DB demonstrates how advanced database technology can drive innovation in financial analytics. From precise transaction clustering to enabling a cutting-edge semantic search engine, Astra DB’s vector search and scalability empower wealthAPI to deliver faster, smarter solutions to its clients. By integrating AI workflows directly into Astra DB’s architecture, wealthAPI has enhanced financial data processing and introduced a valuable new capability for contract analytics. By Belkacem Berchiche, machine learning engineer, wealthAPI, and Dieter Flick, solution engineer, DataStax By Belkacem Berchiche, machine learning engineer, wealthAPI, and Dieter Flick, solution engineer, DataStax Learn more about Astra DB and wealthAPI. Learn more about Astra DB and wealthAPI. Learn more about Astra DB and wealthAPI . Astra DB Astra DB wealthAPI wealthAPI

How Vector Search Cracks the Code on Contract Analytics 

Как Vector Search разбива кода на Contract Analytics 

Com la cerca vectorial trenca el codi a l'anàlisi de contractes 

Cómo Vector Search descifra el código del análisis de contratos

Kuinka vektorihaku murtaa koodin sopimusanalyysissä 

Como a busca vectorial descifra o código en analítica de contratos 

כיצד חיפוש וקטור מפצח את הקוד בניתוח חוזים 

Come la ricerca vettoriale decifra il codice dell'analisi contrattuale

Vector Search が契約分析のコード解読に成功

Ndenge nini Vector Search Ezali ko craquer Code na Analytique ya Contrat 

Kaip vektorinė paieška nulaužia sutarčių analizės kodą 

Cara Carian Vektor Memecahkan Kod pada Analitis Kontrak 

Ukuseshwa KweVector Kuyiqhekeza Kanjani Ikhodi Kuzibalo Zenkontileka 

Vector search effectively delivers semantic similarity for retrieval augmented generation, but it does poorly with short keyword searches or out-of-domain search terms. Supplementing vector retrieval with keyword searches like BM25 and combining the results with a reranker is becoming the standard way to get the best of both worlds. Rerankers are ML models that take a set of search results and reorder them to improve relevance. They examine the query paired with each candidate result in detail, which is computationally expensive but produces more accurate results than simple retrieval methods alone. This can be done either as a second stage on top of a single search (pull 100 results out of vector search, then ask the reranker to identify the top 10) or, more often, to combine results from different kinds of search; in this case, vector search and keyword search. But how good are off-the-shelf rerankers? To find out, I tested six rerankers on the text from the ViDoRe benchmark, using Gemini Flash to extract text from the images. Details on the datasets can be found in section 3.1 of the ColPali paper. Notably, TabFQuAD and Shift Project sources are in French; the rest are in English. We tested these rerankers: Reciprocal Rank Fusion (RRF), a formula for combining results from multiple sources without knowing anything about the queries or documents; it depends purely on relative ordering within each source. RRF is used in Elastic and LlamaIndex, among other projects. Cohere Rerank v3 and Jina Reranker v2, probably the most popular hosted models. BGE-reranker-v2-m3, the highest-scoring open source model (Apache licensed). Voyage rerank-2 and rerank-2-lite, freshly released (in September) by a solid company. The rerankers were fed the top 20 results from both DPR and BM25, and the reranked NDCG@5 was evaluated. In the results, raw vector search (with embeddings from the bge-m3 model) is labeled dpr (dense passage retrieval). BGE-m3 was chosen to compute embeddings because that’s what the ColPali authors used as a baseline. Here’s the data on relevance (NDCG@5): And here’s how fast they are at reranking searches in the arxiv dataset; latency is proportional to document length. This is graphing latency, so lower is better. The self-hosted bge model was run on an NVIDIA 3090 using the simplest possible code lifted straight from the Hugging Face model card. Finally, here’s how much it cost with each model to rerank the almost 3,000 searches from all six datasets. Cohere prices per search (with additional fees for long documents), while the others price per token. Analysis All the models do roughly as well on the French datasets as they do on the English ones. Cohere is significantly more expensive and offers slightly (but consistently) worse relevance than the other ML rerankers – but it’s 3x faster than the next-fastest services. Additionally, Cohere’s standard rate limits are the most generous. Voyage rerank-2 is the king of reranking relevance in all datasets, for an additional hit to latency. Notably, it’s the only model that does not do worse than DPR alone in the arxiv dataset, which seems to be particularly tricky. Voyage rerank-2-lite and jina reranker v2 are very, very similar: they’re the same speed, hosted at the same price, and close to the same relevance (with a slight edge to Voyage). But Voyage’s standard rate limit is double jina’s, and with Voyage you get a “real” Python client instead of having to make raw http requests. BGE-reranker-v2-m3 is such a lightweight model (under 600M parameters) that even on an older consumer GPU it is usably fast. Conclusion RRF adds little to no value to hybrid search scenarios; on half of the datasets, it performed worse than either BM25 or DPR alone. In contrast, all ML-based rerankers tested delivered meaningful improvements over pure vector or keyword search, with Voyage rerank-2 setting the bar for relevance. Tradeoffs are still present: superior accuracy from Voyage rerank-2, faster processing from Cohere, or solid middle-ground performance from Jina or Voyage's lite model. Even the open-source BGE reranker, while trailing commercial options, adds significant value for teams choosing to self-host. As foundation models continue advancing, we can expect even better performance. But today's ML rerankers are already mature enough to deploy with confidence across multilingual content. By Jonathan Ellis, DataStax Vector search effectively delivers semantic similarity for retrieval augmented generation, but it does poorly with short keyword searches or out-of-domain search terms. Supplementing vector retrieval with keyword searches like BM25 and combining the results with a reranker is becoming the standard way to get the best of both worlds. Rerankers are ML models that take a set of search results and reorder them to improve relevance. They examine the query paired with each candidate result in detail, which is computationally expensive but produces more accurate results than simple retrieval methods alone. This can be done either as a second stage on top of a single search (pull 100 results out of vector search, then ask the reranker to identify the top 10) or, more often, to combine results from different kinds of search; in this case, vector search and keyword search. But how good are off-the-shelf rerankers? To find out, I tested six rerankers on the text from the ViDoRe benchmark , using Gemini Flash to extract text from the images. Details on the datasets can be found in section 3.1 of the ColPali paper . Notably, TabFQuAD and Shift Project sources are in French; the rest are in English. ViDoRe benchmark ViDoRe benchmark the ColPali paper the ColPali paper We tested these rerankers: Reciprocal Rank Fusion (RRF), a formula for combining results from multiple sources without knowing anything about the queries or documents; it depends purely on relative ordering within each source. RRF is used in Elastic and LlamaIndex, among other projects. Reciprocal Rank Fusion (RRF), a formula for combining results from multiple sources without knowing anything about the queries or documents; it depends purely on relative ordering within each source. RRF is used in Elastic and LlamaIndex, among other projects. Reciprocal Rank Fusion Reciprocal Rank Fusion Cohere Rerank v3 and Jina Reranker v2, probably the most popular hosted models. Cohere Rerank v3 and Jina Reranker v2 , probably the most popular hosted models. Cohere Rerank v3 Cohere Rerank v3 Jina Reranker v2 Jina Reranker v2 BGE-reranker-v2-m3, the highest-scoring open source model (Apache licensed). BGE-reranker-v2-m3 , the highest-scoring open source model (Apache licensed). BGE-reranker-v2-m3 BGE-reranker-v2-m3 Voyage rerank-2 and rerank-2-lite, freshly released (in September) by a solid company. Voyage rerank-2 and rerank-2-lite, freshly released ( in September ) by a solid company. Voyage rerank-2 Voyage rerank-2 in September in September The rerankers were fed the top 20 results from both DPR and BM25, and the reranked NDCG@5 was evaluated. In the results, raw vector search (with embeddings from the bge-m3 model) is labeled dpr (dense passage retrieval). BGE-m3 was chosen to compute embeddings because that’s what the ColPali authors used as a baseline. Here’s the data on relevance (NDCG@5): And here’s how fast they are at reranking searches in the arxiv dataset; latency is proportional to document length. This is graphing latency, so lower is better. The self-hosted bge model was run on an NVIDIA 3090 using the simplest possible code lifted straight from the Hugging Face model card . the Hugging Face model card the Hugging Face model card Finally, here’s how much it cost with each model to rerank the almost 3,000 searches from all six datasets. Cohere prices per search (with additional fees for long documents), while the others price per token. Analysis All the models do roughly as well on the French datasets as they do on the English ones. All the models do roughly as well on the French datasets as they do on the English ones. Cohere is significantly more expensive and offers slightly (but consistently) worse relevance than the other ML rerankers – but it’s 3x faster than the next-fastest services. Additionally, Cohere’s standard rate limits are the most generous. Cohere is significantly more expensive and offers slightly (but consistently) worse relevance than the other ML rerankers – but it’s 3x faster than the next-fastest services. Additionally, Cohere’s standard rate limits are the most generous. Cohere’s standard rate limits Cohere’s standard rate limits Voyage rerank-2 is the king of reranking relevance in all datasets, for an additional hit to latency. Notably, it’s the only model that does not do worse than DPR alone in the arxiv dataset, which seems to be particularly tricky. Voyage rerank-2 is the king of reranking relevance in all datasets, for an additional hit to latency. Notably, it’s the only model that does not do worse than DPR alone in the arxiv dataset, which seems to be particularly tricky. Voyage rerank-2-lite and jina reranker v2 are very, very similar: they’re the same speed, hosted at the same price, and close to the same relevance (with a slight edge to Voyage). But Voyage’s standard rate limit is double jina’s, and with Voyage you get a “real” Python client instead of having to make raw http requests. Voyage rerank-2-lite and jina reranker v2 are very, very similar: they’re the same speed, hosted at the same price, and close to the same relevance (with a slight edge to Voyage). But Voyage’s standard rate limit is double jina’s , and with Voyage you get a “real” Python client instead of having to make raw http requests. Voyage’s standard rate limit Voyage’s standard rate limit jina’s jina’s Python client Python client BGE-reranker-v2-m3 is such a lightweight model (under 600M parameters) that even on an older consumer GPU it is usably fast. BGE-reranker-v2-m3 is such a lightweight model (under 600M parameters) that even on an older consumer GPU it is usably fast. Conclusion RRF adds little to no value to hybrid search scenarios; on half of the datasets, it performed worse than either BM25 or DPR alone. In contrast, all ML-based rerankers tested delivered meaningful improvements over pure vector or keyword search, with Voyage rerank-2 setting the bar for relevance. Tradeoffs are still present: superior accuracy from Voyage rerank-2, faster processing from Cohere, or solid middle-ground performance from Jina or Voyage's lite model. Even the open-source BGE reranker, while trailing commercial options, adds significant value for teams choosing to self-host. As foundation models continue advancing, we can expect even better performance. But today's ML rerankers are already mature enough to deploy with confidence across multilingual content. By Jonathan Ellis, DataStax

Vector Search: A Reranker Algorithm Showdown

Vektorsoektog: 'n Reranker Algorithm Showdown

Вектарны пошук: разборка алгарытму Reranker

Búsqueda de vectores: un duelo entre algoritmos de reclasificación

Bektore bilaketa: A Reranker Algorithm Showdown

ベクトル検索: リランカーアルゴリズムの対決

Vector Maskay: Huk Reranker Algoritmo Enfrentamiento

Căutare Vector: A Reranker Algorithm Showdown

Gushakisha Vector: A Reranker Algorithm Yerekana

Vyhľadávanie vektorov: Reranker Algorithm Showdown

Wektor gözlegi: Reranker algoritminiň görkezilişi

Ku Lavisisa ka Vector: Nkombiso wa Algorithm ya Reranker

I-Vector Search: I-Reranker Algorithm Showdown

Using knowledge graphs to improve the results of retrieval-augmented generation (RAG) applications has become a hot topic. Most examples demonstrate how to build a knowledge graph using a relatively small number of documents. This might be because the typical approach – extracting fine-grained, entity-centric information – just doesn’t scale. Running each document through a model to extract the entities (nodes) and relationships (edges) takes too long (and costs too much) to run on large datasets. We’ve argued that content-centric knowledge graphs – a vector-store allowing links between chunks – are an easier to use and more efficient approach. Here, we put that to the test. We load a subset of the Wikipedia articles from the 2wikimultihop dataset using both techniques and discuss what this means for loading the entire dataset. We demonstrate the results of some questions over the loaded data. We’ll also load the entire dataset – nearly 6 million documents – into a content-centric GraphVectorStore. Entity-centric: LLMGraphTransformer Loading documents into an entity-centric graph store like Neo4j was done using LangChain’s LLMGraphTransformer. The code is based on LangChain's "How to construct knowledge graphs." from langchain_core.documents import Document
from langchain_experimental.graph_transformers import LLMGraphTransformer
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(temperature=0, model_name="gpt-4-turbo")
llm_transformer = LLMGraphTransformer(llm=llm)

from time import perf_counter
start = perf_counter()

documents_to_load = [Document(page_content=line) for line in lines_to_load]
graph_documents = llm_transformer.convert_to_graph_documents(documents_to_load)

end = perf_counter()
print(f"Loaded (but NOT written) {NUM_LINES_TO_LOAD} in {end - start:0.2f}s") Content-centric: GraphVectorStore Loading the data into GraphVectorStore is roughly the same as loading it into a vector store. The only addition is that we compute metadata indicating how each page links to other pages. import json
from langchain_core.graph_vectorstores.links import METADATA_LINKS_KEY, Link

def parse_document(line: str) -> Document:
    para = json.loads(line)

    id = para["id"]
    links = {
        Link.outgoing(kind="href", tag=id)
        for m in para["mentions"]
        if m["ref_ids"] is not None
        for id in m["ref_ids"]
    }
    links.add(Link.incoming(kind="href", tag=id))
    return Document(
        id = id,
        page_content = " ".join(para["sentences"]),
        metadata = {
            "content_id": para["id"],
            METADATA_LINKS_KEY: list(links)
        },
    ) This is also a good example of how you can add your own links between nodes. from langchain_openai import OpenAIEmbeddings
from langchain_community.graph_vectorstores.cassandra import CassandraGraphVectorStore
import cassio

cassio.init(auto=True)
TABLE_NAME = "wiki_load"
store = CassandraGraphVectorStore(
embedding = OpenAIEmbeddings(),
node_table=TABLE_NAME,
insert_timeout = 1000.0,
)

from time import perf_counter
start = perf_counter()

from datasets.wikimultihop.load import parse_document
kg_documents = [parse_document(line) for line in lines_to_load]
store.add_documents(kg_documents)

end = perf_counter()
print(f"Loaded (and written) {NUM_LINES_TO_LOAD} in {end - start:0.2f}s") Loading benchmarks Running at 100 rows, the entity-centric approach using GPT-4o took 405.93s to extract the GraphDocuments and 10.99s to write them to Neo4j, while the content-centric approach took 1.43s. Extrapolating, it would take 41 weeks to load all 5,989,847 pages using the entity-centric approach and about 24 hours using the content-centric approach. But thanks to parallelism, the content-centric approach runs in only 2.5 hours! Assuming the same parallelism benefits, it would still take over four weeks to load everything using the entity-centric approach. I didn’t try it since the estimated cost would be $58,700 — assuming everything worked the first time! Bottom-line: the entity-centric approach of extracting knowledge graphs from content using an LLM was both time and cost prohibitive at scale. On the other hand, using GraphVectorStore was fast and inexpensive. Example answers In this section, a few questions, drawn from the subset of loaded documents, are asked to address the quality of answers. Entity-centric used 7324 prompt tokens and cost $0.03 to produce basically useless answers, while content-centric used 450 prompt tokens and cost $0.002 to produce concise answers directly answering the questions. It may be surprising that the fine-grained Neo4j graph returns useless answers. Looking at the logging from the chain, we see some of why this happens: > Entering new GraphCypherQAChain chain...

Generated Cypher:

cypher

MATCH (a:Album {id: 'The Circle'})-[:RELEASED_BY]->(r:Record_label)

RETURN a.id, r.id


Full Context:

[{'a.id': 'The Circle', 'r.id': 'Restless'}]


> Finished chain.

{'query': "When was 'The Circle' released?", 'result': "I don't know the answer."} So, the fine-grained schema only returned information about the record label. It makes sense that the LLM wasn’t able to answer the question based on the retrieved information. Conclusion Extracting fine-grained, entity-specific knowledge graphs is time- and cost-prohibitive at scale. When asked questions about the subset of data that was loaded, the additional granularity (and extra cost of loading the fine-grained graph) returned more tokens to include the prompt but generated useless answers! GraphVectorStore takes a coarse-grained, content-centric approach that makes it fast and easy to build a knowledge graph. You can start with your existing code for populating a VectorStore using LangChain and add links (edges) between chunks to improve the retrieval process. Graph RAG is a useful tool for enabling generative AI RAG applications to retrieve more deeply relevant contexts. But using a fine-grained, entity-centric approach does not scale to production needs. If you're looking to add knowledge graph capabilities to your RAG application, try GraphVectorStore. By Ben Chambers, DataStax Using knowledge graphs to improve the results of retrieval-augmented generation (RAG) applications has become a hot topic. Most examples demonstrate how to build a knowledge graph using a relatively small number of documents. This might be because the typical approach – extracting fine-grained, entity-centric information – just doesn’t scale. Running each document through a model to extract the entities (nodes) and relationships (edges) takes too long (and costs too much) to run on large datasets. We’ve argued that content-centric knowledge graphs – a vector-store allowing links between chunks – are an easier to use and more efficient approach. Here, we put that to the test. We load a subset of the Wikipedia articles from the 2wikimultihop dataset using both techniques and discuss what this means for loading the entire dataset. We demonstrate the results of some questions over the loaded data. We’ll also load the entire dataset – nearly 6 million documents – into a content-centric GraphVectorStore . content-centric knowledge graphs content-centric knowledge graphs 2wikimultihop 2wikimultihop GraphVectorStore GraphVectorStore Entity-centric: LLMGraphTransformer Loading documents into an entity-centric graph store like Neo4j was done using LangChain’s LLMGraphTransformer. The code is based on LangChain's "How to construct knowledge graphs." "How to construct knowledge graphs." "How to construct knowledge graphs." from langchain_core.documents import Document
from langchain_experimental.graph_transformers import LLMGraphTransformer
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(temperature=0, model_name="gpt-4-turbo")
llm_transformer = LLMGraphTransformer(llm=llm)

from time import perf_counter
start = perf_counter()

documents_to_load = [Document(page_content=line) for line in lines_to_load]
graph_documents = llm_transformer.convert_to_graph_documents(documents_to_load)

end = perf_counter()
print(f"Loaded (but NOT written) {NUM_LINES_TO_LOAD} in {end - start:0.2f}s") from langchain_core.documents import Document
from langchain_experimental.graph_transformers import LLMGraphTransformer
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(temperature=0, model_name="gpt-4-turbo")
llm_transformer = LLMGraphTransformer(llm=llm)

from time import perf_counter
start = perf_counter()

documents_to_load = [Document(page_content=line) for line in lines_to_load]
graph_documents = llm_transformer.convert_to_graph_documents(documents_to_load)

end = perf_counter()
print(f"Loaded (but NOT written) {NUM_LINES_TO_LOAD} in {end - start:0.2f}s") Content-centric: GraphVectorStore Loading the data into GraphVectorStore is roughly the same as loading it into a vector store. The only addition is that we compute metadata indicating how each page links to other pages. import json
from langchain_core.graph_vectorstores.links import METADATA_LINKS_KEY, Link

def parse_document(line: str) -> Document:
    para = json.loads(line)

    id = para["id"]
    links = {
        Link.outgoing(kind="href", tag=id)
        for m in para["mentions"]
        if m["ref_ids"] is not None
        for id in m["ref_ids"]
    }
    links.add(Link.incoming(kind="href", tag=id))
    return Document(
        id = id,
        page_content = " ".join(para["sentences"]),
        metadata = {
            "content_id": para["id"],
            METADATA_LINKS_KEY: list(links)
        },
    ) import json
from langchain_core.graph_vectorstores.links import METADATA_LINKS_KEY, Link

def parse_document(line: str) -> Document:
    para = json.loads(line)

    id = para["id"]
    links = {
        Link.outgoing(kind="href", tag=id)
        for m in para["mentions"]
        if m["ref_ids"] is not None
        for id in m["ref_ids"]
    }
    links.add(Link.incoming(kind="href", tag=id))
    return Document(
        id = id,
        page_content = " ".join(para["sentences"]),
        metadata = {
            "content_id": para["id"],
            METADATA_LINKS_KEY: list(links)
        },
    ) This is also a good example of how you can add your own links between nodes. from langchain_openai import OpenAIEmbeddings
from langchain_community.graph_vectorstores.cassandra import CassandraGraphVectorStore
import cassio

cassio.init(auto=True)
TABLE_NAME = "wiki_load"
store = CassandraGraphVectorStore(
embedding = OpenAIEmbeddings(),
node_table=TABLE_NAME,
insert_timeout = 1000.0,
)

from time import perf_counter
start = perf_counter()

from datasets.wikimultihop.load import parse_document
kg_documents = [parse_document(line) for line in lines_to_load]
store.add_documents(kg_documents)

end = perf_counter()
print(f"Loaded (and written) {NUM_LINES_TO_LOAD} in {end - start:0.2f}s") from langchain_openai import OpenAIEmbeddings
from langchain_community.graph_vectorstores.cassandra import CassandraGraphVectorStore
import cassio

cassio.init(auto=True)
TABLE_NAME = "wiki_load"
store = CassandraGraphVectorStore(
embedding = OpenAIEmbeddings(),
node_table=TABLE_NAME,
insert_timeout = 1000.0,
)

from time import perf_counter
start = perf_counter()

from datasets.wikimultihop.load import parse_document
kg_documents = [parse_document(line) for line in lines_to_load]
store.add_documents(kg_documents)

end = perf_counter()
print(f"Loaded (and written) {NUM_LINES_TO_LOAD} in {end - start:0.2f}s") Loading benchmarks Running at 100 rows, the entity-centric approach using GPT-4o took 405.93s to extract the GraphDocuments and 10.99s to write them to Neo4j, while the content-centric approach took 1.43s. Extrapolating, it would take 41 weeks to load all 5,989,847 pages using the entity-centric approach and about 24 hours using the content-centric approach. But thanks to parallelism, the content-centric approach runs in only 2.5 hours! Assuming the same parallelism benefits, it would still take over four weeks to load everything using the entity-centric approach. I didn’t try it since the estimated cost would be $58,700 — assuming everything worked the first time! Bottom-line: the entity-centric approach of extracting knowledge graphs from content using an LLM was both time and cost prohibitive at scale. On the other hand, using GraphVectorStore was fast and inexpensive. Example answers Example answers In this section, a few questions, drawn from the subset of loaded documents, are asked to address the quality of answers. Entity-centric used 7324 prompt tokens and cost $0.03 to produce basically useless answers, while content-centric used 450 prompt tokens and cost $0.002 to produce concise answers directly answering the questions. It may be surprising that the fine-grained Neo4j graph returns useless answers. Looking at the logging from the chain, we see some of why this happens: > Entering new GraphCypherQAChain chain...

Generated Cypher:

cypher

MATCH (a:Album {id: 'The Circle'})-[:RELEASED_BY]->(r:Record_label)

RETURN a.id, r.id


Full Context:

[{'a.id': 'The Circle', 'r.id': 'Restless'}]


> Finished chain.

{'query': "When was 'The Circle' released?", 'result': "I don't know the answer."} > Entering new GraphCypherQAChain chain...

Generated Cypher:

cypher

MATCH (a:Album {id: 'The Circle'})-[:RELEASED_BY]->(r:Record_label)

RETURN a.id, r.id


Full Context:

[{'a.id': 'The Circle', 'r.id': 'Restless'}]


> Finished chain.

{'query': "When was 'The Circle' released?", 'result': "I don't know the answer."} So, the fine-grained schema only returned information about the record label. It makes sense that the LLM wasn’t able to answer the question based on the retrieved information. Conclusion Extracting fine-grained, entity-specific knowledge graphs is time- and cost-prohibitive at scale. When asked questions about the subset of data that was loaded, the additional granularity (and extra cost of loading the fine-grained graph) returned more tokens to include the prompt but generated useless answers! GraphVectorStore takes a coarse-grained, content-centric approach that makes it fast and easy to build a knowledge graph. You can start with your existing code for populating a VectorStore using LangChain and add links (edges) between chunks to improve the retrieval process. Graph RAG is a useful tool for enabling generative AI RAG applications to retrieve more deeply relevant contexts. But using a fine-grained, entity-centric approach does not scale to production needs. If you're looking to add knowledge graph capabilities to your RAG application, try GraphVectorStore . GraphVectorStore GraphVectorStore By Ben Chambers , DataStax Ben Chambers

How to Save $70K Building a Knowledge Graph for RAG on 6M Wikipedia Pages

Hoe om $70 000 te bespaar Die bou van 'n kennisgrafiek vir JOOL op 6M Wikipedia-bladsye

كيفية توفير 70 ألف دولار من خلال إنشاء رسم بياني للمعرفة لـ RAG على 6 ملايين صفحة ويكيبيديا

Com estalviar 70.000 dòlars Construint un gràfic de coneixement per a RAG a 6 milions de pàgines de Viquipèdia

Cómo ahorrar $70 000 creando un gráfico de conocimiento para RAG en 6 millones de páginas de Wikipedia

600 万の Wikipedia ページで RAG のナレッジ グラフを構築して 7 万ドルを節約する方法

របៀបសន្សំ $70K បង្កើត Knowledge Graph សម្រាប់ RAG នៅលើទំព័រ Wikipedia 6M

6 сая Wikipedia хуудсан дээр RAG-д зориулсан мэдлэгийн график бүтээхэд 70 мянган долларыг хэрхэн хэмнэх вэ

6M विकिपिडिया पृष्ठहरूमा RAG को लागि ज्ञान ग्राफ निर्माण गरेर $ 70K कसरी बचत गर्ने

په 6M ويکيپېډيا پاڼو کې د RAG لپاره د پوهې ګراف جوړول $70K څنګه خوندي کول

Cum să economisiți 70.000 USD Construirea unui grafic de cunoștințe pentru RAG pe 6 milioane de pagini Wikipedia

ከመይ ጌርና $70K ንቑጥብ ንRAG ዝኸውን ናይ ፍልጠት ግራፍ ኣብ 6M ዊኪፒዲያ ገጻት ንምህናጽ

Indlela yokugcina i-$ 70K yokwakha iGrafu yoLwazi lwe-RAG kwi-6M yamaphepha e-Wikipedia

How to Build a Production-Grade Text2SQL Engine

কিভাবে একটি প্রোডাকশন-গ্রেড Text2SQL ইঞ্জিন তৈরি করবেন

So erstellen Sie eine produktionsreife Text2SQL-Engine

Cómo crear un motor Text2SQL de nivel de producción

Comment créer un moteur Text2SQL de niveau production

प्रोडक्शन-ग्रेड टेक्स्ट2एसक्यूएल इंजन कैसे बनाएं

本番環境レベルの Text2SQL エンジンを構築する方法

프로덕션 등급 Text2SQL 엔진을 구축하는 방법

Como construir um mecanismo Text2SQL de nível de produção

Как создать Text2SQL-движок промышленного уровня

Üretim Seviyesinde Bir Text2SQL Motoru Nasıl Oluşturulur

Cách xây dựng một công cụ Text2SQL cấp sản xuất

如何构建生产级 Text2SQL 引擎

Building Advanced Video Search: Frame Search Versus Multi-Modal Embeddings

উন্নত ভিডিও অনুসন্ধান তৈরি করা: ফ্রেম অনুসন্ধান বনাম মাল্টি-মোডাল এম্বেডিং

Erstellen einer erweiterten Videosuche: Frame-Suche im Vergleich zu multimodalen Einbettungen

Creación de búsqueda de vídeo avanzada: búsqueda de fotogramas frente a incrustaciones multimodales

Création d'une recherche vidéo avancée : recherche de trames et intégrations multimodales

उन्नत वीडियो खोज का निर्माण: फ़्रेम खोज बनाम मल्टी-मोडल एम्बेडिंग

高度なビデオ検索の構築: フレーム検索とマルチモーダル埋め込み

고급 비디오 검색 구축: 프레임 검색과 다중 모드 임베딩 비교

Construindo pesquisa avançada de vídeo: pesquisa de quadros versus incorporações multimodais

Создание расширенного поиска видео: поиск кадров в сравнении с мультимодальными встраиваниями

Gelişmiş Video Arama Oluşturma: Çerçeve Aramaya Karşı Çok Modlu Yerleştirmeler

Xây dựng Tìm kiếm video nâng cao: Tìm kiếm khung so với nhúng đa phương thức

构建高级视频搜索：帧搜索与多模态嵌入

A lot of questions are swirling about the state of generative AI right now. How far along are companies with their bespoke GenAI efforts? Are organizations actually building AI applications using their own proprietary data in ways that move the needle? What kind of architecture is required? These questions aren’t surprising — there’s a huge range of opinions about AI out there, from unabashed optimism to jaded cynicism, mixed with a lot of hype. I’ve found that it helps to clarify the state of affairs in the GenAI marketplace across three areas: what the market wants to see, fears about what might happen, and what will happen (and how) in 2024. What Does Everyone Want — and What Are They Afraid of? GenAI exploded on the scene in late 2022 when OpenAI released ChatGPT and showed how powerful and accessible this kind of technology could be. The excitement about the potential upside of AI was everywhere. In short order, GenAI was going to be infused into every application at every enterprise. Investors envisioned a hockey-stick-like growth curve for companies that provide the infrastructure to support GenAI. The naysayers, on the other hand, envisioned a dystopian AI future that’s a cross between “Westworld” and “Black Mirror.” Others warn of an AI bubble. From an investment perspective, some say it’s like crypto all over again — lots of excitement and hype, and then a smoking crater. I think both of these fears are unfounded. Sure, with every new technology wave, there’ll be bad actors using GenAI for the wrong reasons. And the excitement about the possibilities of GenAI is everywhere; it does have a “bubbly” feel to it, and might even be more strident than the crypto buzz. But the big difference between GenAI and crypto is the fact that there are many, many real use cases for the former, across organizations and across industries. In crypto, there was one strong use case: financial transactions between untrusted parties (aka money laundering). That’s something that the mainstream isn’t quite as interested in. Right now, the state of affairs for GenAI applications reminds me of e-commerce in the late 1990s, when companies were trying to figure out how to make it safe to use credit cards over the Internet. It took a little while for organizations to figure out how to do it securely, but once they did, suddenly everyone had an e-commerce site. The parallel I see in GenAI right now: how to ensure that language models don’t return inaccurate responses by hallucinating. The good news? That’s been figured out (thanks to retrieval-augmented generation, or RAG; more on that below). Where Are We Now, and Where Are We Going? A lot of what we saw last year were proof-of-concept GenAI projects: apps to demonstrate to a company’s leadership what’s possible. But very few companies have moved beyond that to build applications that are in full production. By “production,” I mean that an organization has an AI application that is being used by customers or employees in a non-prototype way. In other words, it’s available as a routine part of activities within some segments of business operations. It might be the front office, it might be what’s behind a call to customer service, but it’s somewhere near the mainstream part of business. Walmart is a good early example of this. The retailer announced in January that it has added GenAI-powered search to its shopping app. Apple is reportedly testing a GenAI tool to help its employees provide speedier technical support. Until we start seeing more examples like this, GenAI is going to linger a little longer in the early stage of what Gartner calls the “hype cycle.” Volkswagen just announced an in-house lab to develop GenAI apps for navigation and infotainment applications for its automobiles. That said, we’re not as far from reaching the “plateau of productivity” as some might think. As I mentioned earlier, trusting models’ output has been a hurdle for organizations that are still grappling with how to produce relevant and accurate large language model (LLM) responses by reducing hallucinations. RAG, which provides models with additional data or context in real-time from other sources — most often, a database that can store vectors — is being employed now to help solve this problem. This technology advancement is a key to developing domain-specific, bespoke GenAI applications built on organizations’ most valuable asset: their own data. While RAG has emerged as the de facto method for getting enterprise context into GenAI applications, fine-tuning — when a pre-trained model is trained further on a subset of data — is often mentioned as well. There are times when this method can be useful, but RAG is the right choice if there’s any concern for privacy, security, or speed. Regardless of how context is added to the application, the big question I get often from investors I’ve been speaking with is when will companies start to make money from GenAI apps? My response: Most of the enterprises you track are consumption-based businesses. Many are now supporting the experiments, proofs of concept (POCs), and niche apps that their customers have built; those don’t do much in the way of consumption. But this is starting to change as major AI applications start to go from POC into true production. I predict this is going to happen in a significant way by the end of 2024. It will come to fruition in the second half of 2024 starting in two places. First, it’s taking hold in retail (see the Walmart example mentioned earlier). You’ll also see widespread adoption in what I call the “AI intranet” area: Chat with PDF, knowledge bases, and internal call centers. With the consumption that these kinds of apps drive, companies like Microsoft, Google, and even Oracle are starting to report results from AI. Outside of the realm of hyperscalers, other AI infrastructure companies will likely start to highlight lifts in the earnings reports they release in January, February, and March of next year. The Path to Production for GenAI Applications The groundwork has already been laid for consumption-based AI infrastructure companies. We’ve already seen strong, commercial proof points that show what’s possible for a large base of domain-specific, bespoke applications. From the creative AI apps — Midjourney, Adobe Firefly, and other image generators, for example — to knowledge apps like GitHub Copilot (over 1 million developers use it), Glean, and others, these applications have enjoyed great adoption and have driven significant productivity gains. Progress on bespoke apps is most advanced in industries and use cases that need to facilitate delivering knowledge to the point of interaction. The knowledge will come from their own data, using off-the-shelf models (either open source or proprietary), RAG, and the cloud provider of their choice. Three elements are required for enterprises to build bespoke GenAI apps that are ready for the rigors of functioning at the production scale: smart context, relevance, and scalability. Smart Context Let’s take a quick look at how proprietary data is used to generate useful, relevant, and accurate responses in GenAI applications. Applications take user input in the shape of all kinds of data and feed it all into an embedding engine, which essentially derives meaning from the data, retrieves information from a vector database using RAG, and builds the “smart context” that the LLM can use to generate a contextualized, hallucination-free response that’s presented to the user in real-time. Relevance This isn’t a topic you hear much about at operational database companies. But in the field of AI and vector databases, relevance is a mix of recall and precision that’s critical to producing useful, accurate, non-hallucinatory responses. Unlike traditional database operations, vector databases enable semantic or similarity search, which is non-deterministic in nature. Because of this, the results returned for the same query can be different depending on the context and how the search process is executed. This is where accuracy and relevance play a key role in how the vector database operates in real-world applications. Natural interaction requires that the results returned on a similarity search are accurate AND relevant to the requested query. Scalability GenAI apps that go beyond POCs and into production require high throughput. Throughput essentially is the amount of data that can be stored, accessed, or retrieved in a given amount of time. High throughput is critical to delivering real-time, interactive, data-intensive features at scale; writes often involve billions of vectors from multiple sources, and GenAI applications can generate massive amounts of requests per second. Wrapping Up As with earlier waves of technology innovation, GenAI is following an established pattern, and all signs point to it moving even faster than previous tech revolutions. If you cut through all the negative and positive hype about it, it’s clear that promising progress is being made by companies working to move their POC GenAI apps to production. And companies like my employer DataStax that provide the scalable, easy-to-build-on foundations for these apps will start seeing the benefits of their customers’ consumption sooner than some might think. By Ed Anuff, DataStax Learn more about how DataStax enables customers to get their GenAI apps to production. A lot of questions are swirling about the state of generative AI right now. How far along are companies with their bespoke GenAI efforts? Are organizations actually building AI applications using their own proprietary data in ways that move the needle? What kind of architecture is required? These questions aren’t surprising — there’s a huge range of opinions about AI out there, from unabashed optimism to jaded cynicism, mixed with a lot of hype. I’ve found that it helps to clarify the state of affairs in the GenAI marketplace across three areas: what the market wants to see, fears about what might happen, and what will happen (and how) in 2024. What Does Everyone Want — and What Are They Afraid of? GenAI exploded on the scene in late 2022 when OpenAI released ChatGPT and showed how powerful and accessible this kind of technology could be. The excitement about the potential upside of AI was everywhere. In short order, GenAI was going to be infused into every application at every enterprise. Investors envisioned a hockey-stick-like growth curve for companies that provide the infrastructure to support GenAI. The naysayers, on the other hand, envisioned a dystopian AI future that’s a cross between “Westworld” and “Black Mirror.” Others warn of an AI bubble. From an investment perspective, some say it’s like crypto all over again — lots of excitement and hype, and then a smoking crater. warn I think both of these fears are unfounded. Sure, with every new technology wave, there’ll be bad actors using GenAI for the wrong reasons. And the excitement about the possibilities of GenAI is everywhere; it does have a “bubbly” feel to it, and might even be more strident than the crypto buzz. But the big difference between GenAI and crypto is the fact that there are many, many real use cases for the former, across organizations and across industries. In crypto, there was one strong use case: financial transactions between untrusted parties (aka money laundering). That’s something that the mainstream isn’t quite as interested in. Right now, the state of affairs for GenAI applications reminds me of e-commerce in the late 1990s , when companies were trying to figure out how to make it safe to use credit cards over the Internet. It took a little while for organizations to figure out how to do it securely, but once they did, suddenly everyone had an e-commerce site. GenAI applications reminds me of e-commerce in the late 1990s The parallel I see in GenAI right now: how to ensure that language models don’t return inaccurate responses by hallucinating . The good news? That’s been figured out (thanks to retrieval-augmented generation , or RAG; more on that below). hallucinating retrieval-augmented generation Where Are We Now, and Where Are We Going? A lot of what we saw last year were proof-of-concept GenAI projects: apps to demonstrate to a company’s leadership what’s possible. But very few companies have moved beyond that to build applications that are in full production. By “production,” I mean that an organization has an AI application that is being used by customers or employees in a non-prototype way. In other words, it’s available as a routine part of activities within some segments of business operations. It might be the front office, it might be what’s behind a call to customer service, but it’s somewhere near the mainstream part of business. Walmart is a good early example of this. The retailer announced in January that it has added GenAI-powered search to its shopping app. Apple is reportedly testing a GenAI tool to help its employees provide speedier technical support. Until we start seeing more examples like this, GenAI is going to linger a little longer in the early stage of what Gartner calls the “ hype cycle .” announced in January reportedly hype cycle Volkswagen just announced an in-house lab to develop GenAI apps for navigation and infotainment applications for its automobiles. That said, we’re not as far from reaching the “plateau of productivity” as some might think. As I mentioned earlier, trusting models’ output has been a hurdle for organizations that are still grappling with how to produce relevant and accurate large language model (LLM) responses by reducing hallucinations. large language model RAG, which provides models with additional data or context in real-time from other sources — most often, a database that can store vectors — is being employed now to help solve this problem. This technology advancement is a key to developing domain-specific, bespoke GenAI applications built on organizations’ most valuable asset: their own data. While RAG has emerged as the de facto method for getting enterprise context into GenAI applications, fine-tuning — when a pre-trained model is trained further on a subset of data — is often mentioned as well. There are times when this method can be useful , but RAG is the right choice if there’s any concern for privacy, security, or speed. There are times when this method can be useful Regardless of how context is added to the application, the big question I get often from investors I’ve been speaking with is when will companies start to make money from GenAI apps? My response: Most of the enterprises you track are consumption-based businesses. Many are now supporting the experiments, proofs of concept (POCs), and niche apps that their customers have built; those don’t do much in the way of consumption. But this is starting to change as major AI applications start to go from POC into true production. I predict this is going to happen in a significant way by the end of 2024. It will come to fruition in the second half of 2024 starting in two places. First, it’s taking hold in retail (see the Walmart example mentioned earlier). You’ll also see widespread adoption in what I call the “AI intranet” area: Chat with PDF, knowledge bases, and internal call centers. With the consumption that these kinds of apps drive, companies like Microsoft , Google , and even Oracle are starting to report results from AI. Outside of the realm of hyperscalers, other AI infrastructure companies will likely start to highlight lifts in the earnings reports they release in January, February, and March of next year. Microsoft Google Oracle report results The Path to Production for GenAI Applications The groundwork has already been laid for consumption-based AI infrastructure companies. We’ve already seen strong, commercial proof points that show what’s possible for a large base of domain-specific, bespoke applications. From the creative AI apps — Midjourney, Adobe Firefly, and other image generators, for example — to knowledge apps like GitHub Copilot ( over 1 million developers use it ), Glean, and others, these applications have enjoyed great adoption and have driven significant productivity gains. over 1 million developers use it Progress on bespoke apps is most advanced in industries and use cases that need to facilitate delivering knowledge to the point of interaction. The knowledge will come from their own data, using off-the-shelf models (either open source or proprietary), RAG, and the cloud provider of their choice. Three elements are required for enterprises to build bespoke GenAI apps that are ready for the rigors of functioning at the production scale: smart context, relevance, and scalability. Smart Context Let’s take a quick look at how proprietary data is used to generate useful, relevant, and accurate responses in GenAI applications. Applications take user input in the shape of all kinds of data and feed it all into an embedding engine, which essentially derives meaning from the data, retrieves information from a vector database using RAG, and builds the “smart context” that the LLM can use to generate a contextualized, hallucination-free response that’s presented to the user in real-time. Relevance This isn’t a topic you hear much about at operational database companies. But in the field of AI and vector databases, relevance is a mix of recall and precision that’s critical to producing useful, accurate, non-hallucinatory responses. Unlike traditional database operations, vector databases enable semantic or similarity search, which is non-deterministic in nature. Because of this, the results returned for the same query can be different depending on the context and how the search process is executed. This is where accuracy and relevance play a key role in how the vector database operates in real-world applications. Natural interaction requires that the results returned on a similarity search are accurate AND relevant to the requested query. Scalability GenAI apps that go beyond POCs and into production require high throughput. Throughput essentially is the amount of data that can be stored, accessed, or retrieved in a given amount of time. High throughput is critical to delivering real-time, interactive, data-intensive features at scale; writes often involve billions of vectors from multiple sources, and GenAI applications can generate massive amounts of requests per second. Wrapping Up As with earlier waves of technology innovation, GenAI is following an established pattern, and all signs point to it moving even faster than previous tech revolutions. If you cut through all the negative and positive hype about it, it’s clear that promising progress is being made by companies working to move their POC GenAI apps to production. And companies like my employer DataStax that provide the scalable, easy-to-build-on foundations for these apps will start seeing the benefits of their customers’ consumption sooner than some might think. By Ed Anuff, DataStax By Ed Anuff, DataStax Learn more about how DataStax enables customers to get their GenAI apps to production. Learn more about how DataStax enables customers to get their GenAI apps to production . DataStax enables customers to get their GenAI apps to production

When Will Infrastructure Companies See Gains from Generative AI?

কখন অবকাঠামো কোম্পানিগুলি জেনারেটিভ এআই থেকে লাভ দেখতে পাবে?

Wann werden Infrastrukturunternehmen von generativer KI profitieren?

¿Cuándo verán las empresas de infraestructura los beneficios de la IA generativa?

Quand les entreprises d’infrastructure bénéficieront-elles de l’IA générative ?

बुनियादी ढांचा कम्पनियों को जनरेटिव एआई से लाभ कब मिलेगा?

インフラ企業はいつジェネレーティブ AI から利益を得られるのでしょうか?

인프라 회사는 언제 Generative AI로부터 이익을 얻을 수 있습니까?

Quando as empresas de infraestrutura verão os ganhos da IA generativa?

Когда инфраструктурные компании увидят выгоду от генеративного искусственного интеллекта?

Altyapı Şirketleri Üretken Yapay Zekadan Kazançları Ne Zaman Görecek?

Khi nào các công ty cơ sở hạ tầng sẽ thu được lợi nhuận từ AI sáng tạo?

基础设施公司何时能从生成式人工智能中获益？

How to Use Knowledge Graphs for Retrieval-Augmented Generation—Without a Graph DB

পুনরুদ্ধার-অগমেন্টেড জেনারেশনের জন্য জ্ঞান গ্রাফগুলি কীভাবে ব্যবহার করবেন—একটি গ্রাফ ডিবি ছাড়াই

So nutzen Sie Wissensgraphen zur abruferweiterten Generierung – ohne Graph-DB

Cómo utilizar gráficos de conocimiento para la generación de recuperación aumentada, sin una base de datos de gráficos

Comment utiliser les Knowledge Graphs pour la génération augmentée par récupération – sans base de données graphique

रिट्रीवल-ऑगमेंटेड जेनरेशन के लिए नॉलेज ग्राफ़ का उपयोग कैसे करें - बिना ग्राफ़ DB के

グラフ DB を使用せずにナレッジ グラフを検索拡張生成に使用する方法

검색 증강 생성을 위해 지식 그래프를 사용하는 방법 - 그래프 DB 없이

Como usar gráficos de conhecimento para geração aumentada de recuperação - sem um banco de dados gráfico

Как использовать графы знаний для генерации с расширенным поиском — без базы данных графов

Almayla Artırılmış Oluşturma için Bilgi Grafikleri Nasıl Kullanılır - Grafik Veritabanı Olmadan

Cách sử dụng Sơ đồ tri thức cho thế hệ tăng cường truy xuất—Không cần cơ sở dữ liệu đồ thị

如何使用知识图谱进行检索增强生成（无需图形数据库）

Stories, News & Mentions about DATASTAX

Categories

Trending Topics

Stories, News & Mentions about DATASTAX

Datastax’s Stories on HackerNoon

Datastax's News & Mentions

Categories

Trending Topics