질의: "Industrial Designer는 회의가 브레인스토밍에 우호적이지 않다고 생각했다. 제약은 분위기가 아니라 실제 환경과 제한된 논의 시간에 관한 것이었다. 게다가 상호작용이 구조화되어 각자 한 가지 과제만 맡고 충분한 협업이 없었다. 이메일을 통한 소통도 비효율적이었다." 골드 문서 내 국소 근거: "the meetings ... are mo
Dense retrieval에서 임베딩 차원을 늘리면 성능이 좋아진다는 건 거의 상식처럼 통용된다. Qwen-Embedding-8B는 4096차원, OpenAI text-embedding-3-large는 3072차원을 쓴다. 그런데 이 고차원 벡터의 모든 좌표가 검색에 도움이 될까? 이 논문의 출발점은 "그렇지 않다"는 관찰이다. 특정 질의(query)에
RAG, 검색, 추천, 분류 - 요즘 실무에서 쓰이는 머신러닝 파이프라인의 상당수가 텍스트를 밀집 벡터(dense embedding)로 바꾸는 임베딩 모델에 기대고 있다. 그런데 하나의 임베딩 모델이 이 모든 작업을 동시에 잘하기란 쉽지 않다. 문제의 뿌리는 작업마다 "가깝다"의 정의가 다르다는 데 있다.
RAG 시스템을 실제로 운영해 본 사람이라면 임베딩 모델의 크기가 얼마나 골치 아픈 변수인지 안다. 검색 품질을 올리려면 파라미터를 키우는 게 가장 확실한 방법인데, 그 순간 두 가지 비용이 동시에 튄다. 하나는 코퍼스 전체를 색인할 때 드는 메모리와 스토리지, 다른 하나는 쿼리마다 발생하는 추론 지연(latency)이다. 특히 다국어 검색으로 넘어가면 상
RAG와 시맨틱 검색이 실서비스에 들어오면서 텍스트 임베딩 모델은 조용히 인프라의 핵심이 됐다. 문제는 성능을 끌어올리려고 모델을 키우다 보니, 검색 파이프라인 전체의 비용과 지연시간이 임베딩 인코딩에서 결정되는 상황이 자주 생긴다는 점이다. 특히 정보 검색(IR, Information Retrieval)에서는 문서와 쿼리를 같은 모델로 인코딩하는 게 당연
Mamba2·RWKV·xLSTM 같은 순환(recurrent) 언어 모델을 텍스트 임베더로 파인튜닝하고, 레이어 방향으로 시퀀스를 잘라 처리하는 "수직 청킹(vertical chunking)" 추론 전략을 도입해 입력 길이와 무관하게 메모리가 상수로 수렴하는 임베딩 모델을 만든 연구.