본문 바로가기
WIKI 기술 지식 베이스

lakeFS와 LanceDB 함께 사용하기

원문 보기 위키 갱신

LanceDB는 벡터 데이터를 저장하고 쿼리할 수 있게 해 주는 벡터 데이터베이스예요.

LanceDB는 오브젝트 스토어 위에서 바로 동작하기 때문에, lakeFS 안에서 벡터 데이터를 저장하고 쿼리하는 데 사용할 수 있어요.

출처: 문서

본문

lakeFS와 함께 동작하도록 LanceDB 설정하기

lakeFS와 함께 동작하도록 LanceDB를 설정하려면 lakeFS S3 게이트웨이를 사용하도록 구성해요:

import lancedb  # pip install lancedb

db = lancedb.connect(
    # structure: s3://<repository ID>/<branch>/<path>
    uri="s3://example-repo/example-branch/path/to/lancedb",
    storage_options={
        # Your lakeFS S3 Gateway
        "endpoint": "https://example.lakefs.io",
        # Access key and secret of a lakeFS user with permissions
        #  to read and write data from that path
        "access_key_id": "«redacted:AKIA…»",
        "secret_access_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    }
)

# table "vectors" on the branch "example-branch" in the repository "example-repo"
table = db.open_table('vectors')

# update and query some data!
table.add([{'id': '1', 'embedding': generate_embedding('some data')}])
df = db.open_table('vectors').search(generate_embedding('some other data')).limit(10).to_pandas()

팁

LanceDB에서 오브젝트 스토어 접근을 설정하는 방법에 대해 더 알아보려면 Configuring Cloud Storage in LanceDB를 참고하세요.

사용 사례

lakeFS 위에서 LanceDB를 실행하면 몇 가지 주요 이점이 있어요:

멀티모달 데이터 스토리지

많은 경우 LanceDB는 문서, 이미지, 텍스트 파일 같은 다른 곳에 존재하는 데이터의 임베딩을 저장해요. 이 "원본(raw)" 데이터 파일은 임베딩을 추출하려고 처리되고, 그 임베딩이 LanceDB에 저장돼요 — 하지만 원본 데이터도 검색(retrieval)을 위해 저장되고, 어떤 경우에는 그 메타데이터가 데이터 웨어하우스나 데이터 레이크에서 쓰이려고 다른 포맷으로 저장돼요.

이 임베딩들을 다른 모달리티와 함께 같은 장에(co-locate) 두면 일관성을 포기하지 않고 더 복잡한 쿼리와 분석을 수행할 수 있어요. 커밋 하나가 벡터 임베딩, 원본 데이터, 메타데이터를 하나의 원자적 단위로 캡처하거든요.

새 데이터의 차등 처리

lakeFS는 데이터가 시간이 지나며 어떻게 바뀌는지 이해하는 매우 성능 좋고 확장 가능한 방법을 제공해요. 예컨대 images/에 원본 이미지 데이터를 저장한다면 — images/ 디렉터리에 이미지를 추가, 제거, 갱신해 원본 데이터를 업데이트할 수 있고, lakeFS가 그 변경을 커밋으로 캡처해요.

이 덕분에 새 데이터의 차등 처리(differential processing)가 가능해요: LanceDB에 images 테이블이 있다면 그 테이블이 나타내는 최신 커밋을 추적할 수 있어요. 새 데이터가 도착하면 이전 커밋과 새 커밋을 diff해서 최신 커밋에 맞춰 임베딩을 갱신하고, 결과적으로 추가·제거·갱신할 임베딩의 최소 집합만 다뤄요.

Write, Audit, Publish 훅으로 높은 데이터 품질 보장하기

lakeFS 훅을 사용하면 벡터 임베딩이 추론(inference)에 제공되기 전에 일정 품질 임계값을 충족하는지 보장할 수 있어요. 이 품질 검사는 새 데이터가 main이나 production 브랜치로 머지되기 전에 자동으로 트리거될 수 있어요. 이런 테스트들이요:

  • 커버리지(Coverage): 데이터셋의 이미지 중 몇 개가 처리되어 임베딩을 가지나요? 몇 개의 임베딩이 더 이상 데이터셋에 없는 이미지를 가리키나요?

  • 거버넌스(Governance): 임베딩이 데이터 정책과 일치하나요? PII를 담고 있나요?

  • 정확성(Accuracy): 임베딩이 정확한가요? 기대 출력과 일치하나요?

  • 드리프트(Drift): centroid shift와 norm drift 같은 지표가 허용 한도 안에 있나요?

이 테스트 중 하나라도 실패하면 커밋이 거부되고 데이터는 추론에 제공되지 않아요. 이렇게 데이터가 높은 품질이고 데이터 정책과 일관됨을 보장해요.

추적 가능하고 재현 가능한 추론

lakeFS에 배포한 뒤에는, 벡터 임베딩을 쿼리할 때 쿼리하려는 데이터의 브랜치, 태그, 커밋 ID를 지정해야 해요. 쿼리하려는 데이터의 커밋 ID를 캡처하면 어느 시점이든 정확히 같은 결과를 재현할 수 있어요. 흔한 접근법은 이 커밋 ID를 추론 로그에 기록하는 거예요 — 원래 쿼리를 만든 사용자나 에이전트와 정확히 같은 결과를 재현할 수 있게 되죠.

간단해 보이지만, 벡터 데이터베이스는 시간이 지나며 꽤 자주 바뀌기 때문에 "이 고객은 왜 챗봇이 무례하다고 불평했지?"나 "이 사용자에게는 왜 이 제품 추천이 맞지 않았지?" 같은 질문에 답하기가 어려워요.

그 커밋 ID를 쿼리에 묶어 두면 더 나아가 그 시점에 존재했던 원본 데이터까지 볼 수 있고, 누가, 언제, 왜 그 변경을 도입했는지에 대한 커밋 로그와 함께 볼 수 있어요.

더 알아보기 (Learn more)

공식 문서: lakeFS LanceDB 연동