AI 요약관련 정보

• 특정 목적의 여러 AI 도구 대신, 파이썬이나 자바스크립트 평가기처럼 모든 것을 처리할 수 있는 단일 '우버 툴'을 사용하는 개념이 제시되었습니다. 💡
• 로컬 LLM(LM Studio, GBT OSS 20B)을 사용하여 기본적인 연산(숫자 합계)은 가능했으나, 파이썬의 경우 여러 시도 끝에 성공하는 등 한계를 보였습니다. 💻
• PostgreSQL 데이터베이스에서 데이터를 가져와 합산하는 실용적인 예시에서, 소형 LLM은 SQL SUM을 사용하거나 파이썬/자바스크립트 코드에 구문 오류를 발생시키는 등 '우버 툴' 접근 방식에 부적합했습니다. 📉
• '우버 툴' 접근 방식은 GBT OSS 20B와 같은 소형 모델로는 어렵고, Cloud Sonnet 4와 같은 강력한 '프론티어 모델'이 필요하다는 결론에 도달했습니다. 🚀
• 프론티어 모델과 함께 PostgreSQL 전용 도구(psql)로 데이터를 가져오고, 파이썬 평가기(pxpect)로 데이터를 처리하는 '30개 도구 + 1개 인터프리터' 방식은 성공적으로 작동했습니다. ✅
• PostgreSQL 도구를 비활성화하고 오직 pxpect만 사용하여 데이터베이스에 접근하려 했을 때, LLM은 pxpect를 통해 psql 명령어를 실행하려 시도하며 순수 우버 툴 접근 방식의 문제점을 드러냈습니다. 🚫
• pxpect가 단순히 명령어를 실행하는 역할만 한다면, 이미 파일 읽기/쓰기 및 명령어 실행이 가능한 에이전트 IDE가 있어 불필요하게 기존 도구를 재창조하는 비효율이 발생합니다. 🗑️
• 임의의 명령어를 실행하는 것은 통제 불능의 심각한 보안 문제를 야기할 수 있습니다. 🔒
• 순수 우버 툴 접근 방식은 오류, 출력 잘림, 시간 초과 등 일관성 없는 결과를 보이며 신뢰성이 떨어집니다. ⚠️
• 방대한 양의 코드와 데이터를 생성하고 파싱하는 과정에서 많은 토큰이 소모되어 비용이 매우 높으며, 현재 프론티어 모델의 보조금 정책이 장기적으로 유지되기 어려워 비용이 크게 증가할 것입니다. 💸
• 결론적으로, 데이터 처리를 위한 평가 도구 사용(30+1 모델)은 비생산 환경에서 합리적이지만, 모든 것을 단일 '우버 툴'로만 해결하려는 시도는 흥미롭지만 비현실적인 사고 실험으로 평가됩니다. 🤔