Milky's note

Databricks를 UI에서 클릭으로 다루는 건 처음 익힐 땐 편하지만,카탈로그 몇 개 + 파이프라인 몇 개를 반복해서 만들어야 하거나 다른 워크스페이스에 그대로 옮겨야 할 때는 금방 피곤해진다.그래서 나는 보통 CLI를 많이 사용했다.UI에서 하는 것 보다 간편하고 훨씬 피로도가 덜 했다 !CLI 설치부터 시작해서, 카탈로그 생성 → 볼륨 생성 → 간단한 Lakeflow Pipeline 생성/실행까지 를 정리하려고 한다. 아래 예시에서 쓰는 카탈로그/스키마 이름(blogpost_demo 등)은 전부 이 글을 위해 새로 만든 데모용 이름이다.그대로 복사해서 써도 되지만, 카탈로그 이름은 메타스토어 안에서 유일해야 하므로 실제로 쓸 때는 본인 조직에 맞는 이름으로 바꿔야 한다. 0. CLI 설치설치 확인..

컬럼 추가했는데 검색 결과에 안 보일 때청킹 단계에서 document_chunks 테이블에 page_start, page_end, section_title, chunk_position, element_types 컬럼을 추가했다. PDF 몇 페이지 몇 섹션에서 나온 내용인지를 답변에 같이 보여주기 위해서였다.테이블 자체는 문제없이 값이 채워졌다.SELECT page_start, section_title FROM document_chunks로 확인하면 멀쩡하게 나온다.그런데 이 테이블을 소스로 삼는 Vector Search 인덱스를 통해 검색하면 이 컬럼들이 아예 보이지 않았다.sync-index를 몇 번을 돌려도 마찬가지였다.databricks vector-search-indexes sync-index m..

RAG를 처음 만들 때는 보통 "문서 몇 개 넣고 → 청킹하고 → 임베딩하면 끝"이라고 생각하기 쉽다.하지만 실제 문서(스캔 PDF, 한글 HWP, 엑셀 표, 옛날 포맷 .doc/.ppt 등)를넣기 시작하면 파싱 단계에서만 절반 이상의 삽질이 나온다. 아래 내용은 Databricks Lakeflow Declarative Pipeline(예전 이름 DLT)으로문서 파싱 파이프라인을 운영하면서 실제로 부딪힌 문제들이다.다만 여기서 다루는 문제의 대부분은 Databricks뿐 아니라어떤 RAG 스택(LangChain, LlamaIndex, 직접 짠 파이프라인 등)에서도 똑같이 마주치는 공통 이슈다. 코드 예시만 Databricks 도구(ai_parse_document, Auto Loader 등)로 되어 있을 ..

프로젝트에서 빠지게 되어 인수인계 문서를 쓰기 시작했다.BigQuery/Airflow로 돌아가는 마케팅 데이터 파이프라인을 담당하고 있었는데, 정리할 게 진짜 많았다. DAG 코드 수십 개테이블 스키마운영 가이드, 트러블슈팅 노하우 (워드로)담당자·이슈 트래커 (엑셀로) 한 줄 한 줄 워드에 옮겨 적다 보니 분량이 감당 안 되는 수준으로 불어났다. 근데 곰곰이 생각해보니, 다음 담당자가 이걸 읽는 시간이 너무 아까울 것 같았다. 정작 필요한 순간엔 "그 DAG 스케줄이 뭐였더라", "이 이슈 담당자가 누구였지" 하면서 문서 전체를 Ctrl+F 하고 있을 게 뻔했다.그래서 방향을 틀었다. "이걸 다 읽게 하지 말고, 그냥 물어보게 하면 되지 않을까?"그렇게 워드 문서 작성이 로컬 RAG(Retrieval-..