커스텀 에이전트를 개선하기 위한 모범 사례

에이전트의 성능은 세 가지 요소에 따라 결정됩니다. 에이전트가 실행되는 모델, 트리거 및 범위 구성 방법, 지침 작성 방법입니다. 이 중 하나를 조정하면 에이전트의 안정성, 일관성, 비용 효율성이 향상될 수 있습니다.

이 가이드에서는 다음을 단계별로 안내해 드립니다.

• 작업에 적합한 모델 선택

• 에이전트의 트리거 및 범위 제어

• 에이전트가 스스로 디버깅하고 최적화하도록 허용하기

Product Scout는 내부 제품 질문에 답변하기 위해 만들어진 커스텀 에이전트입니다. 이 에이전트의 역할은 문서와 과거 대화에서 정보를 가져와서 "X 기능이 일괄 내보내기를 지원하나요?"와 같은 질문에 대해 팀원들이 빠르고 정확한 답변을 얻을 수 있도록 돕는 것입니다.

현재 Product Scout는 Slack 채널의 모든 메시지에서 트리거되고, 전체 워크스페이스에서 맥락을 검색하며, 사용할 수 있는 가장 강력한 모델에서 실행됩니다. 효과는 있지만, 눈에 띄는 세 가지 사항이 있습니다. 답변이 항상 일관적이지 않으며, 필요 이상으로 자주 실행되며, 비용을 절감할 여지가 있습니다. 이 가이드 전체에서 각 조정 사항이 실제로 어떻게 적용되는지 보여드리기 위해 이를 사용하겠습니다.

Notion을 사용하면 커스텀 에이전트가 실행되는 모델을 선택할 수 있으며, 이 선택은 비용에 영향을 미치는 가장 큰 요인 중 하나입니다. 목표는 사용할 수 있는 가장 강력한 모델을 선택하는 것이 아닙니다. 품질 기준을 충족하는 결과를 일관되게 제공하는 모델을 찾는 것입니다.

모델을 선택할 때 모델 선택기에서 각 옵션 위에 마우스를 갖다 대면 속도, 인텔리전스 기능, 비용을 비교할 수 있습니다.

일반적인 프레임워크는 다음과 같습니다.

• 자동을 사용하면 Notion이 각 요청에 가장 적합한 모델을 적용할 수 있습니다. 이것은 대부분의 에이전트에 권장되는 기본값입니다.

• 경량 모델은 반복적이고 위험이 낮은 워크플로(예: 일상적인 초안 작성, 간단한 라우팅 및 분류, 구조화된 콘텐츠 생성)에 적합합니다. 복잡한 추론보다 속도, 일관성, 비용 효율성이 더 중요한 경우 적합합니다.

• 강력한 모델(예: Opus)은 미묘한 글쓰기, 복잡한 추론 또는 높은 정확도가 필요한 작업에 가장 적합하지만 실행당 더 많은 크레딧을 사용합니다.

몇 가지 다른 모델을 테스트하여 품질 기준을 일관되게 충족하는 모델을 확인하세요. 작업이 복잡해짐에 따라 출력 품질이 떨어지는 경우 언제든지 더 강력한 모델로 전환할 수 있습니다.

Product Scout는 원래 사용할 수 있는 가장 강력한 모델에서 실행되었습니다. 그러나 관련 문서를 찾아 요약하는 핵심 작업에는 복잡한 추론이 필요하지 않습니다. 가벼운 모델로 전환하여 품질 저하 없이 비용을 절감했습니다.

에이전트의 트리거와 범위는 함께 작동합니다. 트리거는 실행 시점을 제어합니다. 범위는 에이전트가 읽는 내용을 제어합니다. 둘 중 하나가 너무 광범위하면 불필요하거나 관련 없는 출력 값을 생성하는 실행에 크레딧이 소모됩니다.

좋은 트리거는 유용할 만큼 빈도가 높고 필요할 때만 실행될 만큼 구체적입니다. 에이전트가 트리거될 때마다, 아무런 조치도 취하지 않더라도 크레딧이 사용됩니다. 에이전트의 도움이 실제로 필요한 순간에 트리거를 집중시키세요.

Product Scout의 설정에서, 답장, 반응, '감사합니다!'를 포함하여 #product-questions의 모든 메시지에서 트리거되었습니다. 이는 유용한 것을 생성하지 않는 실행에 크레딧이 소모되는 것을 의미했습니다.

먼저 에이전트가 개입해야 하는 시점을 정의하세요.

• 이 에이전트는 어떤 질문에 답변해야 할까요? 범위 내 질문 유형의 작은 세트를 정의하고 몇 가지 예시를 작성하세요.

• 무엇을 무시해야 할까요? 반응이나 '감사합니다', 일반적인 대화, 주제에서 벗어난 메시지는 실행을 트리거해서는 안 됩니다.

이러한 경계를 정의한 후에는 트리거를 일치하도록 조정하세요. 예를 들어, 트리거를 @멘션으로 제한하거나, 키워드로 필터링하거나, 모든 편집이 아니라 특정 속성 변경을 기준으로 트리거를 설정하세요.

Product Scout의 트리거를 @멘션으로 전환하면 누군가가 실제로 질문할 때만 실행됩니다.

에이전트는 사용 권한이 있는 모든 것을 읽습니다. 해당 범위가 광범위하면 관련 없는 많은 정보를 분류하게 되어 출력 품질이 저하됩니다.

Product Scout는 전체 워크스페이스와 연결된 모든 도구(마케팅 페이지, HR 문서, 이전 회의록, 관련 없는 채널의 몇 달간의 Slack 기록)를 검색했습니다. 이들 중 어느 것도 제품에 대한 답변을 포함하고 있지 않지만, 그럼에도 에이전트는 그것들을 읽고 있었습니다. 이는 더욱 불필요한 결과와 덜 일관된 답변을 의미했습니다.

내 에이전트의 범위를 생각하는 방법은 다음과 같습니다.

• 답변이 실제로 실행된 곳에서 시작하세요. 에이전트가 제품 관련 질문에 답하는 경우, 전체 워크스페이스와 연결된 모든 도구가 아닌 제품 문서 및 관련 Slack 채널에 연결하세요.

• '만일의 경우를 대비해' 맥락을 추가하지 마세요. 추가 페이지, 데이터베이스 또는 채널은 에이전트가 분류해야 하는 더 많은 콘텐츠입니다. 유용한 답변이 정기적으로 포함되지 않는 경우 제거하세요.

• 에이전트가 여전히 관련 없는 주제를 너무 많이 다루는 경우, 두 개의 집중 에이전트로 분할하세요. 제품 관련 질문과 청구 관련 문의를 모두 처리하는 에이전트는 두 가지 업무를 수행합니다. 범위가 좁은 두 개의 별도 에이전트를 사용하면 각 에이전트에서 더 나은 결과를 얻을 수 있습니다.

Product Scout의 범위를 제품 출시 데이터베이스와 #product-questions Slack 기록으로만 좁히면 에이전트가 어디에서 찾아야 하는지 더 명확하게 파악할 수 있습니다. 에이전트가 분류해야 하는 불필요함이 줄어들었기 때문에 답변이 더 일관적이 되었습니다.

첫 시도에서 바로 지침을 올바르게 작성할 필요는 없습니다. 지침을 개선하는 가장 빠른 방법은 커스텀 에이전트에 몇 가지 '나쁜' 출력 값을 보여주고 이를 다시 작성할 수 있도록 도움을 요청하는 것입니다.

간단한 워크플로는 다음과 같습니다.

• 에이전트의 답변이 너무 길었거나, 주제에서 벗어났거나, 너무 자신감이 넘쳤던 사례 3~5개를 수집하세요.

• 에이전트에게 무엇이 잘못되었는지 물어보세요. 범위가 너무 넓었는지, 답변 시점에 대한 규칙이 명확하지 않은지 확인하세요.

• 범위 내 질문 유형, '답변하지 않음' 규칙 또는 응답 템플릿을 추가하는개선된 지침을 제안하도록 하세요.

• 동일한 예시에서 새 지침을 테스트하고 이슈를 해결하는 최소한의 변경 사항을 유지하세요.

예를 들어, Product Scout가 관련 없는 HR 문서에서 가져온 응답을 붙여넣고 다음과 같이 지시할 수 있습니다. '이 답변은 제품 출시 외부 페이지를 참조했습니다. 이를 방지하려면 지침을 어떻게 업데이트해야 할까요?' 에이전트는 '제품 출시 데이터베이스의 페이지만 참조'와 같은 제한 사항을 추가하도록 제안할 수 있습니다.

각 피드백 라운드는 누락된 부분을 파악하는 데 도움이 되며, 작업을 진행하면서 지침이 더욱 명확해집니다.

Product Scout의 기존 지침은 광범위했습니다. '워크스페이스 콘텐츠를 사용하여 제품 질문에 답변하세요.' 몇 차례의 테스트와 피드백을 거친 후, 지침은 훨씬 더 명확해졌습니다. '제품 사양과 Slack 기록을 사용하여 답변하세요. 답변이 당사 문서에 없는 경우, 없다고 말하세요. 답변은 3단락 미만으로 작성하세요.'

팀에 에이전트를 배포하기 전에 설정 페이지 상단의 에이전트 실행하기 를 클릭하여 직접 테스트하세요. 팀이 실제로 묻는 종류의 질문을 해보고 에이전트의 답변 방식을 확인하세요.

이러한 사례가 다른 에이전트에서 어떻게 적용되는지 확인하려면 이 안내를 확인하세요.

최고의 커스텀 에이전트는 시간이 지남에 따라 모양이 갖춰집니다. 사소한 조정 각각이 누적되어 곧 안정성, 일관성, 비용 효율성이 향상된 에이전트를 갖게 됩니다.