OpenAI Tech Blog를 보면서 느낀점
최근에 업무 워크플로우를 쪼개서 어디에 가장 많이 시간을 할당하는지 측정하고 있었고, 스스로 일하는 방식을 완전히 바꿔보는 테스트를 하던 와중에 OpenAI 사내 데이터 에이전트에 대한 테크 블로그가 올라왔다.
(원문) Inside OpenAI’s in-house data agent
이 글은 작가의 Linkedin 에서도 확인할 수 있습니다.
글을 읽다가 정말 공감되는 문구를 발견했는데, 그 이유는 아래와 같다. 이젠 정말 AI와 함께 협업하는 AI-Native가 되지 않으면 살아남을 수 없는 시대가 되었다.
We have a lot of tables that are fairly similar, and I spend tons of time trying to figure out how they’re different and which to use. Some include logged-out users, some don’t. Some have overlapping fields; it’s hard to tell what is what.
(1) 조직 문화, 조직의 Tribal Knowledge는 많은데, 이를 새롭게 적립한다는 건 사실상 불가능하다.
(2) 데이터 실무자는 비슷한 테이블들 사이에서 차이를 파악하느라 시간을 많이 쓴다.
(3) 마찬가지로, AI에게 학습시키려 해도 데이터가 비슷비슷해서 구분이 어렵다.
(4) 이 고민은 OpenAI, 그리고 데이터 조직뿐만 아니라 모든 조직의 고민인 것 같다.
(5) 제품과 고객은 늘 변하는 상황에서, Tribal Knowledge를 AI가 학습할 수 있는 구조화된 지식으로 바꾸는 과정이 필요하다. 아래 OpenAI Data Agent가 제안한 6단계 처럼
① Table Usage : 스키마 메타데이터 + 테이블 lineage로 테이블 간 관계 파악. 과거 쿼리 이력을 학습해서 어떤 테이블이 함께 JOIN되는지, 어떻게 쓰이는지를 이해
② Human Annotations : 도메인 전문가가 작성한 테이블/컬럼의 의미와 주의사항. 메타데이터만으로는 테이블을 구분할 수 없고, 어떻게 만들어졌고 어디서 유래했는지 파악
③ (중요) Codex Enrichment : 단순히 메타데이터만 넣는 게 아니라, 코드베이스에서 코드를 뜯어 실제 의도와 생성 로직까지 파악해 Nuance를 파악해서 비슷해 보이지만 실제로 다른 테이블을 구분
④ Institutional Knowledge : 조직에 축적된 문서 검색. 프로젝트 코드명, 출시 이력, 지표의 표준 정의 등 사내 지식을 연동
⑤ Memory : 사용자의 피드백을 통해 에이전트가 받은 교정이나 발견한 뉴앙스를 저장해서 다음에 반복하지 않음 (쓸수록 똑똑해지는 flywheel)
⑥ Runtime Context : 기존 정보가 부족하거나 오래된 경우, 데이터 웨어하우스에 실시간 쿼리를 날려 스키마를 검증하고 실시간 데이터를 확인