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

안녕하세요! 좋은 질문 감사합니다.말씀하신 것처럼 도구 하나를 사용하는 에이전트라면 멀티에이전트 시스템으로 구축하는 것이 오버엔지니어링이 될 수 있습니다. 저는 강의다보니 다양한 유즈케이스들을 보여드리고 싶어서 그렇게 구현했다고 보시면 좋을 것 같습니다. 다만 해당 에이전트만 활용할 수 있는 도구가 추가될 가능성이 있다면 도구를 하나만 사용하더라도 별도의 에이전트를 구축하는 편이 확장성에 용이할 수도 있습니다. 예를 들면 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를 두는게 아니라면요) 조금 더 보안 측면에서 유리하게 서비스를 운영할 수 있습니다

3.6 강의 관련 질문(interrupt 관련)

안녕하세요, 저는 처음 보는 에러인데요, 첫번째 스크린샷을 보시면 duckduckgo에서 RateLimitError 라는 에러가 발생하는데, 에러가 발생해서 다시 컨펌을 받는게 아닌가 싶기도 합니다. 말씀하신 것처럼 small_llm에서 에러가 발생한다면, 모델이 처리하기에 조금 더 어려운 Task가 아니었나 생각합니다. 아니면 llm 이 바로 답변을 한다고 했을 때, small_llm은 한 번 더 확인을 받고자 하는게 아닌가 싶기도 하구요. 아마도 무한루프의 오류라기 보다는 모델의 특성으로 보시는게 더 좋을 것 같습니다. 추가로 실제 서비스에서 위와 비슷한 내용을 구현하신다고 한다면 사용자에게 나가는 답변을 생성하는 중요한 단계이니 가급적이면 큰 모델을 활용하시는 걸 추천합니다.

그래프 구현 조언 부탁드립니다!

안녕하세요! 좋은 질문 감사합니다. 저도 말씀하신 것처럼 나눠서 구현하는게 좋다고 생각하고, 만약 routing이 문제라면 routing용 supervisor routing agent를 두고 어떤 에이전트를 활용할지 결정하는 방향으로 일단 시작해보시면 좋을 것 같습니다!

3.2 from langchain.chains ~ 에서 모듈을 찾지 못할 때.

공유 감사합니다! 3강 시작하시기 전에 보는게 좋을 것 같아서 3.1강에 적어두었는데 눈에 잘 안들어오는 것 같네요 ㅠㅠ https://inf.run/6rKNN

첫번째 강의 화면과 설명이 안 맞는 거 같아요

어떤 부분이 안맞는다고 생각하시나요?