구상

요새 LLM이다 뭐다 해서 뭐 줏어먹을거 있나 찾아보다가, 텍스트 임베딩을 활용한 검색 구현 예제을 개인 노트에 적용해보기로 맘먹었다.

개인 노트?

개인정보 이슈가 있기 때문에 이러한 개인 노트는 기존 검색 엔진이 다루지 않는 영역이었고, 일부 온라인 개인 노트(흠… 노션?)가 있긴 하지만 개인정보 문제 때문에 대부분의 유저들은 오프라인으로 구현 가능한 방법을 더 선호하는 경향이 있다. Roam, Obsidian 등의 툴들을 비교할 때 Obsidian의 장점으로 중요하게 거론되는 것 중 하나가 이것

(다만 나는 아직 저런 툴조차 쓰지 않고 그냥 텍스트 파일 하나에 모든 노트를 때려넣어서 관리하고 있지만, 어쨌든 나중에 저런 툴에도 적용할 수 있다는 원대한 망상을 하면 아무 문제 없다)

구현

사실 짜놓고 보니까 핵심 아이디어는 위에 참조된 예제에서 구현한 것과 완전 동일하다. 변주라고 해 봐야:

• 임베딩 모델이 OpenAI가 아니라 구글 LLM API를 써 봤다
• 검색 색인을 scann과 faiss-cpu를 시도해 봤으며, 최종적으로 faiss를 써서 적용해봄

임베딩 모델 선택

별다른 생각 없이 구글 클라우드에서 제공하는 API를 시도해 봤는데… 이게 개인 개발자가 쓸 물건이 아니다.

일단 5번 연속으로 부르면(시간 threshold까진 재진 않았지만 대충 10초 내에 5번 정도?) 429 throttling 에러가 나는데, 돈 내면서 호출하는 API에 이렇게 작은 제한을 걸어둘 필요가 있나? 아마 구글 고객지원에 문의하면 그냥 제한을 풀라고 하겠지만, 그럴거면 뭐하러 제한을 걸어둔 거지? 기본 제한값이 비상식적으로 작다. 너무 작다. 고작 이정도에 제한을 걸어둔 걸 보면 구글은 자기네 API 성능에 진짜 자신이 없나 하는 느낌마저 든다.

검색 색인

색인 따로 안만들고 전체 데이터에서 similarity를 계산하는 것도 데이터 크기가 작을 땐 고려해볼 만 하다. 규모가 커지면 vector database(예: Pinecone, supabase)를 고려해볼 수 있을 것 같지만, 초기 개발땐 임베딩 계산을 여러번 갈아엎을 일이 생기기 때문에…

일단 중간보고를 하자면…

(워낙 개인정보 범벅인 개인 노트라 따로 데모를 만들진 않았음)

개인 노트는 전반적인 텍스트의 퀄리티가 중구난방인데다가 고유명사의 사용이 많아서, 검색 퀄리티가 영 좋지는 않았다. 추후에 텍스트를 문장 단위로 분리해서 따로 색인에 추가한다던지 하는 시도를 더 해볼 생각.