이 시리즈의 첫 3개 기사에 대한 놀라운 반응을 보고 4부까지 나오게 되었습니다.
이전 3개 기사에서는 대화 AI 에이전트의 성능 지표 정의, 계측 및 확장성에 대해 논의했습니다. 이전 기사를 확인하지 않은 경우 다음 링크를 참조하세요.
이 기사에서는 지속적으로 성능을 향상시키기 위해 이러한 측정항목을 보다 실행 가능하게 만드는 방법(최신 LLM 발전을 사용하여)에 대해 논의할 것입니다. 목표는 이 영역에서 작업하는 모든 사람을 위해 토론을 단순화하고 상당히 높은 수준으로 유지하는 것입니다.
사용자 인식 지표 와 사용자 보고 지표는 우리가 논의한 두 가지 상위 수준 지표 클래스입니다. 전통적으로 전자는 시스템 수준 측정항목으로 간주됩니다. 이러한 측정항목은 로그에서 직접 측정됩니다. 결과적으로 사용자 인식 지표는 본질적으로 실행 가능하며 작동 가능합니다.
운영 지표는 생산 로그에서 정기적으로 추적되며 팀 전체 OKR에 대한 목표 설정에 사용될 수 있습니다.
그러나 사용자 인식 지표는 조작하기 쉽지만 이는 "인식된" 지표이지 "실제" 사용자 지표가 아니라는 점에 유의해야 합니다. 결과적으로 이러한 지표를 높이 평가해도 대화형 AI 에이전트에 대한 사용자 인식이 크게 향상되지 않을 수 있습니다. 이러한 프로젝트가 여러 분기에 걸쳐 진행되는 경우 이로 인해 자원 관리가 비효율적으로 진행될 수 있습니다.
사용자 보고 지표를 통해 모든 성능 개선의 예상되는 영향을 직접 측정할 수 있는 방법이 필요합니다. 이것은 "북극성" 영향으로 취급되어야 합니다. 그렇다면 문제는 무엇입니까?
직접적인 사용자 피드백은 구조화되지 않아 실행 불가능하고 운영 방식이 다를 것으로 예상됩니다.
사용자가 보고한 상세한 피드백은 본질적으로 구조화되지 않아야 합니다. 사용자가 보고한 피드백이 구조화되면 결국 내부 팀이 이미 알고 있는 영역에 초점을 맞추게 될 수 있습니다. 이 외에도 사용자 보고 지표는 계절성 및 회사 인식과 같은 요인의 영향을 받습니다.
사용자 인식 지표 에 대한 영향은 더 정확하게 추정할 수 있지만 사용자 보고 지표에는 제어할 수 없는 요소가 많이 있습니다.
구조화되지 않은 사용자 보고 피드백은 실행 가능하도록 구조화된 형식으로 변환되어야 합니다. 구조화되지 않은 피드백을 기존 시스템 수준 지표로 변환할 목적으로 훈련된 특정 ML 모델이 있을 수 있습니다.
이러한 지표에 내재된 왜곡을 방지하기 위해 "최근" 사용자 지표 회귀에 대한 User Reported Metrics의 기본 목표를 사용하는 것이 더 실용적일 수 있다는 점에 유의해야 합니다. 보다 수평적인 장기 프로젝트 의 경우 이러한 측정항목을 사용하여 시스템 수준 측정항목과 함께 사용자 인식에 미치는 영향을 측정해야 합니다.
이제 우리가 찾고 있는 특정 지표에 대해 ML 모델을 훈련하는 데 필요한 노력은 무엇입니까? 최근 LLM의 인기와 가용성이 증가함에 따라 즉시 사용 가능한 API를 사용하여 구조화되지 않은 피드백을 시스템 수준 지표와 유사하게 추적하고 측정할 수 있는 것으로 변환하는 것이 가능할 수 있습니다.
LLM이 처리할 수 있는 토큰 수가 증가함에 따라 많은 제품별 정보가 "프롬프트" 자체의 일부로 제공될 수 있다는 점에 유의하는 것이 중요합니다. 결과적으로, 일부 신속한 엔지니어링과 함께 기성 LLM API는 실행 가능한 사용자 보고 지표를 제공할 수 있습니다.
이는 성능 개선 프로젝트의 우선순위를 정하는 데 유용할 수 있는 사용자 인식에 대한 시스템 수준 지표 개선 프로젝트의 영향을 평가하는 매우 빠른 방법을 제공합니다.
이러한 구조화된 사용자 보고 지표 접근 방식에도 불구하고 여전히 예상치 못한 변화의 여지가 있습니다. 그러나 특정 프로젝트(시스템 수준 지표 개선을 목표로 함)가 보고 지표에 긍정적인 영향을 미치는 경우 해당 프로젝트가 실제로 사용자 인식을 개선할 가능성이 높다고 어느 정도 확신을 갖고 가정할 수 있습니다.
그러나 실제로 "좋은" 모든 변경 사항이 항상 사용자 보고 지표를 효과적으로 개선한다는 보장은 없습니다. 따라서 성과 개선 프로젝트의 우선순위를 정하고 평가하려면 두 가지를 혼합하여 사용하는 것이 중요합니다.