본문 바로가기

AI - 검색의 여정/Step 2 - 찾기

🔤 키워드 검색(어휘 검색): 후보군을 만드는 가장 단단한 방법

신뢰할 수 있는 1차 후보군을 만드는 강력한 기반

 

키워드 검색은

토큰화 / 정규화 이후의 단어(term) 매칭을 기반으로

관련 문서 후보군을 빠르게 만들고,

 

최신 AI 검색 시스템에서도 1차 후보 생성(sparse retrieval) 역할로 여전히 널리 쓰입니다.


🧭 전체 AI 검색 시스템에서의 위치

하나의 구성 요소를 제대로 이해하려면

먼저 전체 시스템의 지도를 펼쳐봐야 합니다.

 

키워드 검색은 AI 기반 검색 파이프라인의 특정 단계에 위치하며,

그 역할을 이해하기 위해 전체 구조를 살펴보겠습니다.

 

AI 기반 검색 시스템은 크게 네 가지 단계로 구성됩니다.

 

각 단계는 유기적으로 연결되어 사용자의 정보 요구를 최종적인 답변으로 완성합니다.

  • 준비 (Preparation): 🧩청킹 → 🏷️메타데이터 → 🧠임베딩
    • 문서를 검색 단위(청킹)로 분할하고, 속성 정보(메타데이터)를 부여한 뒤, 의미 벡터(임베딩)로 변환합니다.
  • 찾기 (Finding): 🔤키워드 검색 + 🔎의미 검색 → ⚖️결합 → 🎯리랭킹
    • 키워드/의미 검색으로 후보군을 탐색하고, 결과를 결합하여 최종 순위를 재정렬합니다.
  • 답하기 (Answering): 🍱컨텍스트 포장 → ✍️생성
    • 상위 문서를 근거로 컨텍스트를 구성하여 대규모 언어 모델(LLM)이 답변을 생성합니다.
  • 개선 (Improvement): 🧪평가/개선
    • 시스템 성능을 지속적으로 측정 및 분석하여 모든 단계를 개선합니다.

데이터를 검색에 적합한 형태로 가공하는 ‘준비’ 단계를 마쳤으니,

이제 본격적으로 사용자의 질의에 맞는 문서를 찾는 ‘찾기’ 단계로 들어갑니다.

 

그 첫 관문이 바로 키워드 검색을 통해 넓은 후보 문서 집합을 빠르게 만들기입니다.


🔤 키워드 검색의 역할: 후보군 식별

초기 정보 검색 시스템은

질의어 포함 여부만을 따져

문서 집합을 반환하는 불리언 검색(Boolean retrieval) 모델에 의존했습니다.

 

 

하지만 단순히 문서를 찾기만 하는 것을 넘어

“어떤 문서가 더 관련 있는가”를 판단하는 것이 중요해지면서,

문서를 **점수화**하고 순서를 매기는 **순위 검색(ranked retrieval)** 패러다임으로 발전했습니다.

 

키워드 검색의 핵심 역할은

**"질의어가 (분석 이후의) 용어(term)로서 일치하는 문서 후보군을 만든다"**는 것이며,

이는 다음과 같은 기능으로 나타납니다.

  • 효율적인 문서 탐색:
       모든 문서를 순차적으로 훑지 않고,
       인덱스를 통해 특정 용어가 포함된 문서를 빠르게 찾습니다.
  • 순위 기반 검색의 토대:
       불리언 검색에서는 교집합으로 “대상을 고르고”,
       순위 검색에서는 이렇게 모인 후보에 점수를 매겨 "먼저 보여줄 순서"를 정합니다.
  • 특수 용어 검색 지원:
       제품 코드, 식별자, 고유명사처럼 정확한 일치가 중요한 질의에 강합니다.
  • 정밀한 제어 기능:
       특정 구문이 정확히 일치해야 한다는 조건(예: "Seoul University"),
       연산자 활용 등으로 결과를 정밀하게 제어할 수 있습니다.

이러한 특징 때문에 키워드 검색은 AI 시대에도 여전히 중요합니다.

 

특히 고유명사, 기술 용어, 제품 코드처럼

의미 해석보다 ‘정확한 형태’가 중요한 경우 그 가치가 빛을 발합니다.

 

또한 사용자가 짧고 명확한 키워드로 검색할 때,

시스템이 "그 단어가 들어간 문서를 보여줄 것"이라는 기대에

가장 확실하게 부응하는 방식이기도 합니다.

 

결국 키워드 검색은 더 복잡한 의미 기반 랭킹을 적용하기 전에,

신뢰할 수 있는 1차 후보군을 만드는 강력한 기반입니다.

 

이제 키워드 검색의 속도와 정확성을 가능하게 하는 핵심 부품들을 하나씩 분해해 보겠습니다.


⚙️ 키워드 검색의 핵심 부품 3가지

키워드 검색의 속도와 관련성은 마법이 아니라,

**토큰화(Tokenization), 역색인(Inverted Index), 점수화(Scoring)**라는

세 가지 핵심 개념이 맞물려 작동한 결과입니다.

1. 토큰화(Tokenization)와 정규화(Normalization)

토큰화 문서나 질의어 같은 텍스트토큰(token) 또는 용어(term) 라는
개별 색인 단위로 분해하는 과정입니다.

정규화는 이렇게 분리된 토큰들을 일관된 형태로 맞춰(예: 대소문자 통일, 표기 통일)
안정적인 매칭을 가능하게 합니다.

 

청킹(Chunking) 토큰화(Tokenization)의 차이

 

청킹은 문서를 검색 단위인 **패시지(passage)/청크(chunk)**로 나누는 것이고,

토큰화는 이 패시지 텍스트를 검색용 색인 단위인 **용어(term)**로 나누는 것입니다.

 

둘은 서로 다른 레벨의 작업입니다.


2. 역색인(Inverted Index)

역색인은 키워드 검색 속도의 비밀입니다.

일반적인 방식처럼 '문서 → 포함 단어'를 찾는 대신,
역색인은 '단어 → 포함 문서 목록(postings list)'으로
바로 이동할 수 있게 구조를 뒤집어 둡니다.

예를 들어 Brutus AND Caesar 같은 질의를 처리할 때, 시스템은 모든 문서를 뒤지지 않습니다.
역색인에서 'Brutus'의 문서 목록과 'Caesar'의 문서 목록을 가져와
교집합을 계산해 조건을 만족하는 문서를 빠르게 찾아냅니다.

그리고 **순위 검색(ranked retrieval)**에서는 이렇게 모인 후보들에 대해 점수를 계산해 최종 순서를 정합니다.

 


3. 점수(BM25) 감각

여러 문서가 동일한 키워드를 포함할 때,
어떤 문서를 먼저 보여줄지 결정하려면 점수화(scoring)가 필요합니다.

BM25는 수십 년간 널리 쓰인 대표 점수화 함수로,
단순 포함 여부를 넘어 더 정교한 기준으로 순위를 매깁니다.

 

BM25는 주로 다음 요소를 고려합니다.

  1. 용어 빈도(TF): 특정 단어가 한 문서에서 얼마나 자주 등장하는가
  2. 역문서 빈도(IDF): 그 단어가 전체 문서에서 얼마나 희귀한가(희귀할수록 더 중요하게 봄)
  3. 문서 길이 정규화: 문서가 너무 길어서 점수가 과도하게 유리해지지 않도록 조정

이 모델에는 k1, b 같은 조정 파라미터가 있지만, 수학 공식 자체를 외울 필요는 없습니다.

 

핵심은 BM25가 "더 관련 있을 가능성이 높은 문서를 위로 올리는" 일관된 기준을 제공한다는 점입니다.

핵심 부품을 이해했다면, 이제 이를 효과적으로 활용하기 위한 실전 감각을 익힐 차례입니다.


🧠 실전 감각 4가지

핵심 부품의 원리를 아는 것과

이를 능숙하게 다루는 것은 별개의 문제입니다.

 

키워드 검색을 튜닝하기 위해서는 다음 4가지 감각이 중요합니다.

1. 필드 가중치 (Field Weighting)

문서의 모든 부분이 동일한 중요도를 갖지는 않습니다.
예를 들어 본문보다 제목에 키워드가 등장하는 것이 더 중요할 수 있습니다.
필드 가중치는 특정 필드에 더 높은 중요도를 부여해 검색 관련도를 높이는 기법입니다.

2. 구문 검색 (Phrase Search)

Stanford AND University는 두 단어가 모두 있는 문서를 찾지만,
"Stanford University"는 순서와 붙어 있는 형태까지 요구합니다.
고유명사 / 전문 용어 / 정확한 표현을 다룰 때 구문 검색은 정확도를 크게 올립니다.

3. 동의어/오타 처리 (Synonyms/Typos)

동의어 확장이나 오타 보정은 사용자의 편의를 높일 수 있습니다.
  • 효과: 더 많은 관련 문서를 찾을 수 있어 **재현율(Recall)**이 올라갑니다.
  • 리스크: 다의어/동음이의어에서 의도치 않게 확장되어 **정확도(Precision)**가 떨어질 수 있습니다.
                 예: java(언어 vs 커피), apple(회사 vs 과일), spring(계절 vs 프레임워크)

4. 점수 디버깅 (Explain)

"왜 이 문서가 1위인가?"를 설명할 수 있어야 품질을 개선할 수 있습니다.
점수 디버깅은 문서 점수가 어떤 요소(예: TF / IDF / 필드 가중치 등)로 구성되었는지 해부해
문제를 진단하고 튜닝하는 과정입니다.

❓ 자주 생기는 오해 3가지 + ✅ 바로잡기

  • "키워드 검색은 옛날 방식이라 AI 검색에 필요 없다?"
    ✅ 아닙니다.

    고유명사, 제품 코드, 법률 조문, 정확한 구문처럼 정확 매칭이 중요한 영역에서는
    키워드 검색이 여전히 독보적으로 강합니다.

    현대 시스템에서도 1차 후보를 만드는 강한 신호로 활용됩니다.

  • "검색 점수는 절대적인 정답이다?"
    ✅ 아닙니다.

    점수는 "관련성이 더 높을 가능성이 큰 문서를 먼저 보여주기 위한 상대적 순위 계산값"입니다.

    절대적인 품질 점수라기보다
    정렬을 위한 도구에 가깝습니다.

  • "동의어를 많이 넣을수록 무조건 좋아진다?"
    ✅ 아닙니다.

    동의어 확장은 재현율을 올릴 수 있지만,
    의도치 않은 확장으로 정확도를 떨어뜨릴 수도 있습니다.

    결국 정확도 - 재현율 트레이드오프를 관리하는 정책 문제가 됩니다.

✅ 체크리스트: 키워드 검색 품질 개선을 위한 7가지 점검 항목

  1. 토큰화 기준 점검: 용어(term) 분리가 문서 언어/형식(코드, 식별자 등)에 적합한가?
  2. 불용어/정규화 정책 검토: 중요한 단어가 제거되거나 왜곡되지 않는가?
  3. 필드 설계 및 가중치 조정: 제목/요약/본문 등 구조가 적절하고 가중치가 합리적인가?
  4. 구문 검색 필요성 판단: 다단어 표현이 많은 도메인인가?
  5. 동의어 정책 수립: 어디까지 확장할지, 예외는 무엇인지 기준이 있는가?
  6. 오타 처리 정책 수립: 적극 보정 vs 보수적 제안 중 어느 쪽인가?
  7. Explain을 통한 검증: 상위 문서가 왜 상위인지 정기적으로 분석하는가?

 

정확한 단어(term)로 후보군을 빠르게 만드는 기본기

 

하지만 ‘찾기’ 단계는 여기서 끝나지 않습니다.
같은 질문이라도 문서에 그 단어가 정확히 없을 수 있기 때문입니다.

 

다음 편에서는 준비 챕터에서 만든 **🧠 임베딩**을 이용해

질문과 의미가 가까운 청크를 찾는 **🔎 의미 검색**을 다룹니다.

 

그리고 그 다음 단계에서야 비로소,

🔤키워드 검색이 만든 후보군🔎의미 검색이 만든 후보군

한쪽으로 치우치지 않게 공정하게 합치는

결합(⚖️) 즉, 하이브리드 검색의 핵심으로 넘어갈 수 있습니다.


요약의 레퍼런스: 

https://nlp.stanford.edu/IR-book/pdf/irbookonlinereading.pdf
https://nlp.stanford.edu/IR-book/pdf/02voc.pdf
https://www.staff.city.ac.uk/~sbrp622/papers/foundations_bm25_review.pdf

 

https://lucene.apache.org/core/3_5_0/scoring.html
https://lucene.apache.org/core/2_9_4/queryparsersyntax.html
https://docs.opensearch.org/latest/search-plugins/keyword-search/

 

Apache Lucene - Scoring

Apache Lucene - Scoring Introduction Lucene scoring is the heart of why we all love Lucene. It is blazingly fast and it hides almost all of the complexity from the user. In a nutshell, it works. At least, that is, until it doesn't work, or doesn't work as

lucene.apache.org

 

Apache Lucene - Query Parser Syntax

Apache Lucene - Query Parser Syntax Overview Although Lucene provides the ability to create your own queries through its API, it also provides a rich query language through the Query Parser, a lexer which interprets a string into a Lucene Query using JavaC

lucene.apache.org

 

Keyword search

Keyword search

docs.opensearch.org

 

 


https://docs.weaviate.io/weaviate/search/bm25
https://github.com/castorini/pyserini
https://javadoc.io/doc/org.apache.lucene/lucene-core/6.6.4/org/apache/lucene/search/similarities/BM25Similarity.html
https://docs.opensearch.org/latest/api-reference/search-apis/explain/
https://web.stanford.edu/class/cs276/19handouts/lecture3-indexconstruction-6per.pdf
https://ucilnica.fri.uni-lj.si/pluginfile.php/135779/mod_folder/content/0/NLP-02-Text%20preprocessing.pdf?forcedownload=1

 

Keyword search | Weaviate Documentation

Weaviate BM25 keyword search documentation covering basic queries, search operators, scoring, property targeting, weighting, tokenization, filtering and fuzzy matching.

docs.weaviate.io

 

BM25Similarity - lucene-core 6.6.4 javadoc

Latest version of org.apache.lucene:lucene-core https://javadoc.io/doc/org.apache.lucene/lucene-core Current version 6.6.4 https://javadoc.io/doc/org.apache.lucene/lucene-core/6.6.4 package-list path (used for javadoc generation -link option) https://javad

javadoc.io

 

 

Explain

Explain API Introduced 1.0

docs.opensearch.org


해당 글은 AI 어시스턴트로 작성되었습니다.

NotebookLM과 Chat GPT를 사용하여 작성되었습니다.