오픈 소스 분산 전자책 검색 엔진 구축

 (github.com/j2qk3b)
1P by GN⁺ | ★ favorite | 댓글 1개

오픈소스 분산 전자책 검색 엔진 구축하기

  • 친구의 추천으로 ENS 도메인 이름을 사용하는 Liber3라는 전자책 검색 웹사이트를 알게 됨.
  • Liber3는 ENS와 IPFS를 이용해 전자책 검색 웹사이트를 만들었으나 소스 코드를 공개하지 않음.
  • Glitter의 문서와 데이터셋을 검토한 후, 오픈소스 커뮤니티 버전을 직접 구현하기로 결정함.

프로젝트 초기화

  • 새 프로젝트를 생성하고 Glitter SDK를 설치하여 Glitter 네트워크에 쉽게 연결하고 전자책의 메타데이터를 얻을 수 있음.

네트워크 연결

  • Glitter 네트워크와 상호작용할 수 있는 클라이언트를 생성함.
  • Glitter SDK를 통해 LCDClient 인스턴스를 초기화하고 관련 매개변수를 설정함.

검색 기능 구축

  • 사용자의 쿼리 키워드를 받아 쿼리 문을 구성하고 Glitter 네트워크로 보내는 검색 기능을 정의함.

검색 결과 표시

  • 검색 기능을 구축한 후, 전자책의 기본 정보를 보여주는 인터페이스를 디자인하고 사용자가 책을 쉽게 탐색하고 선택할 수 있는 인터랙티브 요소를 제공함.
  • 이 네 단계를 통해 전자책 검색 엔진을 구축할 수 있으며, 사용자에게 전자책 자원을 검색하는 효율적이고 편리한 플랫폼을 제공함.
  • 컴파일된 웹사이트 버전을 IPFS 네트워크에 게시하면 IPFS 게이트웨이를 통해 접근할 수 있는 분산 전자책 검색 엔진을 가질 수 있음.
  • 전체 소스 코드는 이 저장소에서 확인할 수 있음.

GN⁺의 의견

  • 이 기사는 오픈소스와 분산 기술을 활용하여 전자책 검색 엔진을 구축하는 방법을 설명함으로써, 기술에 관심 있는 사람들에게 흥미를 줄 수 있음.
  • 분산 데이터베이스와 IPFS를 사용하는 것은 중앙 집중식 서버에 의존하지 않고 데이터를 저장하고 검색하는 새로운 방법을 제시함으로써, 데이터의 영속성과 접근성을 향상시킬 수 있는 잠재력을 가짐.
  • 이 기술을 도입할 때는 네트워크의 안정성, 검색 속도, 사용자 경험 등을 고려해야 하며, 기존의 중앙 집중식 검색 엔진과 비교했을 때의 장단점을 이해하는 것이 중요함.
  • 비슷한 기능을 제공하는 다른 프로젝트로는 Project Gutenberg나 Google Books API가 있으나, 이들은 분산 기술을 사용하지 않음.
  • 분산 기술을 사용함으로써 데이터의 소유권과 통제를 사용자에게 돌려주는 동시에, 콘텐츠의 검열 저항성을 강화할 수 있음.

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 오래전에 IPFS 위에서 AI 데이터셋과 모델을 비슷하게 다뤄보고 싶었음
    IPFS의 미래는 모르겠지만, 대규모 데이터셋을 다룰 때 개인이 적은 하드웨어로도 문제를 해결할 수 있게 해주는 P2P 데이터 공유 인프라의 핵심이 더 접근 쉬워지면 좋겠음
    https://github.com/JakeKalstad/IPFSPytorchDataset
    https://github.com/JakeKalstad/load_ipfs_pytorch_model

  • 제목을 보고 전문 검색을 하는 줄 알고 정말 기대했음
    Zlib와 Google Books는 이미 하고 있지만, 모두가 기여할 수 있고 전문 접근까지 제공하는 오픈소스 버전이 있으면 멋진 프로젝트가 될 것 같음

  • 책 제목이나 저자만 찾는다면 검색 엔진은 이미 널렸음
    부족한 건 전자책 본문 내용의 검색 색인이고, 생성형 AI 시대에는 곧 엄청나게 중요해질 것임
    HN에서 누군가는 노트북 한 대로 수백만 권의 본문을 색인할 수 있다고 했고, 다른 사람들은 범위가 거의 불가능하다고 함. 이걸 하는 프로젝트가 있는지 궁금함

    • 전자책 하이라이트 모음을 기기 내 의미 검색으로 정리하는 사이드 프로젝트를 만들고 있음
      지금은 자기 콘텐츠만 색인하지만, 나중에는 컬렉션을 공유해서 다른 사람들이 책에서 찾은 관련 아이디어를 의미 검색으로 발견할 수 있는 모드를 넣고 싶음. 현재 동작 방식은 오픈소스에서 볼 수 있음
      [1] https://emdash.ai/
      [2] https://github.com/dmotz/emdash
    • 색인의 크기는 검색 대상 항목 수보다 검색 텍스트에 훨씬 더 좌우됨
      Google이 초창기에 이런 내용을 문서화했던 것으로 기억하는데, 검색 색인은 특정 질의와 맞는 관련 메타데이터를 반환함. 질의 공간은 주로 원시 키워드와 튜플, 기억이 맞다면 2~3단어 n-그램에 기반하고, 후자는 최소 빈도 조건을 만족해야 함. 긴 검색어는 더 짧은 n-그램으로 구성할 수 있음
      영어 고급 원어민 어휘는 보통 약 4만 단어이고, 오래된 단어까지 포함한 큰 사전도 25만 단어 미만일 수 있음
      어휘를 그 단어를 인용한 저작물에 매핑하는 건 비교적 단순함. n-그램은 조합 폭발이 있지만 그래도 꽤 제한된 공간이고, 우리는 이미 웹 규모의 문서 색인을 25년 넘게 해온 경험이 있음
      노트북도 수백만 권에 대해 쓸 만한 색인은 어느 정도 만들 수 있을 것 같지만, 더 포괄적인 색인, 특히 검색 공간의 순위 색인까지 하려면 좀 더 큰 시스템이 필요할 가능성이 큼. 아마 그쪽이 더 큰 난제임
    • 그 노트북이 얼마나 강력한지에 달렸음
      최근 업무에서 로컬 LLM을 다뤘는데, 요즘 양자화가 크게 발전했어도 ThinkPad에서 이런 작업은 가능하긴 하지만 4090/H100 몇 장 달린 VPS를 몇 시간 빌리는 것보다 여전히 훨씬 떨어짐
      요약에서 가장 큰 문제는 로컬 LLM 모델 대부분이 문맥 창이 아주 크지 않아서, 짧은 Vonnegut 소설 같은 큰 텍스트도 버거워한다는 점임. GitHub 이슈 요약으로 테스트했는데 16k 토큰 문맥 창에서도 댓글이 많으면 가끔 힘들어함
      물론 나보다 똑똑한 사람이라면 Raspberry Pi에서도 돌아가게 만들 수 있을지도 모름
    • 인기 있고 무료인 전자책 관리 도구 Calibre가 이제 보유한 모든 책의 본문 색인을 지원하는 것으로 알고 있음
    • 색인의 최초 생성은 평균적인 노트북으로도 가능할 수 있지만, 색인을 자주 갱신하고 요청을 처리하는 건 계산량이 꽤 클 것 같음
      근거는 없고 추측일 뿐이라 더 알고 싶음

  • 검색 색인을 어떻게 채우는지, 그리고 예상하는 메모리 한계가 어느 정도인지 자세히 설명해줄 수 있나?

  • 멋짐. 토렌트 검색에도 쓸 수 있을까?
    영상 스트리밍이 되는 웹 토렌트와 탈중앙 검색 엔진을 함께 돌리는 식으로

  • 이게 실제 검색 엔진인지, 아니면 select from 질의를 만들어주는 프런트엔드일 뿐인지 궁금함

  • 이게 대체 무슨 얘기인지 모르겠음
    “Liber3를 추천받았고, ENS 도메인 이름을 쓰며, ENS와 IPFS에서 동작하고, Glitter를 쓰는 것 같고, Tendermint로 만든 서비스다” 같은 문장이 나오는데, 다른 은하의 언어로 온 외계 신호처럼 들림
    Liber3라는 것도 시도해봤지만 뭘 해도 “Oops! Something went wrong. Please refresh or try again later”만 나옴. 이게 다 뭘 말하는 건가?

    • ENS는 Ethereum Name Service로, 블록체인용 DNS라고 보면 됨
      IPFS는 InterPlanetary File System으로, 불변 P2P S3 같은 분산 객체 저장소에 가까움
      Glitter는 익숙하게 들리지만 바로 떠오르진 않음
      Tendermint는 블록체인용 합의 엔진이고, Inter-Blockchain Communication(IBC) Protocol 및 Cosmos SDK와 함께 블록체인 간 상호운용성을 가능하게 하려는 도구 체인의 일부임
      블록체인 생태계는 정말 그 자체로 작은 세계임. 배타적이라는 뜻은 아니지만 꽤 끼리끼리라서, 적극적으로 찾아보지 않으면 접할 일이 거의 없음
      덧붙이면 IPFS는 데이터베이스나 탈중앙 무신뢰 시스템에 관심이 있다면, 블록체인 회의론자라도 살펴볼 가치가 큼. 내부에서 꽤 흥미로운 작업을 하고 있고, 팀도 거의 모든 블록체인 프로젝트처럼 골드러시식 분위기에 올라타지는 않았음
    • 제목이 전문용어를 걷어낸 버전임
      오픈소스 전자책 검색 엔진을 만드는 구현 지침이라고 보면 됨. 물론 그 설명에도 약간의 전문용어는 남아 있지만 특정 라이브러리 이름을 줄줄이 나열하는 수준은 아님
      글의 대부분은 구현 세부사항이고, 친절하게 링크가 걸려 있음

  • 그러고 나서 거의 15년 전부터 존재했고 이름이 libgen.rs였다는 걸 깨닫게 됨

    • Anna's Archive가 더 좋음
답변달기