krzysztof/landing_page
1
0
Fork 0
mirror of https://github.com/qdrant/landing_page.git synced 2026-10-05 10:58:32 +02:00
Code Issues Packages Projects Releases Wiki Activity

Update case-study-kakao.md

Browse Source
This commit is contained in:
daniel-azoulai
2026-01-27 09:56:22 -08:00
parent e26d9df5c9
commit cb19c07abc
1 changed files with 22 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files
qdrant-landing/content/blog/case-study-kakao.md
+22 -25
View File
@@ -18,17 +18,13 @@ tags:
- case study
---
# Qdrant Case Study: Kakao Connectivity Platform
​​Kakao is one of South Korea's leading technology companies, best known for KakaoTalk, the country's dominant messaging platform with over 48 million monthly active users. Beyond messaging, Kakao operates a broad ecosystem of services including maps, mobility, fintech, and enterprise solutions.
Kakao builds an AI-powered internal Service Desk with Qdrant**
### Helping employees find answers faster without sacrificing precision or control
​​Kakao is one of South Korea's leading technology companies, best known for KakaoTalk—the country's dominant messaging platform with over 48 million monthly active users. Beyond messaging, Kakao operates a broad ecosystem of services including maps, mobility, fintech, and enterprise solutions.
Kakao’s Connectivity Platform team set out to solve a familiar internal problem: employees across the organization needed a faster, more reliable way to get answers about internal systems, APIs, and operational procedures. The result was **Service Desk Agent**, an AI-powered internal service desk designed to answer questions in natural language using Kakao’s internal documentation and historical inquiry data.
### Helping employees find answers faster—without sacrificing precision or control
Kakao’s Connectivity Platform team set out to solve a familiar internal problem: employees across the organization needed a faster, more reliable way to get answers about internal systems, APIs, and operational procedures. The result was **Service Desk Agent**, an AI-powered internal service desk designed to answer questions in natural language using Kakao’s internal documentation and historical inquiry data .
Built as a Retrieval-Augmented Generation (RAG) system on top of LangGraph, Service Desk Agent acts as a conversational interface to Kakao’s internal knowledge—helping employees resolve issues quickly, while reducing repetitive work for support staff.
Built as a Retrieval-Augmented Generation (RAG) system on top of LangGraph, Service Desk Agent acts as a conversational interface to Kakao’s internal knowledge. This helps employees resolve issues quickly, while reducing repetitive work for support staff.
## The challenge: searching complex internal knowledge at scale
@@ -36,14 +32,14 @@ From the beginning, the team faced a search problem that couldn’t be solved wi
Service Desk Agent needed to work across two very different types of data:
* Long-form technical documentation, including project guides and API specifications, where understanding context matters—but exact system names and proper nouns still need to be matched.
* Long-form technical documentation, including project guides and API specifications, where understanding context matters. But, exact system names and proper nouns still need to be matched.
* Historical Q\&A and incident data, which often includes precise error messages, commands, and configuration details.
Pure keyword search struggled with conceptual questions. Pure vector search struggled with exact terms and proper nouns. Neither approach alone was sufficient .
Pure keyword search struggled with conceptual questions. Pure vector search struggled with exact terms and proper nouns. Neither approach alone was sufficient.
At the same time, Kakao had strict infrastructure and operational requirements. All data needed to remain within internal infrastructure, the system had to be deployable on Kubernetes, and the solution needed a permissive open-source license with strong official documentation for operations like upgrades, backup, and recovery .
At the same time, Kakao had strict infrastructure and operational requirements. All data needed to remain within internal infrastructure, the system had to be deployable on Kubernetes, and the solution needed a permissive open-source license with strong official documentation for operations like upgrades, backup, and recovery.
This was a greenfield project—Kakao wasn’t replacing an existing vector database. Instead, the team evaluated several options, including Milvus, Weaviate, Qdrant, and Elasticsearch, to determine the best foundation for RAG-based internal AI services .
This was a greenfield project; Kakao wasn’t replacing an existing vector database. Instead, the team evaluated several options, including Milvus, Weaviate, Qdrant, and Elasticsearch, to determine the best foundation for RAG-based internal AI services.
## Why Kakao chose Qdrant
@@ -51,37 +47,38 @@ After evaluating multiple vector databases, the Connectivity Platform team selec
The decision came down to a combination of search quality, performance, and operational fit.
Qdrant’s hybrid search capabilities were a key factor. By supporting both dense vectors for semantic search and sparse vectors for keyword-based retrieval—combined using Reciprocal Rank Fusion (RRF)—the team could address both conceptual questions and exact-match queries in a single system. Named Vectors made it possible to manage multiple vector types within the same collection .
Qdrant’s hybrid search capabilities were a key factor. By supporting both dense vectors for semantic search and sparse vectors for keyword-based retrieval—combined using [Reciprocal Rank Fusion (RRF)](https://qdrant.tech/documentation/concepts/hybrid-queries/#reciprocal-rank-fusion-rrf), the team could address both conceptual questions and exact-match queries in a single system. Named Vectors made it possible to manage multiple vector types within the same collection.
Performance was another major consideration. Qdrant’s Rust-based architecture, efficient HNSW implementation, and support for scalar quantization (INT8) provided low-latency search while optimizing memory usage—important for an internal service expected to scale over time .
Performance was another major consideration. Qdrant’s [Rust-based architecture](https://qdrant.tech/articles/why-rust/), efficient [HNSW implementation](https://qdrant.tech/course/essentials/day-2/what-is-hnsw/), and support for [scalar quantization (INT8)](https://qdrant.tech/documentation/guides/quantization/#scalar-quantization) provided low-latency search while optimizing memory usage. This was crucial for an internal service expected to scale over time.
From an operational standpoint, Qdrant fit naturally into Kakao’s environment. Its single-binary design simplified deployment, it ran reliably on Kubernetes, and it allowed Kakao to retain full control over data by self-hosting within internal infrastructure .
From an operational standpoint, Qdrant fit naturally into Kakao’s environment. Its single-binary design simplified deployment, it ran reliably on Kubernetes, and it allowed Kakao to retain full control over data by self-hosting within internal infrastructure.
Finally, the team highlighted the developer experience: a well-designed Python SDK with async support, an intuitive Web UI for debugging and exploration, and detailed official documentation covering both usage and performance tuning .
Finally, the team highlighted the developer experience: a well-designed Python SDK with async support, an intuitive Web UI for debugging and exploration, and detailed official documentation covering both usage and performance tuning.
## How Service Desk Agent uses Qdrant
Qdrant sits at the core of Service Desk Agent’s RAG architecture, acting as the system’s primary vector store.
The team integrated Qdrant using the asynchronous Python client (`AsyncQdrantClient`) to handle high query concurrency, with secure HTTPS communication for all data access .
The team integrated Qdrant using the asynchronous Python client (`AsyncQdrantClient`) to handle high query concurrency, with secure HTTPS communication for all data access.
Collections were designed around data sources, with separate collections for internal technical documentation, historical inquiry data, and a semantic cache used to speed up repeated queries. Metadata filtering allows the system to narrow search scope by service or time period, while maintaining fast response times .
Collections were designed around data sources, with separate collections for internal technical documentation, historical inquiry data, and a semantic cache used to speed up repeated queries. Metadata filtering allows the system to narrow search scope by service or time period, while maintaining fast response times.
Each collection stores both dense and sparse vectors using Named Vectors. Hybrid search results are merged using RRF to produce more accurate answers across different query types .
Each collection stores both dense and sparse vectors using [Named Vectors](https://qdrant.tech/documentation/concepts/vectors/#named-vectors). Hybrid search results are merged using RRF to produce more accurate answers across different query types.
An automated indexing pipeline handles document ingestion end-to-end—from cleansing and chunking, to embedding generation, to batch upserts into Qdrant.
An automated indexing pipeline handles document ingestion end-to-end. This ranges from cleansing and chunking, to embedding generation, to batch upserts into Qdrant.
The entire system runs on Kakao’s internal Kubernetes cluster, using a replication-based Qdrant setup for high availability and rolling updates for zero-downtime deployments. The system integrates with distributed locking and state management solutions within the broader application architecture.
![indexing-pipeline][/blog/case-study-kakao/indexing-pipeline.png]
![search-pipeline][/blog/case-study-kakao/indexing-pipeline.png]
![indexing-pipeline](/blog/case-study-kakao/indexing-pipeline.png)
![search-pipeline](/blog/case-study-kakao/indexing-pipeline.png)
## The result: faster answers, lower support load
Today, Service Desk Agent supports approximately 1 million vectors, with the dataset continuing to grow as more internal knowledge is indexed. The system operates across multiple collections and uses 3072-dimensional embeddings from OpenAI’s model .
Today, Service Desk Agent supports approximately 1 million vectors, with the dataset continuing to grow as more internal knowledge is indexed. The system operates across multiple collections and uses 3072-dimensional embeddings from OpenAI’s model.
By combining hybrid search, metadata filtering, and semantic caching, the team was able to improve both search quality and response times. Scalar quantization reduced memory usage, while tuned HNSW parameters helped maintain low latency under load .
By combining hybrid search, metadata filtering, and semantic caching, the team was able to improve both search quality and response times. Scalar quantization reduced memory usage, while tuned HNSW parameters helped maintain low latency under load.
From a business perspective, the impact has been clear:
@@ -93,6 +90,6 @@ Before Service Desk Agent, employees searched across multiple internal knowledge
## What’s next
Kakao plans to continue expanding Service Desk Agent by indexing more of its internal knowledge base. The team is also exploring deeper GraphRAG integration, potential multimodal search capabilities, and sharding strategies to support future scale and performance needs .
Kakao plans to continue expanding Service Desk Agent by indexing more of its internal knowledge base. The team is also exploring deeper GraphRAG integration, potential multimodal search capabilities, and sharding strategies to support future scale and performance needs.
Within the Connectivity Platform team, Qdrant has become the foundation for RAG-based internal AI services—providing the hybrid search, flexibility, and operational stability required to support AI-driven knowledge access at scale.