Panorama

모든 프로젝트는 비즈니스와 시스템이 실제로 어떻게 돌아가는지 그리는 데서 시작해, 무엇을 지을 가치가 있는지 정한다. Panorama는 코드를 한 줄도 쓰지 않고 환경에 어떤 시스템도 세우기 전에, 무엇을 지을 가치가 있는지 분명히 하는 것이 목표라고 말한다. 이렇게 하면 지출이 잘못된 문제로 흘러가는 걸 막는다. 아무도 쓰지 않는 AI 기능에 이미 예산을 태운 팀에게 첫 단계가 바로 핵심이다. 작업에서 가장 싸게 정답을 낼 수 있는 부분이다.

Panorama는 검색을 데모 요령이 아니라 측정된 시스템으로 다룬다. 즉 청킹, 임베딩, 리랭킹, 하이브리드 검색을 차근차근 처리한다. 그런 다음 평가를 연결해 언제 나빠지는지 알 수 있게 한다. 겨냥하는 대상은 노트북에서는 멀쩡해 보였던 RAG 파이프라인이, 실제 질의가 돈 내는 사용자 앞에 도착하는 순간 빗나가는 팀이다.

이전 단계를 잊는 에이전트, 수만 토큰으로 부풀어 오르는 프롬프트, 잘못된 세부에 쓰이는 컨텍스트 윈도. 모두 모델에게 무엇을 보여주는가로 돌아간다. Panorama는 각 단계에서 그 입력을 설계한다. 공개된 한 사례는 프롬프트가 너무 커서 어떤 프런티어 모델도 받아들이지 못한 제품을 다룬다. 모델이 보는 것을 다시 짠 것이 그걸 돌아가게 만든 일이었다. 진짜 제약은 컨텍스트의 원시 크기가 아니라 신호 밀도였다.

추론 청구서는 사용량보다 빠르게 불어나기 쉽고, Panorama의 접근은 그 이유를 밝히는 것이다. 팀은 토큰이 어디로 가는지 분석하고, 라우팅, 캐싱, 배치 처리, 더 작은 모델로 비용을 줄인다. 한 사례에서는 반복적인 작업을 몇 달러로 학습한 오픈 모델로 증류했다. 호출당 비용이 16분의 1로 떨어졌다. 큰 차이다. 청구서가 오르고 있다면 볼 만하다.

모델은 뒤에 있는 데이터만큼만 좋다. 그리고 거의 모든 기업이 데이터는 넘치게 갖고 있다. 다만 모양이 틀렸을 뿐이다. Panorama는 그 데이터를 쓸 수 있게 만드는 파이프라인, 학습 세트, 평가 세트, 라벨링 시스템, 거버넌스를 구축한다. 화려하지 않은 일이다. 동시에 친절한 데모 밖에서 모델이 버티는지를 조용히 결정하는 층이기도 하다.

프롬프팅으로 부족해지면 Panorama가 다음 단계를 맡는다. 데이터 큐레이션, 학습, 평가, 배포, 지속적인 튜닝이다. 프롬프트 손질을 넘어선 팀, 교묘한 문구로만 작업을 이해하는 모델이 아니라 자기 데이터와 작업에 맞춰 빚은 모델이 필요한 팀의 길이다. 프롬프팅만으로는 어느 지점까지만 간다.

팀은 최종 상태를 납품이 아니라 파트너십으로 규정한다. 엔지니어는 만들어진 것을 이해하고 계속 확장해야 하며, 모델과 요구가 바뀌어도 팀은 연락 가능한 상태를 유지한다. 이는 AI에서 특히 중요하다. 기반 모델은 대부분의 소프트웨어보다 빠르게 변하고, 유지할 수 없는 시스템은 몇 달 만에 부채가 된다.