Hacker News 의견

• 이런 시스템을 만들 때는 벡터 데이터베이스나 임베딩에 집착하지 말라는 조언을 하고 싶음
  전체 텍스트 검색이나 grep/rg 같은 도구가 훨씬 빠르고 저렴하며, 인덱스를 유지할 필요도 없음
  좋은 LLM에게 검색 도구를 주면 “dog OR canine” 같은 쿼리를 스스로 만들어내고 반복적으로 개선할 수 있음
  게다가 이렇게 하면 청킹 문제를 해결할 필요도 없어짐

  • 브라우저에서 임베딩 기반(“semantic”)과 BM25 검색의 차이를 보여주는 작은 앱을 만들었음
    Search Sensei에서 확인 가능함
    처음 로드 시 약 50MB의 모델 가중치와 onnx runtime을 다운로드하지만 이후엔 원활히 작동함
    예를 들어 BM25는 “j lo”와 “jlo”가 Jennifer Lopez를 의미한다는 걸 이해하지 못하지만, 임베딩 기반 검색은 이런 오타나 별칭을 잘 처리함
    2016~2024년 뉴스 기사 1000개를 대상으로 검색을 수행함
  • Anthropic의 contextual retrieval 연구에 따르면, 임베딩 + BM25 조합이 가장 좋은 결과를 냈다고 함
    하지만 BM25 단독 성능은 공개되지 않아 아쉬움
    내 소규모 테스트에서는 쿼리 단어가 그대로 포함된 페이지를 임베딩이 놓치는 경우가 있었음 — 결국 Ctrl+F가 이김
  • 내 경험상 semantic vs lexical 검색은 정밀도(precision)와 재현율(recall)의 트레이드오프로 이해하는 게 맞음
    Lexical 검색은 정밀도가 높지만 재현율이 낮고, semantic 검색은 그 반대 지점에 위치함
  • Google Maps에서 “billiards”를 검색했더니 수영장과 염소 관련 결과만 나오는 동의어 문제를 겪었음
    “NOT” 연산자가 더 필요하다고 느낌. RAG에 대해서도 더 배우고 싶음
  • 이런 방식으로 검색을 수행할 때 표준 프롬프트를 사용하는지 궁금함
    일부 에이전트형 도구들이 자동으로 이런 쿼리를 만들어주는 걸 봤는데, 프롬프트로 유도된 건지 기본 동작인지는 모르겠음

• 성능이 떨어지는 이유 중 하나는 semantic chunking이 부족해서일 수 있음
  문서 전체를 임베딩하면 여러 개념이 섞여 정확도가 떨어짐
  Spacy 같은 도구로 의미 단위로 나누고, 각 청크가 문서 내에서 어떤 맥락에 있는지 추가한 뒤 임베딩해야 함
  Anthropic의 contextual retrieval 접근법이 RAG 시스템에서 매우 효과적이었음
  GPT OSS 20B 모델로 문맥 생성을 하면 됨

  • 작성자 아님이지만, 우리는 이미 semantic chunking을 하고 있음
    여러 문서의 컨텍스트를 집계해야 하는 질문으로 테스트했기 때문에 오해가 있었던 듯함

• 왜 semantic 검색이 lexical 검색보다 우수하다고 전제하는지 의문임
  2023년에 Tantivy(BM25)와 비교했을 때 결과 차이는 미미했음
  약간의 재현율 향상이 있다고 해도, 그 복잡한 구조를 만들 가치가 있는지 모르겠음

  • 테스트 방식에 따라 다름
    개발자 테스트에서는 90% 재현율이었지만 실제 사용자 테스트에서는 30% 수준으로 떨어졌음
    사용자는 문서의 정확한 용어를 모르기 때문에 lexical 검색만으로는 부족했음
    에이전트를 얹을 수도 있지만, 지연(latency) 이 커져 사용자 만족도가 떨어짐
  • 앱의 성격에 따라 다름
    Wanderfugl에서는 BM25 점수가 낮은 부분도 semantic 검색이 잘 찾아줌
    결국 하이브리드 랭킹이 답일 수 있음
  • “두 과학자 간의 대화” 같은 쿼리를 처리할 수 있다는 점이 장점임
    결국 사용 사례 의존적임

• 이메일, Slack, GDrive, 코드, 위키 등 모든 데이터를 로컬 오프라인에서 질의할 수 있는 오픈소스 도구를 찾고 있음
  직접 구축하거나 커스터마이징은 피하고 싶고, 좋은 기본값과 모델 추천이 있으면 좋겠음

  • 그래서 Nextcloud MCP 서버를 만들었음
    GitHub 링크
    기본적으로 CRUD를 지원하고, 벡터 검색을 활성화하면 문서나 노트를 임베딩함
    Ollama와 OpenAI를 임베딩 제공자로 지원함
    MCP 서버는 semantic + BM25(qdrant fusion) 검색을 모두 제공하고, MCP 샘플링을 통해 응답을 생성함
    서버 자체가 답을 생성하지 않고, 어떤 LLM/MCP 클라이언트와도 연동 가능함
    이 MCP sampling/RAG 패턴은 매우 강력하며, 다른 데이터 소스에도 일반화된 오픈소스 버전이 나올 가능성이 큼

• 우리가 사용하는 도구는 haiku.rag임
  개발자 친화적인 Python 코드와 pydantic-ai 기반 구조, 벤치마크와 고급 인용 기능을 제공함
  깊은 리서치 에이전트를 지원하며, 장기적으로 유지되는 진짜 오픈소스 프로젝트임

• 기본 임베딩 모델로 Sentence Transformers (all-MiniLM-L6-v2) 를 사용 중인데, 영어 전용이라 독일어 RAG를 만들 때 문제가 될 수 있음을 깨달음
  비영어 모델의 성능이 어떤지 궁금함

  • MTEB 리더보드를 참고하면 됨
    “Retrieval” 섹션의 RTEB Multilingual 또는 RTEB German 항목을 보면 됨
    CPU 기반 셀프호스팅이라면 100M 파라미터 이하 모델로 필터링하는 게 좋음
  • 많은 모델이 비영어권 언어에서 성능 저하를 보임
    하지만 독일어는 비교적 학습 데이터가 많고, 다국어 모델도 충분히 존재함
    특히 상용 API 기반 모델들은 대부분 다국어 지원임
  • 우리도 예전에 다국어 임베딩 모델을 사용했었음
    관련 논문은 Springer 링크 참고 가능함

• GPT-4 시절(8K context)에는 책 전체를 청크로 나눠 GPT-4에 넣어 관련 구절을 검색하는 스크립트를 만들었음
  그땐 검색 한 번에 1달러 정도 들었지만, 지금은 훨씬 저렴해짐
  Anthropic의 contextual retrieval 글에서도, 문서가 컨텍스트에 다 들어간다면 RAG 대신 그냥 넣는 게 낫다고 함
  다만 컨텍스트가 길어지면 품질이 떨어지고, 비용과 속도도 문제임
  지금은 책 전체를 컨텍스트에 넣어도 1센트 수준으로 가능함

• RAG에서 가장 어려운 부분은 문서 파싱임
  텍스트만 다루면 괜찮지만, 표나 다중 페이지 표, 차트, 목차, 각주 등이 있으면 정확도가 급격히 떨어짐
  이를 개선하기 위해 RAPTOR 패턴처럼 LLM이 내용을 요약·질문하며 벡터 DB에 저장하는 접근이 있음
  하지만 모든 경우에 통하는 범용 RAG 파이프라인은 여전히 어려운 과제임

  • 벡터 임베딩 초보로서, 표가 그렇게 복잡한 문제를 만든다는 걸 몰랐음
    벡터 DB가 긴 텍스트 그룹과 표 형식 중 어느 쪽을 더 잘 처리하는지도 궁금함

• 전체 텍스트 검색을 RAG에 적용한 새로운 관점이 흥미로웠음
  에이전트형 도구 루프와 퍼지 검색(fuzzy search) 처리 방식에 대한 통찰이 인상적이었음

• 이런 시스템의 평가용 데이터셋이 표준화되어 있는지 궁금함
  문서와 질문 세트가 있어 특정 문서나 청크가 가장 관련성 높은 결과로 나와야 하는 식의 벤치마크가 있으면 좋겠음

  • 그런 용도로 haiku-rag 벤치마크와 평가 세트를 참고하면 됨