TiDB의 하이브리드 검색을 포켓몬 파티 구성으로 테스트해 보기

계기

ZennFes Spring 2026을 보고 "TiDB로 무언가 만들 수 없을까"라고 생각한 것이 계기입니다. 조사해 보니 TiDB의 강점은 SQL · 전문 검색 (Full-text Search) · 벡터 검색 (Vector Search)을 하나의 데이터베이스에서 통합하여 다룰 수 있다는 점이었습니다. 보통은 RDB · 전문 검색 엔진 · 벡터 DB를 각각 구축해야 하지만, 동일한 테이블의 1개 쿼리로 해결할 수 있습니다. 이 **하이브리드 검색 (Hybrid Search)**을 테스트해 보고 싶어 소재를 찾다가 **포켓몬 (Pokemon)**을 선택했습니다.

포켓몬은 타입 · 종족값 · 특성이라는 구조화된 데이터와, "방어형에 강한 물리 어태커"와 같은 모호한 역할(자연어)이 공존합니다. 하이브리드 검색의 장점이 잘 드러나며, PokeAPI를 통해 누구나 재현할 수 있다는 점도 선택한 이유입니다.

만들고 있는 것은 자연어 요구사항으로부터 후보를 좁혀 파티를 구성하는 간단한 도구입니다.

왜 하이브리드 검색인가

예를 들어 "불꽃 타입이면서, 방어형에 강한 물리 어태커"라는 요구사항은 성격이 다른 조건들이 섞여 있습니다.

엄격한 조건 (타입 · 종족값) → SQL · 전문 검색이 특기
모호한 의미 (역할 · 플레이 스타일) → 벡터 검색이 특기

벡터 검색만 사용하면 의미는 비슷해도 "불꽃 타입"과 같은 엄격한 조건을 놓치기 쉽습니다 (예: 노말이나 물 타입의 내구형이 상위에 올라옴). 반대로 SQL이나 키워드만 사용하면, "방어형에 강한"을 "내구형"으로 바꾸기만 해도 검색되지 않습니다. TiDB라면 이를 1개의 쿼리로 수행할 수 있습니다.

스키마

하나의 테이블에 구조화된 열 · 전문 검색용 열 · 벡터 열을 공존시킵니다. ORM은 pytidb를 사용하며, 임베딩 (Embedding)은 자동 생성에 맡깁니다.

class Pokemon(TableModel, table=True):
id: int = Field(primary_key=True)
name_ja: str
...

여기서 은근히 효과적이었던 것은 무엇을 임베딩할 것인가였습니다. 종족값을 그대로 나열하는 것보다, 역할을 설명하는 문장으로 만들어 임베딩하는 것이 모호한 요구사항과 더 잘 맞았습니다.

하이브리드 검색

검색 본체는 pytidb의 메서드 체이닝 (Method Chaining)으로 작성합니다.

hits = (
table.search(query, search_type="hybrid")
.filter({"$or": [{"type1": "ほのお"}, {"type2": "ほのお"}],
...

fusion은 벡터와 전문 검색의 스코어 (Score)를 가중치를 두어 합성합니다. vs_weight를 높이면 의미 중심, fts_weight를 높이면 키워드 중심이 됩니다. prefilter의 구조화된 필터가 "불꽃 타입 제한"과 같은 필수 조건을 먼저 보장해 줍니다.

파티 생성

좁혀진 후보를 LLM에 전달하여 파티를 구성하게 합니다. 후보 리스트 안에서만 선택하게 함으로써, 존재하지 않는 포켓몬이 나오는 것을 방지합니다. 검색(TiDB)이 후보를 내놓고, LLM은 순서 정하기와 설명에 전념하는 분업 구조입니다.

요약

TiDB의 하이브리드 검색을 테스트할 소재로서 포켓몬은 궁합이 좋아 보였습니다. SQL 필터 · 전문 검색 · 벡터를 하나의 테이블 · 하나의 쿼리로 다룰 수 있으므로, 검색 기반을 늘리지 않고도 RAG적인 메커니즘을 구축할 수 있습니다.

mem0를 추가하여 사용자의 소지 포켓몬이나 취향을 기억하는 단계까지 확장해 나간다면 더욱 재미있을 것 같습니다.

참고 링크

Discussion