내 문서·DB·API 데이터를 LLM에 연결해 주는 오픈소스 프레임워크로, 문서를 읽고 나눠 인덱스로 만든 뒤 질문에 맞는 부분을 찾아 LLM에 넘기는 RAG 전 과정을 짧은 코드로 처리한다. 사내 문서 Q&A처럼 내 데이터를 바탕으로 답하는 앱을 빠르게 만들 때 쓴다.
| 단계 | 하는 일 | 대표 구성요소 |
|---|---|---|
| 로딩 | 파일·웹·DB에서 문서 읽기 | SimpleDirectoryReader, LlamaHub 커넥터 |
| 분할·임베딩 | 문서를 청크로 나눠 벡터로 변환 | 노드 파서, 임베딩 모델 |
| 인덱싱 | 검색할 수 있는 구조로 저장 | VectorStoreIndex |
| 질의 | 관련 청크를 찾아 답변 생성 | 쿼리 엔진, 챗 엔진 |
Python에서는 pip install llama-index로 설치한다. 문서 폴더를 SimpleDirectoryReader로 읽고, VectorStoreIndex로 인덱싱한 뒤 index.as_query_engine()으로 바로 질문하면 된다. 이전 대화를 이어 가는 챗봇이 필요하면 as_chat_engine()을 쓴다.
기본값은 OpenAI 모델을 쓰므로 API 키가 필요하다. 다른 LLM이나 로컬 모델을 쓰려면 Settings에서 LLM과 임베딩 모델을 바꾼다. 인덱스는 저장해 두고 다시 불러오면 같은 문서를 매번 임베딩하는 비용이 들지 않는다.
문서가 많아지면 메모리 인덱스 대신 Chroma·Pinecone 같은 외부 벡터 DB를 연결한다. 주제가 다른 문서 묶음이 여럿이면 RouterQueryEngine으로 질문마다 알맞은 인덱스를 고르게 한다. 표나 도표가 많은 PDF는 기본 리더로 읽으면 구조가 깨지기 쉬워 별도 파서를 쓰는 편이 낫다.
| 항목 | LlamaIndex | LangChain |
|---|---|---|
| 중심 | 데이터 연결·인덱싱·검색 | 체인·에이전트·도구 연결 |
| 잘 맞는 일 | 문서 기반 Q&A, 검색 품질 다듬기 | 여러 도구를 부르는 작업 흐름 |
| 시작 방식 | RAG 기본값으로 빠르게 시작 | 구성 요소를 직접 조립 |
두 프레임워크 모두 서로의 영역으로 기능을 넓혀 와서 경계가 뚜렷하지는 않다. 검색 품질이 핵심이면 LlamaIndex로 시작하고, 둘을 함께 쓰기도 한다.
돌아가는 것과 정확한 답을 내는 것은 다르다. 청크 크기와 한 번에 가져올 청크 수(top-k)를 문서 특성에 맞게 조절하고, 실제 질문 몇 개로 답이 맞는지 확인해야 한다. 업데이트가 잦아 버전에 따라 import 경로가 바뀐 적이 있으니 예제 코드는 공식 문서 최신판에 맞춰 쓴다.
가장 흔한 건 흩어진 내 문서를 모아 질문에 답하는 봇을 만드는 방식이다. 작은 폴더로 먼저 돌려 보고, 답이 괜찮으면 벡터 DB를 붙여 규모를 키운다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 사내 문서 검색 | 위키·매뉴얼·PDF를 인덱싱해 두고 직원이 자연어로 물으면 근거 문서와 함께 답하게 |
| 고객 지원 챗봇 | FAQ·제품 문서를 챗 엔진에 연결해 이전 대화를 이어 가며 답하게 |
| 에이전트의 검색 도구 | 만든 쿼리 엔진을 에이전트가 부르는 도구로 넘겨, 필요할 때만 문서를 찾아보게 |
| RAG 프로토타입 | 기본값으로 빠르게 띄워 보고 청크 크기·top-k를 바꿔 가며 검색 품질 비교 |