모델 파인튜닝을 멈추세요. 문제는 아키텍처입니다.
데모는 훌륭해 보입니다. 하지만 프로덕션 시스템은 다릅니다. 그 사이에는 간극이 존재합니다.
요즘 사람들은 모든 것을 에이전트라고 부릅니다. 메모리가 있는 챗봇도 에이전트이고, 루프가 있는 스크립트도 에이전트라고 합니다. 이러한 오해는 엔지니어링 오류를 야기합니다. 결국 단순한 작업에는 과도한 설계를 하고, 복잡한 작업에는 설계를 미흡하게 하게 됩니다.
에이전트에게는 목표가 필요합니다. 단순히 지시를 따르는 것이 아니라, 다음에 무엇을 할지 스스로 결정해야 합니다. 실패를 처리하고, 언제 멈춰야 할지도 알아야 합니다.
다음 규칙을 사용하여 시스템을 점검해 보세요:
- 사람이 매 단계마다 가이드를 주어야 한다면, 그것은 채팅 인터페이스입니다.
- 도구 호출(tool call) 실패 시 스스로 복구한다면, 그것은 에이전트입니다.
- 목표를 하위 작업으로 분해한다면, 그것은 진정한 에이전트입니다.
성공적인 팀은 새로운 모델을 쫓지 않습니다. 대신 좁고 명확한 목적을 가진 파이프라인을 구축합니다. 이들은 다음 세 가지에 집중합니다:
- 도구 설계: 인터페이스가 얼마나 깔끔한가?
- 실패 처리: 도구가 아무것도 반환하지 않을 때 어떤 일이 발생하는가?
- 관측 가능성(Observability): 모든 결정을 추적할 수 있는가?
사용하는 프레임워크보다 중요한 것은 설계 패턴입니다. 저는 다양한 프레임워크에서 아키텍처를 재구축해 보았지만 결과는 항상 같았습니다. 프레임워크는 비계(scaffolding)일 뿐이며, 아키텍처가 실제 건물입니다.
다음 패턴을 따르세요:
- 계획 후 실행. 추론을 위한 단계와 실행을 위한 단계를 분리하세요.
- 검색(retrieval)과 추론을 분리하세요. 컨텍스트를 가져오는 것과 컨텍스트를 사용하는 것은 서로 다른 작업입니다.
- 명시적인 핸드오프(handoff)를 사용하세요. 한 에이전트가 다른 에이전트에게 작업을 넘길 때는 구조화된 로그를 사용해야 합니다.
RAG는 표준이지만, 청킹(chunking) 방식이 잘못된 경우가 많습니다. 문서를 제대로 나누지 못하면 모델은 컨텍스트를 잃게 됩니다. 이는 환각(hallucination) 현상을 유발합니다.
RAG 파이프라인이 쓸모없는 결과를 반환한다면, 청킹과 메타데이터를 살펴보세요. 임베딩 모델을 탓하지 마십시오.
엔지니어링의 과제는 신뢰할 수 있는 시스템을 구축하는 것입니다. 거버넌스, 관측 가능성, 그리고 신뢰할 수 있는 도구 사용에 집중하세요. 단순히 벤치마크 점수만 쫓지 마십시오.
최고의 엔지니어는 시스템 설계에 집중할 것입니다. 그들은 다른 사람들이 유지보수할 수 있고 신뢰할 수 있는 AI 시스템을 구축할 것입니다.
출처: https://dev.to/aibughunter/stop-fine-tuning-your-model-your-architecture-is-the-problem-3kkg