clickonitem — LLM·LangChain 개발 노트

📌 3줄 요약 · 벡터 검색으로 가져온 문서에는 질문과 상관없는 문단 이 섞여 있는 경우가 많아, LLM에게 그대로 넘기면 노이즈 가 됩니다. · Contextual Compression Retriever 는 검색으로 찾은 문서를 질문에 맞게 압축·선별 해, 꼭 필요한 부분만 남겨 LLM에 전달합니다. · 불필요한 내용을 걷어 내면 답변 품질이 올라가고 토큰 낭비도 줄어 , RAG 파이프라인이 한층 깔끔해집니다. 📖 목차 검색 결과에 섞이는 노이즈 문제 Contextual Compression의 아이디어 압축기(Compressor)의 종류 기본 사용법 코드로 보기 문서가 걸러지는 과정 실무 팁 자주 묻는 질문(FAQ) ❓ 질문 → 🔍 기본 검색 → 🗜️ 압축·선별 → ✅ 핵심만 전달 앞선 글들에서 Retriever 로 문서를 검색하고, MultiQuery 나 Self-Query 같은 기법으로 검색의 폭과 정확도를 넓히는 방법을 살펴봤습니다. 그런데 문서를 " 잘 찾는 것 "과 그 문서를 " 잘 다듬어 쓰는 것 "은 또 다른 문제입니다. 검색으로 데려온 문서 안에는 질문과 관계없는 문장이 적지 않게 섞여 있기 때문입니다. 오늘은 이렇게 검색 결과에서 필요한 부분만 추려 LLM에 넘기는 Contextual Compression Retriever 를 정리해 보겠습니다. 🧭 검색 결과에 섞이는 노이즈 문제 벡터 검색은 질문과 의미가 비슷한 문서 를 통째로 데려옵니다. 문제는 그 문서 하나가 여러 주제를 담은 긴 글 일 때입니다. 예를 들어 "환불 정책이 어떻게 되나요?"라고 물었는데, 가져온 문서가 배송·결제·환불·회원가입을 모두 다루는 긴 안내문이라면, 그중 정작 질문과 관련된 부분은 몇 문장 뿐입니다. 나머지는 답변에 도움이 되지 않는 노이즈 입니다. 이 상태로 문서 전체를 LLM에 넘기면 두 가지 손해가 생깁니다. 하나는 토큰 낭비 로...

📌 3줄 요약 · 보통의 벡터 검색 은 "의미가 비슷한 문서"는 잘 찾지만, "2023년 이후", "평점 4점 이상"처럼 조건으로 걸러야 하는 질문 에는 약합니다. · Self-Query Retriever 는 사용자의 자연어 질문을 검색어 와 메타데이터 필터 로 스스로 쪼개어 , 의미 검색과 조건 필터를 동시에 적용합니다. · 문서에 붙은 메타데이터 구조 를 미리 알려 주기만 하면, "최근에 나온 액션 영화 중 평점 높은 것"같은 질문도 자동으로 처리됩니다. 📖 목차 일반 벡터 검색이 놓치는 것 Self-Query Retriever의 아이디어 메타데이터 구조를 알려 주기 기본 사용법 코드로 보기 질문이 필터로 바뀌는 과정 실무 팁 자주 묻는 질문(FAQ) 🗣️ 자연어 질문 → 🧠 LLM 해석 → 🔍 검색어 + 🏷️ 필터 → ✅ 걸러진 결과 앞선 글들에서 Retriever 로 문서를 검색하고, MultiQuery 나 Contextual Compression 같은 기법으로 검색 품질을 끌어올리는 방법을 살펴봤습니다. 그런데 현실의 질문은 "이런 내용"뿐 아니라 " 이런 조건 "을 함께 담고 있는 경우가 많습니다. "작년에 나온 영화 중에서", "카테고리가 요리인 글만", "평점이 높은 제품으로"처럼요. 오늘은 이렇게 의미와 조건이 섞인 질문 을 자동으로 처리해 주는 Self-Query Retriever 를 정리해 보겠습니다. 🧭 일반 벡터 검색이 놓치는 것 기본적인 벡터 검색은 질문과 문서를 임베딩(숫자 벡터) 으로 바꾼 뒤, 의미가 가까운 문서 를 찾아 줍니다. "맛있는 디저트 레시피"라고 물으면 비슷한 주제의 글을 잘 데려오죠. 하지만 " 2023년 이후에 올라온 디저트 레시피"처럼 명확한 ...

📌 3줄 요약 · LCEL 체인은 프롬프트·모델·파서 처럼 이미 만들어진 블록만으로는 부족할 때가 많고, 중간에 내가 만든 파이썬 함수 를 끼워 넣어야 하는 순간이 옵니다. · RunnableLambda 는 평범한 함수를 체인에 꽂을 수 있는 블록으로 감싸 주고, RunnablePassthrough 는 입력을 건드리지 않고 그대로 흘려보내거나 값을 덧붙여 넘깁니다. · 두 도구를 익히면 "전처리 → 모델 → 후처리", "원본은 보존하면서 계산값만 추가" 같은 현실적인 흐름 을 깔끔하게 짤 수 있습니다. 📖 목차 왜 체인에 함수를 끼워야 할까 RunnableLambda로 함수를 블록으로 만들기 함수를 자동으로 감싸 주는 경우 RunnablePassthrough로 입력 그대로 넘기기 assign으로 값을 덧붙이기 실무 팁 자주 묻는 질문(FAQ) 📥 입력 → 🛠️ 내 함수(전처리) → 🔗 프롬프트·모델 → ✅ 결과 앞선 글들에서 LCEL(LangChain Expression Language)의 | 기호로 프롬프트 → 모델 → 파서 를 잇고, 병렬과 분기 로 흐름을 넓히는 방법을 살펴봤습니다. 그런데 실제로 체인을 짜다 보면, LangChain이 미리 만들어 둔 블록만으로는 해결되지 않는 틈이 생깁니다. 입력 문자열을 정리하거나 , 모델 출력을 한 번 더 가공하거나 , 중간에 간단한 계산을 끼워 넣어야 할 때가 그렇습니다. 오늘은 이런 틈을 메워 주는 두 도구, RunnableLambda 와 RunnablePassthrough 를 제대로 쓰는 법을 정리해 보겠습니다. 🧭 왜 체인에 함수를 끼워야 할까 LCEL 체인의 각 블록은 입력을 받아 출력을 내놓는 공통 규칙을 따릅니다. 프롬프트, 모델, 파서가 모두 이 규칙을 지키기 때문에 | 로 자연스럽게 이어집니다. 문제는 우리가 하고 싶은 일이 늘 이 블록들로 딱 떨어지지 않는다는 점입니다. 예를 들어 사...

📌 3줄 요약 · LCEL 의 | 연결은 "한 줄로 흐르는" 체인을 만들지만, 실제 서비스에서는 여러 작업을 동시에 돌리거나 조건에 따라 길을 나누는 경우가 많습니다. · RunnableParallel 은 여러 체인을 병렬로 실행 해 결과를 하나의 딕셔너리로 모아 주고, RunnableBranch 는 입력을 보고 어느 체인으로 보낼지 분기합니다. · 두 도구를 익혀 두면 "요약과 번역을 한꺼번에", "질문 유형에 따라 다른 프롬프트로" 같은 복합 흐름 을 깔끔하게 짤 수 있습니다. 📖 목차 왜 병렬과 분기가 필요할까 RunnableParallel로 동시에 실행하기 병렬 결과를 다음 단계로 넘기기 RunnableBranch로 길 나누기 병렬과 분기를 함께 쓰기 실무 팁 자주 묻는 질문(FAQ) 📥 입력 → 🔀 병렬 / 분기 → 🔗 각 체인 실행 → ✅ 결과 취합 앞선 글들에서 LCEL(LangChain Expression Language)의 | 기호로 프롬프트 → 모델 → 파서 를 한 줄로 잇는 방법을 익혔습니다. 이 방식은 직관적이지만, 흐름이 처음부터 끝까지 일직선 이라는 전제를 깔고 있습니다. 그런데 실제 서비스에서는 여러 작업을 동시에 처리 하거나, 입력을 보고 서로 다른 길로 보내야 하는 상황이 자주 생깁니다. 오늘은 LCEL을 한 단계 더 깊이 들여다보며, 체인을 병렬로 묶는 RunnableParallel 과 조건에 따라 분기하는 RunnableBranch 를 살펴보겠습니다. 🧭 왜 병렬과 분기가 필요할까 하나의 입력에 대해 여러 결과가 동시에 필요한 경우를 떠올려 봅시다. 예를 들어 어떤 문서를 받아 요약 도 하고 핵심 키워드 도 뽑고 싶다면, 두 작업은 서로를 기다릴 필요가 없습니다. 이럴 때 작업을 차례로 돌리면 괜히 시간이 더 걸립니다. 서로 독립적인 작업은 동시에 돌리는 편이 자연스럽습니다. 반대로, ...

📌 3줄 요약 · LangChain 체인 을 노트북 안에만 두지 않고, FastAPI 로 감싸면 누구나 호출할 수 있는 API 서버 가 됩니다. · 핵심은 요청(request) → 체인 실행 → 응답(response) 의 흐름이며, FastAPI의 엔드포인트 함수 안에서 체인을 invoke 하는 것이 전부입니다. · 입력·출력 형식은 Pydantic 모델 로 정의하고, 긴 답변은 스트리밍 으로 흘려보내면 실제 서비스에 가깝게 다듬을 수 있습니다. 📖 목차 왜 체인을 API로 감싸야 할까 FastAPI와 체인이 만나는 지점 입력·출력 형식 정의하기 코드로 살펴보기 스트리밍 응답 다루기 실무 팁 자주 묻는 질문(FAQ) 🌐 HTTP 요청 → 🚪 FastAPI 엔드포인트 → 🔗 체인 실행(invoke) → ✅ JSON 응답 지금까지는 LangChain 체인을 주로 노트북이나 터미널 안에서 직접 실행해 봤습니다. 그런데 만든 체인을 웹·앱·다른 서버에서 가져다 쓰려면 , 결국 "밖에서 호출할 수 있는 창구"가 필요합니다. 그 창구가 바로 API 서버 이고, 파이썬에서 이를 가장 가볍게 만들 수 있는 도구가 FastAPI 입니다. 오늘은 완성한 체인을 FastAPI로 감싸 호출 가능한 API 로 바꾸는 과정을 차근차근 따라가 보겠습니다. 🧩 왜 체인을 API로 감싸야 할까 잘 만든 체인이라도, 코드 안에서만 돌아간다면 그 코드를 실행할 수 있는 사람 만 쓸 수 있습니다. 프런트엔드 개발자나 모바일 앱, 또는 다른 백엔드 서비스가 이 체인을 쓰고 싶어도 직접 파이썬을 돌릴 수는 없는 경우가 대부분입니다. 그래서 체인을 HTTP로 호출할 수 있는 형태 로 열어 두는 것이 중요합니다. 한번 API로 감싸 두면, 어떤 언어·어떤 환경에서도 주소로 요청만 보내면 체인의 결과를 받아 갈 수 있습니다. 즉 API 서버는 체인과 바깥 세상을 이어 주는 다리 인 셈입니다. 체인을 API로 ...