𝗧𝗵𝗲 𝗛𝗼𝘁𝘁𝗲𝘀𝘁 𝗔𝗜 𝗙𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸 𝗥𝗶𝗴𝗵𝘁 𝗡𝗼𝘄 𝗛𝗮𝘀 𝗮 𝗙𝗮𝘁𝗮𝗹 𝗙𝗹𝗮𝘄
요즘은 모든 것을 에이전트라고 부릅니다.
도구를 호출하는 함수가 에이전트입니다. 메모리가 있는 챗봇이 에이전트입니다. 루프가 있는 스크립트가 에이전트입니다. 이것은 잘못된 생각입니다.
명확한 정의가 없으면 단순한 작업은 과하게 설계(over-engineer)하고, 복잡한 작업은 부실하게 설계(under-engineer)하게 됩니다. 단 하나의 좋은 프롬프트만 있으면 되는 워크플로우에 에이전트 오케스트레이션(agentic orchestration)을 구현하느라 몇 주를 허비하는 팀들을 보곤 합니다.
에이전트에게는 단순한 지시가 아니라 목표(objective)가 필요합니다. 에이전트는 다음에 무엇을 할지 스스로 결정합니다. 실패를 처리합니다. 작업이 완료되었을 때를 압니다.
- 사람이 시스템에 모든 단계를 일일이 알려준다면, 그것은 채팅 인터페이스일 뿐입니다.
- 시스템이 실패한 도구 호출로부터 스스로 복구한다면, 제대로 나아가고 있는 것입니다.
- 시스템이 목표를 하위 작업(subtasks)으로 분해한다면, 그것이 진짜 에이전트입니다.
대부분의 성공적인 에이전트는 특정 분야에 특화되어 있습니다(narrow). 한 가지 일을 잘 해냅니다. 고객 지원이나 문서 추출을 처리합니다. 범용 추론 엔진이 아닙니다.
성공적인 팀은 다음 세 가지 영역에 집중합니다:
- 도구 설계(Tool design): 인터페이스가 얼마나 깔끔한가?
- 실패 처리(Failure handling): 도구가 아무것도 반환하지 않을 때 어떤 일이 벌어지는가?
- 관측 가능성(Observability): 에이전트가 왜 그런 결정을 내렸는지 추적할 수 있는가?
아키텍처를 바꾸지 않은 채 모델만 교체하며 더 나은 결과를 기대하는 팀은 실패할 것입니다.
LangChain이나 CrewAI 같은 프레임워크보다 패턴이 더 중요합니다. 패턴은 도구와 상관없이 작동합니다.
다음 패턴들을 활용하십시오:
- 계획 후 실행(Plan then execute): 계획을 세우는 단계와 실행하는 단계를 분리하십시오.
- 검색과 추론의 분리(Separate retrieval from reasoning): 데이터를 가져오는 것과 데이터를 사용하는 것은 서로 다른 작업입니다.
- 명시적 인수인계(Explicit handoffs): 한 에이전트가 다른 에이전트에게 작업을 넘길 때 구조화된 로그를 사용하십시오.
프레임워크는 비계(scaffolding)일 뿐입니다. 아키텍처가 본 건물입니다.
RAG 또한 실패의 원인이 됩니다. 대부분의 사람들이 청킹(chunking)을 잘못하고 있습니다. 문서를 제대로 나누지 못하면 모델은 문맥(context)을 놓치게 됩니다.
RAG가 정확하지만 쓸모없는 결과를 반환한다면, 청킹이나 메타데이터를 수정하십시오. 임베딩 모델을 탓하지 마십시오.
벤치마크를 쫓는 일을 멈추십시오. 신뢰할 수 있는 시스템을 구축하는 데 집중하십시오. 거버넌스, 관측 가능성, 그리고 신뢰할 수 있는 도구 사용에 집중하십시오.
중요한 엔지니어는 다른 사람들이 유지보수할 수 있는 시스템을 만드는 사람입니다. 이것은 모델 연구가 아니라 시스템 설계(systems design)입니다.
Source: https://dev.to/aibughunter/the-hottest-ai-framework-right-now-has-a-fatal-flaw-nobody-mentions-3hd1
Optional learning community: https://t.me/GyaanSetuAi