TwentyTwentyOne

에이전트가 똑똑해 보이지만 위험한 이유 — 무한 루프, 잘못된 tool 호출, 비용 증가를 어떻게 봐야 하나에이전트를 처음 붙이면, 솔직히 좀 신납니다.질문을 보고,필요한 tool을 고르고,결과를 받아서 다시 답을 만들고…딱 봐도 “오, 이제 진짜 AI 서비스 같네” 싶은 느낌이 와요.근데 여기서 한 번 더 가야 합니다.왜냐면 에이전트는 멋져 보이는 만큼, 운영에서는 생각보다 무섭기 때문이에요.특히 처음 만들 때는 이런 일이 자주 생깁니다.같은 질문에 쓸데없이 tool을 여러 번 부름굳이 안 불러도 될 tool을 자꾸 씀tool 오류가 나면 이상하게 우회하거나 헛소리를 함대화가 길어질수록 느려지고 비싸짐어디서 잘못됐는지 추적이 잘 안 됨LangChain 문서는 에이전트가 기본적으로 모델 호출 → tool..

LangChain Agent 처음 만들기 — create_agent로 진짜 에이전트처럼 동작하는 흐름 이해하기여기서부터는 분위기가 조금 달라집니다.지금까지는 체인을 만들고,문서를 찾고,tool도 붙여봤죠.그런데 아직은 어딘가 “기능 조각” 느낌이 남아 있습니다.질문이 오면 우리가 미리 정한 흐름대로 움직이는 쪽에 더 가까웠어요.에이전트는 여기서 한 단계 넘어갑니다.질문을 보고, 지금 뭘 해야 하는지 판단하고, 필요한 tool을 고르고, 결과를 받아서, 최종 답을 만드는 루프가 생깁니다. LangChain 문서는 agent를 “언어 모델과 tools를 결합해 과제를 추론하고, 어떤 tool을 쓸지 결정하며, 반복적으로 해결해 나가는 시스템”으로 설명하고, 전형적인 agent loop는 모델 호출 → too..

LangChain으로 Tool Calling 제대로 다루기 — tool 설계, 설명문, 반환 형식이 품질에 미치는 영향지난 글에서 Tool Calling의 필요성을 봤다면,이번엔 한 단계 더 들어가야 합니다.왜 어떤 tool은 잘 호출되고,어떤 tool은 이상한 순간에 불리고,어떤 tool은 인자를 자꾸 틀리게 넣는지요.처음엔 모델 문제처럼 보일 수 있어요.근데 실제로는 꽤 자주 tool 설계 문제입니다.LangChain 공식 문서는 tool의 이름, 설명, 인자 이름, 인자 설명이 단순한 메타데이터가 아니라, 모델이 “언제 이 도구를 써야 하는지”와 “어떻게 써야 하는지”를 판단하는 데 직접 영향을 준다고 설명합니다. 또 @tool을 쓸 때 type hint는 입력 스키마를 정의하므로 필수이고, doc..

Tool Calling이 진짜 중요한 이유 — LLM이 답변만 하는 걸 넘어서 외부 기능을 쓰게 만드는 방법RAG까지 오면 한 번 이런 생각이 듭니다.“이제 문서도 찾고, 답도 하네. 그럼 거의 다 된 거 아닌가?”근데 막상 서비스로 가면 바로 한계가 보입니다.사용자가 묻는 건 꼭 “설명”만이 아니거든요.오늘 환율 알려줘내 주문 상태 조회해줘이 숫자들 평균 계산해줘이 API에서 최신 데이터 가져와줘사용 가능한 일정 찾아줘이건 문서 검색만으로는 안 됩니다.왜냐면 여기서는 지식을 말하는 것이 아니라, 외부 기능을 실제로 써야 하기 때문이죠.그래서 Tool Calling이 중요합니다.LangChain 문서는 tools를 “에이전트가 할 수 있는 일을 확장하는 장치”로 설명하고, 실시간 데이터 조회, 코드 실행..

RAG 품질이 안 나오는 이유 — chunk 크기, overlap, k값, 프롬프트 문제를 어떻게 봐야 하나첫 번째 RAG를 만들고 나면 보통 되게 비슷한 순간이 와요.처음 질문 하나는 잘 맞습니다.그래서 속으로 살짝 신나요.“오… 됐다.”근데 두 번째, 세 번째 질문부터 이상해집니다.어떤 질문에는 진짜 그럴듯하게 답하는데,어떤 질문에는 엉뚱한 chunk를 물고 오고,가끔은 문서를 가져와 놓고도 답을 이상하게 하고,또 어떤 경우엔 문서 안에 답이 있는데도 못 찾습니다.이쯤 되면 많은 분이 바로 이렇게 생각해요.“모델이 별론가?”“임베딩 모델을 더 좋은 걸로 바꿔야 하나?”“벡터DB를 바꿔야 하나?”물론 그런 경우도 있습니다.그런데 실제로는 그 전에 먼저 봐야 할 게 있어요.RAG 품질 문제의 상당수는 c..

첫 번째 RAG 만들기 — Retriever로 찾고, 문서를 넣고, 근거 기반으로 답하게 하기여기까지 왔으면 이제 드디어 많은 사람이 말하는 그 단어, RAG를 직접 만질 차례입니다.사실 저는 처음에 RAG를 너무 거창하게 생각했어요.뭔가 엄청 복잡한 아키텍처 같고, 벡터DB도 붙어야 하고, 검색 최적화도 해야 하고, 평가도 해야 하고…맞아요. 나중엔 그렇게 커질 수 있습니다.근데 첫 번째 RAG는 그렇게 시작할 필요가 없어요.진짜 출발은 생각보다 소박합니다.질문이 들어오면 관련 문서를 찾고, 그 문서를 프롬프트에 넣고, 그 문서를 근거로 답하게 만든다.LangChain 문서도 retriever를 비정형 쿼리를 받아 관련 문서를 반환하는 인터페이스로 설명하고, RAG를 특정 소스 정보에 대해 질문에 답하..

임베딩과 벡터스토어를 처음 이해하는 글 — RAG를 배우기 전에 꼭 알아야 할 검색의 언어여기서부터 많은 분이 갑자기 어려워합니다.문서 하나 읽고 답하게 만드는 것까지는 따라왔는데,이제 문서가 10개, 100개, 1000개가 되면 어떻게 해야 하냐는 거죠.그 순간부터 나오는 단어가 있습니다.임베딩벡터벡터스토어유사도 검색semantic search처음 보면 좀 부담스럽습니다.저도 처음엔 그랬어요.괜히 수학 같고, 뭔가 AI 엔진 속으로 들어가는 느낌이었거든요.근데 막상 핵심은 생각보다 단순합니다.임베딩은 “문장의 의미를 숫자로 바꾼 것”이고,벡터스토어는 “그 숫자들을 저장해두고 비슷한 의미를 찾는 저장소”입니다.LangChain 문서는 임베딩 모델이 텍스트를 고정 길이 숫자 벡터로 바꾸고, 이 벡터가 텍스..

LangChain으로 문서 하나 읽고 답하는 AI 만들기 — RAG 전에 꼭 알아야 할 가장 작은 문서 Q&A여기서부터 좀 재밌어집니다.이전까지는 LangChain으로프롬프트를 만들고,체인을 연결하고,대화 히스토리를 관리하는 흐름까지 왔죠.그런데 아직 모델은 기본적으로 자기 안에 있는 지식만 가지고 답합니다.즉, 내가 가진 문서나 회사 자료나 강의 노트나 README를 “읽고 답하는” 단계는 아니었어요.이제 그걸 해볼 차례입니다.다만 이번 글은 일부러 RAG까지 바로 가지 않겠습니다.왜냐면 많은 분이 여기서 너무 빨리 벡터스토어, 임베딩, 검색기로 뛰어들다가 정작 핵심을 놓치거든요.핵심은 생각보다 단순해요.문서를 읽는다 → 적당히 나눈다 → 질문과 함께 넣는다 → 근거 기반으로 답하게 만든다LangCha..

LangChain 대화 히스토리 다루기 — 긴 대화를 자르고, 요약하고, 비용을 관리하는 방법챗봇을 처음 만들면, 이상하게 초반에는 다 잘됩니다.두세 번 주고받을 때는 “오, 문맥도 기억하네?” 싶어요.근데 대화가 길어지는 순간부터 느낌이 바뀝니다.답이 점점 느려지고,쓸데없이 예전 얘기를 끌고 오고,가끔은 지금 질문보다 한참 전에 했던 말을 더 중요하게 받아들이기도 하죠.그때 알게 됩니다.대화형 챗봇에서 중요한 건 “많이 기억하는 것”이 아니라,어떤 걸 남기고 어떤 걸 줄일지 설계하는 것이라는 걸요.LangChain 쪽 문서도 이걸 꽤 분명하게 말합니다. 긴 대화는 LLM의 컨텍스트 윈도우를 넘길 수 있고, 설령 윈도우 안에 들어가도 오래된 내용 때문에 모델이 산만해지고 응답 속도와 비용이 커질 수 있다..

LangChain 대화형 챗봇 만들기 — 메시지 히스토리와 문맥 유지를 처음부터 이해하는 방법여기서부터 진짜 “챗봇 같다”는 느낌이 나기 시작합니다.이전 글까지는 프롬프트를 만들고, 모델을 호출하고, 출력 형식을 다루는 흐름이었죠.그런데 아직은 사실 한 번 물어보고 한 번 답하는 도구에 더 가까웠어요.사용자가 이렇게 묻는 순간부터 문제가 생깁니다.“조금 더 쉽게 설명해줘”“방금 말한 예시 다시 보여줘”“그럼 그걸 FastAPI 기준으로 바꾸면?”“아까 말한 3번째 방식만 코드로 줘”이 질문들은 전부 이전 대화 맥락이 있어야만 제대로 답할 수 있습니다.LangChain 문서도 메시지를 모델과의 상호작용에서 대화 상태를 표현하는 기본 단위라고 설명하고, RunnableWithMessageHistory는 다른..