Amazon Bedrock AgentCore Web Search: 프로덕션 에이전트를 망치는 7가지 실수
2024년, 대부분의 AI 팀은 실수를 저질렀습니다. 바로 정적 데이터에 의존하는 RAG 파이프라인을 구축했다는 점입니다.
정적 RAG 파이프라인은 인터넷을 찍은 사진과 같습니다. 사진을 찍는 순간 이미 과거의 정보가 되어버립니다. AWS는 Amazon Bedrock AgentCore의 Web Search 기능을 통해 이 문제를 해결했습니다.
이 도구를 사용하면 검색 인프라를 직접 구축하지 않고도 에이전트가 실시간 데이터를 사용할 수 있습니다. 하지만 많은 팀이 배포 과정에서 실패를 겪습니다.
반드시 피해야 할 7가지 실수는 다음과 같습니다:
RAG의 대체제로 웹 검색을 사용하는 것. 웹 검색은 최신 뉴스나 가격 정보를 위한 것입니다. RAG는 회사의 내부 문서를 위한 것입니다. 라우터(router)를 사용하여 각 쿼리에 맞는 경로를 선택하세요.
Bedrock Guardrails가 웹 검색까지 커버할 것이라고 가정하는 것. 그렇지 않습니다. 웹 검색은 별도의 경로입니다. 도메인 허용 목록(allowlist)이나 PII(개인정보) 스크러빙과 같은 AgentCore 정책 제어 기능은 직접 설정해야 합니다.
멀티 에이전트 시스템에서 중복 검색을 실행하는 것. AutoGen과 같은 프레임워크에서는 모든 서브 에이전트가 검색을 개별적으로 호출할 수 있습니다. 이는 비용을 4배에서 8배까지 증가시킵니다. 대신 공유 검색 메모리(shared search memory)를 사용하세요.
'고착된 지식의 함정(Frozen Knowledge Trap)'을 간과하는 것. 모델이 오래된 답변을 내놓는다고 해서 모델을 탓하지 마세요. 문제는 데이터 아키텍처일 가능성이 높습니다. 답변이 매주 바뀐다면 실시간 검색이 필요합니다.
관측성(observability)을 생략하는 것. 에이전트가 환각(hallucination) 현상을 일으킨다면 그 이유를 알아야 합니다. 잘못된 검색 결과 때문이었는지, 아니면 모델의 오류였는지 확인해야 합니다. Langfuse를 사용하여 모든 단계를 추적하세요.
특정 엔드포인트에 맞춰 하드코딩하는 것. AWS는 이러한 도구들을 계속 업데이트할 것입니다. 제공업체를 쉽게 교체할 수 있도록 MCP 호환 도구 기술자(tool descriptors)를 사용하세요.
프롬프트 인젝션(prompt injection) 테스트를 누락하는 것. 오염된 웹페이지가 에이전트를 하이재킹할 수 있습니다. 서비스를 출시하기 전에 알려진 인젝션 페이로드로 에이전트를 테스트하세요.
프로덕션 환경에 적합한 에이전트를 구축하는 방법:
- 쿼리 의도를 분류합니다.
- RAG, 웹 검색 또는 메모리로 라우팅합니다.
- 웹 검색 결과를 정책 필터를 통해 통과시킵니다.
- 컨텍스트를 구성하고 모델을 호출합니다.
정적인 시스템 구축을 멈추세요. 실시간 기반의 근거 있는(grounded) 에이전트로 나아가야 합니다.
Optional learning community: https://t.me/GyaanSetuAi