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으로 설정해도 항상 같은 답변을 받기는 어려운게 사실입니다. 지금 하신 것처럼 원하는 결과를 얻기 위해서 프롬프트를 계속 수정해가면서 테스트 해보시는게 가장 합리적이고 현재로서 가장 좋은 방향입니다.

Agent 성능 관련 문의

안녕하세요! 좋은 질문 감사합니다. ChatGPT에 pdf와 같은 파일을 업로드해서 분석한다면 OpenAI에서 제공하는 다양한 pdf parsing과 분석 툴들을 사용할 수 있다는 장점이 있습니다(어떻게 구현이 되었는지 알 수는 없지만) 직접 유사한 기능을 개발한다면 pdf 파일 불러오기 -> pdf 파일 텍스트 파싱 -> pdf 텍스트 LLM 전달 과 같은 흐름을 직접 구현하면 비슷한 효과를 얻을 수 있을거라고 생각합니다. 저는 개인적으로 가급적이면 있는 도구들을 활용하는게 좋다고 생각합니다. 만약 회사 정책에 위반이 되는게 아니라면, ChatGPT를 활용해서 pdf나 엑셀을 분석하는 편이 더 좋다고 생각합니다. 아마 그들은 ChatGPT에만 엄청 많은 수의 엔지니어들을 할당해서 개발중일거라, 우리가 직접 개발하는 것보다 훨씬 더 빠르고 다양한 기능들을 제공할 수 있을거라고 생각하기 때문입니다.다만 말씀하신 보안 문제가 있을 수 있고, 프롬프트를 작성해서 우리 회사나 내가 처리하는 문서에 대한 context를 조금 더 자세히 제공할 수 있다면 ChatGPT를 쓰는 것보다 직접 개발하는 것이 LLM에게 문맥을 더 자세히 제공하는 측면에서는 유리하다고 생각합니다. 인프라를 직접 관리하면서 서비스를 운영하는 것과 누군가가 제공하는 서비스를 사용하는 유지보수도 고려가 되어야겠지만요.

후속강의 문의

좋은 피드백 감사합니다! 기획은 끝났는데 촬영 일정 잡는게 쉽지가 않네요 ㅠㅠ 올 하반기에 꼭 출시했었어야 하는데 이미 12월이라니... 강의 출시하게 되면 소식으로 먼저 안내 드리겠습니다!

2.3 Elastic Load Balancer ↔️ EC2

안녕하세요! 좋은 질문 감사합니다TL;DR 하자면 이해하신 바가 100% 맞습니다. 보안상 Private Subnet에 어플리케이션을 두고 웹 트래픽은 Public Subnet에 있는 ELB로 받아서 연결하는게 맞습니다. 만약 Private Subnet에 있는 EC2에 ssh로 접근해야 한다면, 강의 후반부에서 안내 드리는 bastion을 활용하게 됩니다. 이름이 거창하지만 Private Subnet에있는 EC2에 연결하기 위해 사용하는 Public Subnet에 위치한 EC2입니다, 비용이 걱정된다면 bastion은 항시 운영할 필요는 없으니 필요할 때만 on/off를 진행하는 방식으로요. bastion을 활용하는 이유는 소스코드에 접근을 어렵게 하기 위함이라고 보시면 됩니다. 개인적으로 보안 전문가는 아니지만 해커가 뚫으려고 하면 언제든 뚫릴 수 있다고 생각하는데요, 그래서 다양한 layer를 두고 뚫리는데 오래 걸리게 서비스를 구성하는 것이 가장 현실적이라고 생각합니다. 따라서 bastion이 털리더라도 소스코드는 안털릴 수 있기 때문에(bastion에 ssh key를 두는게 아니라면요) 조금 더 보안 측면에서 유리하게 서비스를 운영할 수 있습니다