RAG와 MCP의 차이가 조금 헷갈립니다

안녕하세요! 좋은 질문 감사합니다. 답변을 드려보자면RAG는모르는 지식을 찾아보고 답변하는 기술입니다RAG는 AI 에이전트가 학습하지 않은 최신 정보나 기업 내부 문서 등을 검색(Retrieval)해서 답변의 정확도를 높이는 방식입니다.핵심 목적: 지식의 확장 및 환각(Hallucination) 방지.작동 방식: 질문과 관련된 문서를 데이터베이스에서 찾아 모델에게 "이 내용을 참고해서 답해줘"라고 전달합니다.에이전트 관점: 에이전트가 똑똑해지기 위해 옆에 두는 '백과사전'과 같습니다.MCP는 데이터와 도구를 연결하는 표준 규격 입니다MCP는 Anthropic에서 발표한 오픈 표준으로, 서로 다른 서비스나 데이터 소스(Google Drive, Slack, GitHub, 로컬 파일 등)를 AI 에이전트와 쉽게 연결하기 위한 규약입니다.핵심 목적: 연결의 표준화 (Integration).작동 방식: 과거에는 서비스마다 일일이 API를 개발해야 했지만, MCP를 사용하면 하나의 표준 인터페이스로 다양한 도구와 데이터를 에이전트에 즉시 붙일 수 있습니다.에이전트 관점: 에이전트가 외부 세계와 소통하기 위해 사용하는 '범용 플러그(Plug)'와 같습니다.

섹션 3 : 이메일 작성 도우미 질문

안녕하세요! 좋은 질문 감사합니다.말씀하신 것처럼 본질적인 차이는 없습니다. 다만 실제 서비스가 아니라 강의이다보니 가능하면 다양한 사용 방법을 안내해드리고 싶어서 준비한 회차입니다. 추가로 만약 회사에서 ChatGPT나 Claude등을 사용하지 못하는 경우 자체서비스를 개발하는 경우가 있는데요(실제로 많은 기업들이 외부 솔루션 사용을 금지하고 있습니다) 그런 상황에서 도움이 되지 않을까 싶어 추가해보았습니다!

postgresql의 pgvector 벡터는 어떤가요?

안녕하세요! 고민이 많으시겠네요. 결론부터 말씀 드리자면 나쁘진 않습니다. 유사도 검색 성능은 쓸만했는데, 한국어 기반 키워드 검색 성능이 많이 떨어지긴 합니다. 이를 보강하는 extension들이 있었는데, 사용해보지는 못했습니다. 경험상 대부분 유사도 검색을 많이 활용하기 때문에 키워드 검색을 무조건 해야하는게 아니라면(특정 용어에 대한 Chunk를 찾아야 한다거나) 저는 일단 pgvector를 활용해보시는 것도 괜찮을 것 같습니다. 처음부터 바로 새로운 툴을 도입하기 어려운 상황이라면 pgvector로 시작했다가 p95, p99등을 모니터링 하시면서 성능이 너무 안나온다고 하면 다른 벡터스토어를 고려해보시는 방안이 어떨까 싶습니다.

doc관련

안녕하세요! 현재 회차에서는 아무런 전처리나 후처리가 이루어지지 않은 상황이라 강의 영상과는 차이가 큰 답변이 나올 수 있습니다. 계속해서 수강하시면 점점 답변이 강의 영상과 비슷해지는 걸 확인하실 수 있으실 거라고 생각합니다. 혹시 전부 수강하셨는데도 답변이 너무 이상하게 나온다면 질문으로 말씀 부탁드립니다!

LangGraph로 구현한 봇을 n8n으로 전환 관련 질문

안녕하세요! 좋은 질문 감사합니다. 1번은 check_faq에서 답변을 찾을 수 있으면 먼저 답변을 생성하는 편이 좋다고 생각합니다. 그러면 굳이 임베딩을 추가로 진행하지 않으면서 비용과 시간을 아낄 수 있기 때문입니다.2번은 케이스에 따라 다른데요, 아래 두가지 경우에서는 n8n을 활용하는 것을 선호하는 편입니다.커스텀 코드를 작성할 필요가 없는 프로젝트라고 판단이 되거나빠르게 테스트를 해보고 싶을 때다만 커스텀 해야될 기능들이 많고(예를 들면 굉장히 까다로운 고객의 요구사항들을 받아줘야한다거나) 할 때는 langgraph 등을 활용해서 직접 개발하는 것을 선호합니다.

load_dotenv() 실행 False

안녕하세요! 어디선가 무언가가 꼬여서 발생한 이슈일텐데 에디터를 한번 종료하시고 재부팅해서 다시 시도해보시겠어요?

RAG 답변 개선을 위한 정답지 활용 구조 검토 요청

안녕하세요! 결론부터 말씀 드리자면 정말 좋은 접근 방법입니다.임베딩 모델을 활용해서 사용자의 질문과 QA데이터셋을 비교해서 답변을 리턴하면, 정확도도 확실히 올라가고(당연한 이야기겠지만) LLM 호출이 사라지니 비용과 시간 측면에서도 확실히 유리합니다. 제가 에이전트 유즈케이스 강의에서 FAQ를 따로 활용하시라고 말씀 드리는 이유가 정확하게 말씀하신 방향과 일치합니다. 저는 업무에서 꼭 정확하게 답변해야하는 질문은 프롬프트에 직접 넣는 식으로도 진행했던 적이 있습니다. 하지만 피드백이 많아지게 되면 QA 데이터 셋을 생성하는 것 자체에 어려움이 있을테니. 아무래도 데이터 검색 효율을 늘리는 방향을 고민해보셔야 할 것 같습니다. 문서 검색을 할 때 사용자의 의도에 맞는 문서를 필터링 하는 로직을 추가 하신다거나, 답변 생성 후 답변을 검증한 후에, 만약 사용자의 의도와 맞지 않는다면 문서를 추가 검색하는 방식도 고민해보실 수 있습니다. 예를 들면 유사도가 가장 높은 1-3위 문서로 답변을 생성했을 때 정확하지 않다면, 4-6위 문서를 활용해서도 답변을 생성해보는 방식으로요. 좋은 방향으로 잘 고민하고 계신 것 같습니다! 또 궁금하신 부분이 있으시면 질문으로 올려주세요~

단순 도구 사용과 도구를 가진 에이전트를 사용하는 것의 차이가 궁금합니다.

안녕하세요! 좋은 질문 감사합니다.말씀하신 것처럼 도구 하나를 사용하는 에이전트라면 멀티에이전트 시스템으로 구축하는 것이 오버엔지니어링이 될 수 있습니다. 저는 강의다보니 다양한 유즈케이스들을 보여드리고 싶어서 그렇게 구현했다고 보시면 좋을 것 같습니다. 다만 해당 에이전트만 활용할 수 있는 도구가 추가될 가능성이 있다면 도구를 하나만 사용하더라도 별도의 에이전트를 구축하는 편이 확장성에 용이할 수도 있습니다. 예를 들면 stock price를 가져오는 에이전트가 거래에 대한 전반적인 정보들을 처리하기 위해 RSI, EMA 등과 같은 수치들을 같이 계산하게 하고자 한다면 새로운 도구를 개발해서 해당 에이전트에게만 전달해서 조금 더 확장이 가능하다고 생각합니다. 다만 정답은 없고, 다양한 테스트를 통해서 서비스에 가장 적합한 환경을 구축하는게 좋다고 생각합니다. 만약 설명이 부족하다면 답글 부탁 드립니다!

LangChain과 LangGraph v1

안녕하세요! 좋은 질문 감사합니다. 답변을 드려보자면v1이 출시되었어도 클래스나 함수 이름이 바뀌면서 arguments등이 변경되긴 했지만 근본적인 구현에는 크게 변화가 없는 것 같습니다. migration guide를 봐도 대단한 작업을 필요로 하는 것 같지는 않습니다.개인적으로 에이전트 개발을 위한 랭그래프 활용은 랭그래프에서 제공하는 다양한 기능들을 활용하는 것 보다 운영하고자 하는 시스템에 맞는 노드 설계가 더 중요하다고 생각합니다. 물론 랭그래프에서 다양한 편의기능을 제공하기는 하지만, 해당 기능들이 운영하고자 하시는 서비스에는 적합하지 않을수도 있습니다자연스럽게 다음 질문으로 넘어가자면, 저는 새로운 기능들 위주로 마이그레이션을 권장하고 싶지는 않습니다. LLM이 이렇게까지 좋아지기 전에 랭체인에서 밀던것은 pdf요약이었는데요, stuff라고해서 pdf전체를 넣어서 요약하는 것이 context window제한으로 제대로 동작하지 않아서 map reduce라는 신기능을 출시했었는데, 성능은 뒤에 나온게 더 별로였습니다. 따라서 v1에 새로 나온 기능들이 기존에 작업하셨던 그래프와 비교했을 때 어마어마하게 뛰어난 성능을 보일거라고 생각하지는 않습니다물론 선제적으로 도입해서 시도해보시는게 좋을 수도 있는데, 저는 운영 환경 마이그레이션은 최대한 보수적으로 하는게 좋다고 생각합니다. v1이 출시된지 얼마 되지 않아서 아직 use case들이 많이 공유되지 않았을텐데 아마 내년 2-3월 즈음이면 슬슬 "이런거 해보니까 좋더라구요~"와 같은 내용들이 공유되기 시작할 거에요. 그러면 그 때 쓸만한지 보시고 업무에 적용하시는 편이 좋을 것 같습니다추가적인 설명이 필요하다면 답글 부탁드립니다!

2.4 강의 관련 질문(답변을 검증하는 self rag)

안녕하세요! 결론부터 말씀 드리자면 좋은 접근이라고 생각합니다. LLM이 많이 발전해서 다양한 기능들을 수행할 수는 있지만, temperature를 아무리 0으로 설정해도 항상 같은 답변을 받기는 어려운게 사실입니다. 지금 하신 것처럼 원하는 결과를 얻기 위해서 프롬프트를 계속 수정해가면서 테스트 해보시는게 가장 합리적이고 현재로서 가장 좋은 방향입니다.