Agentforce신뢰할 수 있는 에이전트 동작 달성을 위한 가이드

Olfa Kharrat, 제품 관리 이사 - Agentforce
Reinier van Leuken, 제품 관리 수석 이사 - Agentforce

신뢰는 1999년 설립 이래 새로운 클라우드 컴퓨팅과 SaaS 기술 모델을 개척하는 과정에서 Salesforce의 가장 중요한 가치로 자리 잡았습니다. 비즈니스는 귀중한 기업 데이터를 클라우드에 저장하여 Salesforce를 향한 신뢰를 보여줍니다. 이 데이터는 적절한 액세스 제어를 통해 안전하게 관리됩니다. 이는 여전히 중요한 개념이지만, 에이전트 AI 시대에는 신뢰의 정의가 훨씬 더 넓어졌습니다. 기업이 중요한 비즈니스 기능을 수행하는 데 자율 에이전트에 점점 더 의존하는 지금, 에이전트는 정확하고 관련성 있으며 무엇보다도 신뢰할 수 있는 비즈니스 파트너가 되어야 합니다.

그렇다면 어떻게 신뢰할 수 있는 에이전트를 구축할 수 있을까요? 일반적으로 동일한 입력을 제공할 때 같은 결과를 산출해야 안정성이 있다고 할 수 있습니다. 하지만 에이전트는 본질적으로 결정론적이지 않은 대규모 언어 모델(LLM)을 바탕으로 구동되기 때문에, 같은 입력에 다른 결과가 출력되기도 합니다. 이를 통해 에이전트는 접하게 되는 모든 조건이나 상황을 명시적으로 프로그래밍할 필요 없이 특정 상황에 따라 창의적인 맞춤형 솔루션을 개발할 수 있는 유동성을 갖게 됩니다. 하지만 에이전트는 비즈니스 요구 사항과 운영 가이드라인을 준수하기 위해 거버넌스도 필요로 합니다. 비즈니스 프로세스를 실행할 때는 안정성을 입증하고 결정론적인 제약 조건에 부합하는 비즈니스 성과를 창출해야 합니다. 결정론은 에이전트가 제공하는 자율성 및 유동성과 충돌하는 경직성과 규율을 부과합니다. 따라서 성공적인 에이전트를 생성하려면 창의적인 유동성과 엔터프라이즈 제어 간의 적절한 균형을 유지하는 것이 핵심입니다.

이 문서에서는 신뢰할 수 있는 에이전트를 개발하기 위한 주요 고려 사항에 대해 설명합니다. 에이전트 제어의 5가지 수준을 정의하고 각 수준에서 에이전트 동작을 제어하고 유지하는 모범 사례를 제시합니다. 지침은 Agentforce 추론 엔진이 작동하는 방식을 다룹니다. Agentforce의 발전에 따라 최신 모범 사례를 반영하여 문서가 업데이트될 예정입니다.

이 문서에서는 Agentforce 에이전트 설계 및 구축의 기본 사항에 익숙하다고 가정합니다. Agentforce 소개의 경우 다음을 권장합니다.

• agentforce.com에서 리소스를 검토하세요.
• 트레일 Agentblazer 챔피언되기 를 따라보세요. 이 트레일은 핵심 AI 개념을 살펴보고 주요 업무를 위한 기본 에이전트를 구축하는 데 도움을 줍니다.
• Agentforce에 대한 자세한 정보는 help.salesforce.com , 특히 에이전트 설게 및 구현 에서 확인하세요. 이 학습 맵은 솔루션 구상, 에이전트 설정 및 구성, 테스트, 배포 및 모니터링부터 모든 주요 수명 주기 단계를 안내합니다.

에이전트 동작을 더 효과적으로 이해하고자 먼저 에이전트와 보다 경직된 모델인 챗봇을 비교해 보겠습니다.

챗봇: 엄격한 규칙 추종

챗봇은 사전에 정해진 결정 트리를 따라 대화에 참여합니다. 이러한 결정 트리의 통과는 사용자가 제공한 답변을 기반으로 합니다. 답변은 사전 결정된 옵션 세트로부터 선택될 수도 있고, 자유 텍스트 답변일 수도 있습니다. 자유 텍스트 답변의 경우 의도 분류에 예측 모델이 사용됩니다. 이러한 트리는 모든 잠재적인 대화 경로를 매핑하고 각 단계에서 챗봇의 응답을 지시합니다. 챗봇의 동작은 사전 설정된 규칙에 따라 엄격하게 결정됩니다. 사용자의 입력이 인식된 경로와 일치하지 않거나 예측 모델이 특정 의도를 인식하도록 훈련되지 않은 경우, 챗봇이 적절하게 응답하지 않습니다.

에이전트: 직관적인 적응형 모델

반면 에이전트는 자연어 처리(NLP)에서 LLM의 강력한 힘과 고급 기능을 활용합니다. LLM을 통해 에이전트는 사용자 입력이 예상치 못한 방식으로 표현된 경우에도 이면의 의도를 알아차릴 수 있습니다. 의도에 대한 이해를 바탕으로 에이전트는 다양한 가능성 중에서 가장 적합한 작업을 선택할 수 있습니다. 에이전트는 완전히 새로운 응답을 공식으로 만들어 내기까지 합니다. 이러한 유연성과 적응성은 에이전트를 챗봇과 차별화합니다.

요리를 활용한 비유

챗봇과 에이전트의 다른 점은 초보 요리사와 숙련된 요리사의 차이에 비유할 수 있습니다.

• 초보 요리사(챗봇)는 정확한 측정, 단계별 명령, 특정 조리 시간이 나와 있는 상세한 레시피에 크게 의존합니다. 레시피를 지키지 못하면 요리를 망칠 수도 있습니다. 마찬가지로 챗봇은 사전 프로그래밍된 결정 트리의 범위 내에서 작동해야 합니다.
• 숙련된 요리사(에이전트)는 수년간의 요리 경험과 직감을 가지고 있습니다. 고객 선호도에 대한 전반적인 이해와 사용 가능한 재료에 대한 간략한 정보를 바탕으로, 고객의 요구를 만족하는 맛있는 식사를 준비할 수 있습니다. 정확한 단계는 매번 다를 수 있으며, 요리를 할 때마다 미묘한 차이가 있을 수 있지만, 전반적인 결과물은 일관되게 만족스럽습니다. 마찬가지로 에이전트는 사용자 입력의 컨텍스트와 의도에 따라 접근 방식을 조정하여 성공적인 상호 작용을 이루어낼 수 있습니다.

요약하자면, 에이전트와 챗봇의 근본적인 차이점은 적응성과 예상치 못한 입력을 처리할 수 있는 능력에 있습니다.

에이전트 인텔리전스의 뚜렷한 특징은 적시에 가장 적합한 작업을 조율하고 트리거하는 능력에 있습니다. 이러한 유연성 덕분에 가능한 사용자 상호 작용을 하나하나 광범위하게 프로그래밍할 필요가 없습니다.

Agentforce에서 에이전트 구축에는 주제, 작업, 자연어 명령 및 설명이 포함됩니다.

주제

주제는 에이전트가 '해야 할 일'입니다. 주제에는 분류 설명, 범위, 명령과 같은 특성이 있어 각 작업과 수행 방법을 정의합니다. 주제에는 에이전트가 실행할 수 있는 작업과 이러한 작업의 실행 방법을 규율하는 명령이 포함되어 있습니다.

조치

작업은 에이전트가 업무를 완수하기 위해 수행할 수 있는 사전 정의된 작업입니다. 작업에는 5가지 유형이 있습니다.

• Apex 코드 실행
• API 호출
• 플로 실행
• 프롬프트 템플릿에 대한 LLM 응답 수신
• 예측 모델 호출

자연어 명령 및 설명

에이전트의 정의에는 에이전트의 자산을 설명하고 에이전트가 작동해야 하는 가이드라인을 정의하는 자연어 명령이 포함되어 있습니다. 명령은 작업 및 주제에 대해 작성됩니다.

• 작업. 작업에는 다음이 포함됩니다.
  • 작업의 기능을 설명하여 추론 엔진에 이 작업을 언제 실행할지 알려주는 명령
  • 에이전트가 준비할 수 있도록 자연어 설명이 포함된 입력
  • 서식을 지정하고 사용하는 방법에 대한 자연어 설명이 포함된 출력
• 주제. 주제에는 상위 수준에서 작업을 실행하는 방법을 규율하는 명령이 포함되어 있습니다. 예를 들어, 명령으로 목소리 톤, 원하는 작업 순서, 가능한 전제 조건, 대화를 사람에게 에스컬레이션해야 하는 시기 등에 대한 가드레일을 지정할 수 있습니다. 주제에는 분류 설명과 범위 설명도 포함되어 있습니다. 에이전트는 이를 통해 정의된 역할의 범위 내에서 업무를 수행할 수 있습니다.
• 데이터. 에이전트가 업무를 성공적으로 수행하려면 데이터가 필요합니다. 데이터는 CRM 데이터와 같이 정형적일 수도, 기업의 기술 문서처럼 비정형적일 수도 있습니다. 에이전트는 작업 입력을 사용하여 데이터에 액세스합니다. 예를 들어, 작업은 CRM 데이터에 기반하거나 검색 증강 생성(RAG) 기술을 사용하여 비정형 데이터 청크로 증강된 프롬프트 템플릿을 호출할 수 있습니다.

이렇듯 다양한 구성 요소를 올바르게 구축하면 에이전트가 적절한 경계 내에서 작동하면서 의도한 목적을 수행하는 데 도움이 됩니다.

Agentforce 추론 엔진은 이러한 구성 요소를 올바른 에이전트 동작으로 조율하며, 주제와 작업에 대해 정의된 자연어 명령과 설명을 활용합니다. 추론 엔진은 2022년에 Yao et al이 도입한 LLM의 새로운 추론 패러다임인 ReAct를 기반으로 구축되었습니다. 이 패러다임은 문제에 대해 추론하고, 조치를 취하고, 작업의 결과를 관찰하고, 작업 완료까지의 주기를 반복하여 사람이 수행하는 작업 관리를 모방합니다.

Salesforce 에이전트는 다음 패러다임을 준수합니다.

1. 추론: 사용자 의도를 파악하고 올바른 주제 및 작업과 일치시킵니다.
2. 행동: 올바른 작업 체인을 시작합니다.
3. 관찰: 사용자 의도에 따라 작업 결과를 평가합니다. 의도가 충족되지 않으면 지금까지 얻은 결과와 주제/작업 명령 및 설명을 바탕으로 판단을 내립니다. 의도가 충족되면 서식 지정 명령을 최대한 준수하면서 최종 응답을 제공합니다.
4. 반복: 최종 지시 단계에 도달할 때까지 단계를 반복합니다.

추론 엔진은 모든 추론 시 LLM을 사용하고 단계를 관찰합니다. 작업 유형에 따라 행동 단계에서 LLM을 사용할 수도 있습니다.

이 섹션에서는 에이전트의 결정론을 개선하기 위한 계층화된 접근 방식을 간략하게 설명합니다. 각 수준은 이전 수준을 기반으로 구축되며, 복잡성과 기능이 갈수록 늘어나 에이전트 동작을 보다 효과적으로 제어할 수 있습니다.

첫 번째 수준에서는 에이전트가 관련 주제를 자율적으로 식별한 다음, 명시적인 명령이 아닌 목표를 사용하여 적절한 작업을 선택할 수 있도록 하는 데 중점을 둡니다. 핵심 메커니즘에는 맥락에 따른 이해를 바탕으로 사용자 입력에 응답하는 것이 포함됩니다. 기술적으로 모든 작업 유형을 추가할 수 있지만, 이 수준에서는 작업이 프롬프트 작업이라고 가정합니다. 프롬프트 작업이 포함된 명령이 필요 없는 주제는 일반적인 쿼리를 빠르고 효율적으로 처리할 수 있는 방법을 제공합니다.

이 수준에서는 동적 이해를 바탕으로 에이전트 응답성과 자율성의 기준 수준을 설정하는 데 중점을 둡니다.

명령이 필요 없는 작업 선택의 토대를 기반으로 구축된 이 수준에는 에이전트 동작을 안내하는 명시적인 명령이 도입됩니다. 정확한 명령을 추가하면 에이전트가 다양한 상황에 대응하는 방식을 더 효과적으로 제어할 수 있습니다. 에이전트에 대한 명령은 규칙, 가이드라인, 가드레일, 예시로 표현 가능합니다. 이를 통해 에이전트는 다양한 주제를 처리하고, 작업을 실행하고, 출력을 처리하는 방법에 대한 구체적인 지침을 얻을 수 있습니다. 이 수준의 목표는 에이전트에 명확한 지침을 제공하여 일관성을 높이고, 기업 가이드라인 및 프로세스 준수를 개선하는 데 있습니다.

그라운딩에는 에이전트의 이해와 응답을 외부 지식 소스에 연결하는 것이 포함됩니다. 그라운딩은 에이전트가 제공하는 정보가 더 정확하고 최신 상태이며 관련성이 높도록 하는 데 도움이 됩니다. 이 수준은 데이터베이스, 기술 자료 및 기타 정보 저장소에 대한 액세스를 통합합니다. 검증된 데이터에 에이전트의 응답을 그라운딩하면 안정성과 신뢰성이 향상됩니다.

이 수준에서는 에이전트가 변수를 사용하여 작업할 수 있는 기능을 추가합니다. 변수를 통해 에이전트는 상호 작용을 개인화하고, 여러 상호 작용에 걸쳐 컨텍스트를 유지하며, 에이전트 세션 중에 유지되는 특정 데이터 포인트에 따라 동작을 동적으로 조정할 수 있습니다. 가령 에이전트는 사용자 선호도, 주문 세부 정보 및 기타 관련 정보를 수집한 후 해당 데이터를 사용하여 상호 작용을 맞춤화할 수 있습니다. 변수를 통해 에이전트는 더 복잡하고, 보다 계획적이고, 한층 개인화된 상호 작용을 효과적으로 처리할 수 있습니다.

마지막 단계에서는 에이전트를 Salesforce의 핵심 기능인 Apex, API 및 플로와 통합합니다. 통합을 통해 에이전트는 Salesforce 에코시스템 내에서 데이터 액세스 및 조작, 워크플로 트리거, 다른 시스템과의 상호 작용 등 복잡한 작업을 수행할 수 있습니다.

• Apex는 프로그래밍 방식 제어를 제공합니다.
• API는 다른 애플리케이션과의 원활한 통합을 지원합니다.
• 플로를 사용하면 복잡한 비즈니스 프로세스를 자동화할 수 있습니다.

이 수준을 통해 에이전트는 정교한 업무를 실행하고 비즈니스 결과에 직접 기여할 수 있는 강력한 도구로 전환됩니다.

에이전트 응답성과 자율성의 기준부터 시작하여 해당하는 설명과 함께 주제와 작업으로만 구성된 에이전트를 고려합니다. 이 예제 에이전트를 사용하여 추론 엔진의 다양한 단계를 도입하고 이러한 설명을 활용하여 올바른 주제를 선택한 후 실행할 작업을 선택하는 방법을 보여줄 수 있습니다. 이 예제에서 주제 명령을 생략하면 첫 번째 수준의 에이전트는 상위 수준의 에이전트와 비교할 때 가장 자유도가 높다는 점을 확인할 수 있습니다. 수준 1에서 에이전트는 진행 중인 대화만을 바탕으로 적절하다고 판단되는 작업을 자유롭게 선택할 수 있습니다.

추론 엔진에 대한 다음 고려 사항을 검토합니다.

• 추론 엔진의 LLM에 대한 구성 설정이 수정되었습니다. 에이전트 빌더는 변경할 수 없습니다. 현재 OpenAI LLM은 추론 기능에 사용됩니다. 하지만 더 많은 모델이 추가되면서 변경될 수 있습니다.
• 추론 엔진 기본 기록: 추론 엔진에 요청이 이루어질 때마다(2~5단계), 가장 최근 요청과 응답 기록을 자동으로 검색합니다. 이렇게 하면 추론 엔진에 대한 대화 컨텍스트가 유지됩니다. 고객 상호 작용 외에도 플래너 LLM에 대한 호출에는 주제 선택과 같은 다른 요청을 해결하기 위한 추론 엔진 LLM으로의 호출도 포함됩니다.

추론 프로세스에는 4가지 주요 단계가 포함됩니다.

1. 주제 선택
2. 작업 선택
3. 에이전트 루프
4. 그라운딩 확인

주제는 에이전트가 올바른 작업 또는 작업 순서를 분류하는 정확성을 개선하도록 설계됩니다. 각 주제는 간결한 주제 설명에 포함될 수 있는 의미론적으로 구별되는 작업들로 이루어져야 하며, 결국 유사한 에이전트 기능에 속해야 합니다.

올바른 주제는 추론 엔진 LLM(다이어그램의 2~3단계)에서 선택합니다. 주제 프롬프트를 사용하여 분류 설명이 마지막 발화와 가장 가까운 주제를 선택합니다. 이 주제 프롬프트에는 모든 주제에 대한 분류 설명과 대화 기록이 포함되어 있습니다. 대화 기록에는 발화 및 에이전트 답변 외에도 실행된 작업과 그 결과가 포함됩니다. 나아가 프롬프트에는 대화 기록의 맥락 내에서 분석을 의무화하는 중요한 명령이 통합되어 있으며, LLM이 사고 프로세스를 공유하도록 요구합니다.

추가 고려 사항:

• '주제 외' 발화를 위한 추가적인 숨겨진 주제가 가시적인 주제와 함께 자동으로 존재합니다. 이 주제는 기존 주제가 발화와 일치하지 않을 때 선택됩니다. 이렇게 하면 에이전트가 오분류를 방지하는 데 도움이 됩니다. 이 주제에는 작업이 없습니다. 추론 엔진이 나중에 적절한 응답을 공식화하는 데 도움을 주기 위해서만 존재합니다.
• 주제 프롬프트에는 주제의 이름과 분류 설명만 사용됩니다.
• 추론 엔진 LLM은 한 번에 하나의 주제만 선택할 수 있습니다.
• 대화의 방향이 예기치 않게 틀어질 수 있습니다. 발화가 수신될 때마다 추론 엔진은 새로운 발화가 있을 때 최신 주제를 선택할 수 있는 주제 선택 단계로 넘어갑니다.

주제의 목적은 2가지입니다.

1. 작업을 그룹화하여 추론 엔진에 혼동을 줄 위험을 줄여 잘못된 작업이 선택되지 않도록 합니다.
2. 명령으로 작업 선택 및 실행을 안내합니다(자세한 내용은 수준 2: 에이전트 제어: 명령 추가에서 확인).

에이전트는 에이전트 기능을 관련 작업으로 이루어진 명확하게 정의된 주제로 신중히 구성하여 더 효과적이고 예측 가능하게 작동하며, 더 쉽게 업데이트하고 확장할 수 있습니다. 주제 설계에는 하향식과 상향식이라는 두 접근 방식이 있습니다.

• 하향식 접근 방식에서 주제는 먼저 에이전트가 수행해야 할 상위 수준의 작업으로 설계되고, 개별 작업은 해당 주제에 대해 정의됩니다.
• 상향식 접근 방식에서는 먼저 모든 개별 작업을 정의한 다음 주제로 그룹화합니다.

두 접근 방식 모두 적절하게 따르면 좋은 결과를 가져옵니다.

상향식 접근 방식

이 섹션에서는 상향식 접근 방법을 설명합니다. 상향식 접근 방법이 추론 엔진에서 처음부터 주제를 필요로 하는 이유와 밀접하게 연관되어 있기 때문입니다.

1단계: 모든 에이전트 작업 나열

먼저 에이전트가 수행할 수 있어야 하는 구체적인 작업을 모두 나열합니다. 이 단계에서는 너무 포괄적이기보다는 매우 구체적으로 정하는 편이 더 좋습니다. 작업을 조기에 그룹화하거나 간소화하려 하지 마세요. 에이전트가 할 수 있는 일에 대한 종합적이고 세분화된 보기를 만드는 것이 목표입니다.

예를 들어, 고객 서비스 에이전트의 경우 초기 목록에는 다음이 포함될 수 있습니다.

• 주문 반품: 주문에 대한 반품 프로세스를 시작하는 데 사용합니다.
• 재고 가용성 확인: 제품의 재고가 있는지 확인하는 데 사용합니다.
• 제품 교환 정책 확인: 교환 규칙에 대한 정보를 검색하는 데 사용합니다.
• 지식으로 질문에 답변: 일반적인 질문이나 FAQ 스타일의 질문에 답변하는 데 사용합니다.
• 프로모션 확인: 사용 가능한 프로모션이나 할인을 확인하는 데 사용합니다.
• 배송 날짜 예측: 예상 배송 날짜/시간을 추정하는 데 사용합니다.
• 주문 상태 확인: 고객 주문의 현재 상태를 찾는 데 사용합니다.
• 고객 주문 찾기: 특정 고객의 과거 또는 활성 주문을 모두 검색하는 데 사용합니다.
• 기술 문제 해결: 제품 또는 서비스의 기술적 문제를 해결하는 데 사용합니다.
• 고객 주문 조건 찾기: 주문과 관련된 모든 조건을 검색합니다.
• 고객 자산 찾기: 고객과 관련된 자산을 식별하거나 검색하는 데 사용합니다.
• 배송 주소를 변경합니다.

이 시점에서 '고객 불만 해결'과 같은 작업은 너무 광범위합니다. 작업은 에이전트 동작에서 가장 작은 세분화 수준을 나타내야 합니다. 불만 유형은 다양할 수 있으며, 이미 여러 작업에서 다루고 있습니다.

• 배송 후 문제(예: 손상되거나 오작동하는 제품 문제 해결)는 이미 '기술 문제 해결'에서 다루고 있습니다.
• 배송 전 문제(예: 배송 누락, 배송 날짜 변경 필요, 주문 수정)는 이미 '주문 상태 확인', '배송 날짜 예측' 또는 '주문 반품'과 같은 작업에서 다루고 있습니다.
• 정책 문의와 같은 일반적인 고객 우려 사항은 이미 '지식으로 질문에 답변' 또는 '제품 교환 정책 확인'에서 다루고 있습니다.

2단계: 추론 혼동을 일으킬 수 있는 작업 쌍 하나 이상 표시

추론 엔진에 혼동을 일으킬 수 있으므로, 본질적으로 유사한 작업을 표시합니다. 설명이 의미론적으로 충분히 다르지 않으면 추론 엔진이 5단계에서 어떤 작업을 선택해야 할지 알지 못합니다.

예를 들어, '기술 문제 해결'과 '지식으로 질문에 답변'은 비슷한 설명을 가지고 있지만, 기능은 크게 다를 수 있습니다. 이러한 의미론적 중복을 표시하면 여러 주제에 걸쳐 구분할 작업을 식별하는 데 도움이 됩니다.

3단계: 작업의 초기 그룹화를 주제로 생성

작업이 명확하게 정의되고 의미론적 중복이 식별되면 작업을 예비 주제로 그룹화할 수 있습니다. 주제는 기능의 논리적 범주, 즉 에이전트의 일관된 기능이나 기술을 나타내는 작업을 그룹화한 것입니다.

그룹화할 경우 다음에 유의하세요.

• 필요한 최소 주제 수를 사용하여 의미론적 중복을 방지합니다.
• 각 주제에 의미 있는 관련 작업이 포함되어 있는지 확인합니다.
• 체인에서 실행해야 하는 지원 작업이 동일한 주제에 있는지 확인합니다.

고객 서비스 에이전트를 위한 초기 그룹화의 예는 다음과 같습니다.

주제 1:

• 주문 반품
• 재고 가용성 확인
• 제품 교환 정책 확인
• 프로모션 확인
• 배송 날짜 예측
• 고객 주문 조건 찾기
• 주문 상태 확인
• 고객 주문 찾기
• 고객 자산 찾기
• 지식으로 질문에 답변
• 배송 주소 변경

주제 2:

• 기술 문제 해결
• 고객 자산 찾기

4단계: 주제에 대한 분류 설명을 작성하고 필요한 경우 주제를 세분화합니다.

초기 그룹화가 완료되면 각 주제에 대한 분류 설명을 작성합니다.

• 이 예제의 주제 2는 제품의 기술적 문제에 관한 것입니다.
• 하지만 주제 1은 더 넓은 범위를 다룹니다. 주로 주문 관리와 관련이 있지만, 프로모션 확인이나 지식으로 질문에 답변 등 주문 관리와 관련이 없는 일부 작업도 포함되어 있습니다. 주제 1은 한 문장으로 명확하고 간결하게 설명할 수 없으므로, 주제를 여러 주제로 나누어야 합니다.

나누고 나면 다음과 같은 결과를 얻을 수 있습니다.

• 주제 1: 주문 관리: 교환 및 반품과 관련된 작업을 제외한 고객 주문과 관련 물류의 관리 및 수정과 연관이 있는 작업을 설명합니다.
  • 재고 가용성 확인: 제품의 재고가 있는지 확인합니다.
  • 배송 날짜 예측: 주문이 언제 도착할지 예측합니다.
  • 주문 상태 확인: 고객 주문 상태를 찾습니다.
  • 고객 주문 찾기: 고객이 발주한 모든 주문을 검색합니다.
  • 배송 주소를 변경합니다.
• 주제 2: 문제 해결
  • 고객 자산 찾기: 고객의 등록된 디바이스 또는 제품을 검색합니다.
  • 기술 문제 해결: 기술 지원 또는 진단을 제공합니다.
• 주제 3: 교환: 주문 교환 및 반품과 관련된 작업을 설명합니다.
  • 주문 반품: 주문 반품 프로세스를 시작합니다.
  • 제품 교환 정책 확인: 제품의 교환 규칙을 제공합니다.
  • 고객 주문 찾기: 고객이 발주한 모든 주문을 검색합니다.
  • 고객 주문 조건 찾기: 주문과 관련된 모든 조건을 검색합니다.
• 주제 4: 제품 지원: 정보 검색 및 라우팅에 사용되는 교차 작업을 설명합니다.
  • 지식으로 질문에 답변: 기술 자료 정보를 사용하여 일반적인 고객 문의에 응답합니다.
  • 프로모션 확인: 현재 진행 중인 프로모션 또는 할인을 확인합니다.

요약하자면, 먼저 가능한 모든 작업의 종합적인 목록을 만든 후 작업 간의 의미론적 중복을 표시합니다. 그다음, 최소한 모든 의미론적 중복을 해소하는 일련의 주제를 생성하여 추론 엔진이 한 주제의 범위 내에서 혼동하지 않도록 합니다. 그런 다음 모든 주제의 분류 설명을 작성합니다. 주제의 범위가 너무 넓은 경우 더 세분화된 주제로 나눕니다. 이 지침을 구현하면 성능이 좋을 뿐만 아니라 유지 관리 및 확장이 용이한 에이전트를 구축할 수 있습니다.

이 구조는 에이전트의 동작 내에서 더 나은 추론, 더 정확한 실행, 더 명확한 결정 경계를 지원합니다. 나아가 설계자, 엔지니어, 분야별 전문가 간의 협업에 의존하여 에이전트의 기능을 더 투명하게 만들고 모듈화합니다.

효과적인 주제 생성을 위한 추가 고려 사항

• 최적의 주제 수: 올바른 주제를 분류할 때 LLM의 성능을 개선하려면 일반적으로 10개의 주제를 초과하지 않는 것이 좋습니다. 하지만 이는 어림짐작일 뿐입니다. 또한, 각 주제에 명확하고 뚜렷한 설명이 있어야 합니다. 궁극적으로 최적의 주제 수는 주제 분류 설명 간의 의미론적 간격에 따라 달라집니다. 주제 간에 분류 설명이 크게 다른 경우, 주제 중복의 위험을 최소화할 수 있습니다. 주제 간 중복을 방지할 수 있는 더 많은 모범 사례는 여기 에서 확인하세요.
• 주제 크기와 명확성의 균형: 일반적으로 주제가 사소할수록 작업과 명령 측면에서 분류가 더 쉬워지지만, 비슷한 설명으로 주제를 너무 많이 생성하면 작업 간에 의미론적 중첩이 오분류를 초래하는 등 혼란이 발생할 수 있습니다. 따라서 의미론적으로 명확하게 차별화된 주제 설명을 지정하는 것이 중요합니다. LLM을 사용하여 효과적으로 차별화된 분류를 생성할 수 있습니다.
• 표준 언어 및 컨텍스트 명확성: LLM은 특정 기업 또는 비즈니스적 의미와 약어를 인식하지 못할 수 있습니다. 표준어를 사용하거나 특정 문맥에서 단어의 의미를 명확하게 설명해야 합니다.
• 주제 프롬프트에는 주제 이름과 설명만 전송됩니다. 따라서 주제의 범위나 명령을 변경해도 주제 선택에 영향을 주지 않습니다.

활용 사례

서비스 에이전트가 시계에 대한 보증 정책 요청을 받았다고 상상해 보세요. 보증 문제가 제품 교환 또는 지원과는 관련이 없는 것 같고, 이 요청을 처리하기에는 주문 관리가 가장 적합한 주제인 듯합니다. 따라서 추론 엔진에서 요청을 이행할 가능성이 가장 높은 주제로 후자를 선택합니다.

주제를 선택한 후 추론 엔진이 선택한 주제에서 실행할 올바른 작업을 고릅니다. 다시 말하지만, 추론 엔진 LLM이 관찰 프롬프트라는 또 다른 프롬프트를 사용하여 이를 처리합니다. 관찰 프롬프트의 목적은 추론 프로세스의 다음 단계를 확보하는 것입니다. 다음 단계는 아래 중 하나일 수 있습니다.

• 작업 시작
• 사용자로부터 작업 입력 요청
• 사용자의 요청에 대한 명확한 설명 요청
• 작업 루프가 완료된 후 사용자에게 최종 답변 전송(사용자 요청 이행)(3단계 추론에서 자세한 내용 참조)

관찰 프롬프트에 대한 입력은 대화 기록과 주제의 작업 전체에 대한 모든 설명으로 구성됩니다.

작업 설계를 위한 모범 사례

작업은 에이전트가 업무를 완수하기 위해 수행할 수 있는 사전 정의된 작업입니다. 작업은 업무에 대한 가장 세밀한 정의입니다. 에이전트 작업에는 (1) Apex 코드 실행, (2) API 호출, (3) 플로 실행, (4) 프롬프트 템플릿에 대한 LLM 응답 수신, (5) 예측 모델 호출이라는 5가지 유형이 있습니다. 이러한 작업의 대부분은 결정론적일 수 있습니다. 예외는 프롬프트 템플릿에 대한 응답을 받는 것입니다(외부 시스템인 플로 또는 Apex 작업에 프롬프트 호출 등의 확률적 요소가 포함되어 있지 않은 경우에만 해당). 이러한 문제는 에이전트 제어의 다섯 번째 수준에서 다룰 예정입니다.

1. 프롬프트 작업에서 에이전트 동작 제어. 프롬프트 작업에서 에이전트의 동작을 제어하는 방법에는 2가지가 있습니다. (1) 프롬프트 엔지니어링을 통해 프롬프트 템플릿에 명령을 더 추가하는 방법과 (2) 프롬프트 응답, 특히 온도를 생성하는 LLM의 하이퍼 매개 변수를 구성하는 방법입니다(문서 참조). 온도를 낮추면 생성된 응답의 변동성이 줄어들어 반복성과 에이전트 안정성이 향상됩니다.
2. 단일 주제 내에서 최적의 작업 수: 최대 주제 수와 마찬가지로 주제 내 작업 수는 10개를 초과하지 않아야 합니다. 다시 말하지만, 이는 경험에 비추어 본 수치일뿐 실제 동인은 작업 간의 의미론적 간격입니다. 작업이 설명으로 명확하게 구별될 수 있다면 수치는 더 커질 수 있습니다. 하지만 의미론적 간격은 숫자로 측정할 수 없으며, 이는 에이전트 빌더의 해석에 달려 있습니다. 작업 설명 간의 의미적 차이가 클수록 의미론적 간격이 넓어집니다. 여기서는 항상 중복을 피해야 합니다.
3. 작업 설명: 이름과는 달리, '작업 명령'은 실제로 추론 엔진 LLM이 주제에서 올바른 작업을 선택하기 위해 사용하는 명령 역할을 합니다. 의미론적으로 고유한 작업 설명을 사용하면 분류의 품질을 크게 개선할 수 있습니다. 이러한 설명을 신중하게 검토하고, 특히 단일 주제에 속하는 모든 작업 설명을 비교해 보세요.

활용 사례

서비스 에이전트가 시계에 대한 보증 정책 관련 질문을 받은 이전 예제로 계속 진행해 보겠습니다. 주문 관리 주제를 고르면 가장 가능성이 높은 작업이 선택됩니다. 주문 관리에 관한 주제이므로, 첫 번째 논리적 단계는 주문 조회 작업을 실행하여 주문을 조회하는 것입니다(그렇지 않은 경우 보증 정보를 확인하려는 이유가 무엇인지 확인).

사용자 발화는 답변이 사용자에게 다시 전송되기 전에 여러 작업의 실행을 트리거할 수 있습니다. 이는 에이전트 루프 때문인데, 에이전트 루프는 아래의 조건 중 하나가 충족될 때까지 다음으로 가장 적합한 작업을 선택하고 실행합니다.

• 추론 엔진 LLM이 요청이 완료되었음을 확인합니다. 이 경우 사용자 요청이 응답으로 처리되었음이 확인됩니다. 여기에는 응답이 작업 출력에서 그라운딩되었는지 살펴보는 그라운딩 확인이 포함됩니다. 응답에는 추론 엔진 LLM에서 창조된 정보가 없어야 합니다. 이런 정보가 포함되면 환각이나 잘못된 응답을 초래할 수 있습니다.
• 더 이상 적합한 작업을 찾을 수 없습니다.
• 현재 단계에 허용되는 최대 LLM 호출 수에 도달했습니다. 이 수치는 추론 엔진 자체에서 설정됩니다.

작업에는 특정 시간 초과가 적용되지 않습니다. 이는 복잡성에 따라 작업 실행 시간이 달라질 때 중단을 방지하기 위함입니다. 어떤 작업은 다른 작업보다 실행하기가 더 복잡합니다.

활용 사례

주문 조회를 시작한 후 추론 엔진은 지금까지 생성된 응답을 평가한 다음, 사용자에게 응답을 다시 전송하기 전에 추가 작업을 수행해야 한다고 판단합니다. 이제 대화 기록에 주문이 표시되므로, 보증 정책을 확인하려고 합니다.

그러나 이 과정에서 에이전트는 '주문 조회' 작업을 통해 고객이 실제로 시계 2개를 구매했음을 알게 됩니다. 따라서 에이전트 루프에서 추론 엔진은 고객에게 보증 정보가 필요한 시계가 무엇인지 지정해 달라고 요청하기로 합니다.

초과 스크립팅 방지

에이전트가 사용자와 대화하는 방식을 과도하게 스크립팅하지 않도록 합니다. 초과 스크립팅은 에이전트가 관계를 구축하고, 고유한 사용자 요구 사항을 이해하고, 역동적인 상황에 효과적으로 실시간 대응하는 능력을 저해할 수 있습니다. 또한, 명령이 길어지면 에이전트의 응답 속도가 느려지고 추론 엔진에 혼동이 발생할 수 있습니다. 명령을 통해 결정론을 강제하는 것은 권장되는 접근 방식이 아닙니다.

하지 말아야 할 일

예를 들어, 에이전트를 대상으로 서비스 답변에서 경쟁사를 언급하지 말라고 지시할 필요는 없습니다. 이는 원치 않는 동작으로 이어질 수 있는데, 에이전트가 경쟁사인 제공업체와의 통합과 관련된 질문에 답변하지 않을 수도 있습니다. 이 대신, '경쟁사 관련 논의에서는 회사의 최대 이익을 고려하여 응답할 것'이라는 명령을 사용할 수 있습니다. 이렇게 하면 '...인 경우에만 경쟁사 xyz 언급'과 같은 제한적인 조건부 명령을 방지하고, 대신 LLM의 추론 기능을 활용하게 됩니다. 이 예제는 사람인 서비스 직원이 회사에 입사한 후 교육을 받는 방식과 유사하게 더 높은 추상적인 수준에서 명령을 제시하는 방법을 보여줍니다.

하지 말아야 할 일의 몇 가지 예를 더 살펴보겠습니다. 다음은 채용 웹사이트에서 지원자 프로필을 처리하는 서비스 에이전트를 대상으로 제공되는 몇 가지 잘못된 명령입니다. 이러한 명령은 가능한 모든 고객의 발화를 예측하려고 시도하므로, 피하는 것이 좋습니다.

명령 1: 에이전트가 다음과 같은 발화를 수신합니다. "제 프로필에 사진을 추가할 수 있나요?" 그런 다음 즉시 고객에게 "프로필 유형이 무엇인가요?"라고 묻습니다.

명령 2: 지원자가 프리미엄 프로필이라고 언급한 경우 "계약 세부 정보를 확인해 보겠습니다"라고 답한 후 계약 세부 정보를 검색하고 프로필 사진을 업데이트하는 데 동의했는지 확인합니다.

지원자가 이에 동의했다면 "예, 제가 대신 업데이트해 드릴 수 있습니다. 새로운 사진을 제공하시겠어요?”라고 대답합니다. 사진을 받으면 그에 따라 지원자의 프로필을 업데이트합니다. 계약 내용에 프로필 사진 변경이 포함되지 않은 경우 "죄송합니다. 작업을 처리할 수 없습니다. 사람 에이전트에게 연결해 드리겠습니다"라고 답합니다.

명령 3: 프리미엄이 아닌 프로필: 고객의 프로필이 프리미엄 프로필이 아닌 경우 "사진을 업데이트할 수 없습니다. 원하신다면 사람 에이전트에게 연결해 드리겠습니다"라고 응답합니다.

명령 4: 프로필 유형이 명확하지 않은 경우 "프로필 유형을 알 수 없습니다"라고 응답합니다.

대신 해야 할 일

세세한 것까지 전부 관리하는 대신, 에이전트의 동작과 행동을 지시하는 보다 유연한 접근 방식을 사용합니다. 다음 모범 사례를 고려하세요.

1. 기술 문서에 포함된 정책 및 규칙에 대해서는 명령으로 작성하지 말고 검색 증강 생성(RAG)/지식 작업을 사용하세요. 관련 정보가 적시에 검색됩니다. 위 예제에서, '사진 업데이트'라는 제목의 기술 문서에 다음과 같이 명시합니다. "계약 내용에서 사진 변경을 허용하는 프리미엄 프로필을 보유한 지원자만 사진을 업데이트할 수 있습니다."
2. 대화와 별개로 주요 지침과 가드레일을 개별적으로 요약합니다. 에이전트를 대상으로 문제의 예상 동작이나 절차에 대한 설명을 명확하고 간결하게 제공합니다.

이러한 모범 사례를 따른 더 나은 명령은 다음과 같을 수 있습니다.

명령 1 : “계정 변경 요청이 있을 경우 지식 작업을 사용하여 정책을 확인합니다.”

명령 2 : “관련 정책을 찾을 수 없는 질문에는 답변하지 않습니다.”

위의 지침을 적용하면 에이전트 결과를 개선할 수 있습니다. 이제 고객이 에이전트에 프로필 변경을 요청하면 에이전트는 기술 자료에서 필요한 정책을 검색하고, 검색된 규칙을 해석하고, 해당 규칙을 컨텍스트에 적용하고, 마지막으로 고객에게 응답해야 한다는 것을 이해하게 됩니다. 초과 스크립팅과 달리, 이러한 동작 접근 방식은 훨씬 더 일반적이고 광범위하게 적용 가능합니다. 에이전트는 가능한 모든 대화를 작성하지 않고도 더 광범위한 대화 주제에 원하는 동작으로 유연하게 대응할 수 있게 됩니다.

작업 순서 적용

관찰 프롬프트에는 명령과 작업 설명이 포함되어 있지만, 정의된 순서는 없습니다. 작업 순서가 중요한 경우 동일한 명령 내에서 명시적으로 언급해야 합니다.

채용 웹사이트 에이전트의 예를 계속 살펴보겠습니다. 에이전트는 적절한 면접관을 배정하여 면접 계획을 처리할 수 있어야 합니다. 그러려면 먼저 채용 담당자의 참여 가능 여부를 확인한 다음 지원자에게 가능한 3가지 옵션을 제안해야 합니다.

이 경우 실행 순서를 유지하려면 명령이 개별 상자에 있어서는 안 됩니다.

1. 명령 1: 면접관의 참여 가능 여부를 확인합니다.
2. 명령 2: 그런 다음 지원자에게 적절한 옵션을 제안합니다.

추론 엔진은 명령 2의 '그런 다음' 문구가 무엇을 지칭하는지 알 수 없기 때문에 명령이 작동하지 않습니다. 명령이 특정 순서가 아닌 그룹으로 추론 엔진에 전송되기 때문입니다.

이 대신 순서 정의 명령을 하나의 문으로 결합하고 다음과 같이 작성해야 합니다.

1. 명령 1: 면접관의 참여 가능 여부를 확인합니다. 그런 다음 지원자에게 적절한 옵션을 제안합니다.

재작성 없이 작업 출력 실행

추론 엔진은 그 자체로 LLM입니다. 에이전트 루프에 따라 최종 답변을 생성하는 역할을 합니다. 이 접근 방식은 응답 생성에 가드레일을 제공하는 에이전트 명령을 시행하거나 에이전트 루프의 일부였던 여러 작업의 출력을 결합하여 사용자 요청을 이행하는 데 필요합니다.

하지만 하나의 프롬프트 작업만 실행되었을 것으로 예상되는 경우, 에이전트에 작업 출력을 절대 변경하지 않도록 지시하는 명령을 내릴 수 있습니다. 이렇게 하면 에이전트 동작이 더 예측 가능하고 안정적으로 이루어집니다.

승인된 프롬프트 템플릿에 이러한 엄격한 준수를 적용하는 것은 특정 상황, 특히 일관성, 규정 준수 및 사전 정의된 메시지가 중요한 경우에 필수적입니다. 2가지 예는 다음과 같습니다.

• 규제 대상 산업: 규제가 엄격한 분야(예: 금융, 의료, 법률)에서 운영되는 조직은 모든 고객 응대 커뮤니케이션을 엄격하게 제어해야 하는 경우가 많습니다. 승인된 프롬프트 템플릿은 응답이 법률 및 규제 요건을 준수하도록 보장하여 잘못된 해석, 책임 또는 부정확한 정보의 유포 위험을 최소화합니다.
• 사전 테스트 및 검증된 응답: 프롬프트 템플릿이 정확성, 효율성 및 원하는 결과를 보장하기 위해 엄격한 테스트와 검증을 거친 경우로, 이러한 템플릿에서 벗어나면 그 효율성과 가치가 떨어질 수 있습니다. 엄격한 준수는 입증된 메시지가 일관되게 전달되도록 보장합니다.

이 명령은 에이전트가 작업의 출력을 변경할 수 있는 자유를 제한합니다. 이 플랜 트레이서에 나와 있는 대로 명령이 프롬프트 템플릿의 출력(예: 'promptResponse')을 참조하는지 확인하세요.

따라서 이 경우의 명령은 다음과 같을 수 있습니다.

“ 에이전트의 채널에 관계없이 promptResponse 출력을 변경하지 않습니다. ”

엄격한 준수 시행의 제한 사항:

상호 작용에 여러 개의 개별 에이전트 작업이 필요한 경우 단일 템플릿에 대해 엄격한 준수를 적용하기란 불가능합니다. 실제로 이러한 상황에서는 추론 엔진이 관련 작업을 단일 응답으로 통합하여 모든 단일 작업 출력을 변경해야 합니다.

최적의 명령 수

일반적인 LLM 특성을 바탕으로 대상 명령 수는 명령 복잡성과 명령 상호 작용에 따라 5개에서 10개 사이입니다. 이러한 명령 특성은 추론 엔진이 따를 수 있는 명령 수에 영향을 미칩니다.

• 명확성 및 구체성: 잘 정의된 규칙은 따르기가 더 쉽습니다.
• 규칙 간 충돌: 규칙이 서로 모순되는 경우 이를 해결하기 위해 추가 논리가 필요합니다.
• 길이 및 복잡성: 각 규칙에 심층적인 추론이 필요한 경우, 더 세분화된 명령으로 나누는 것을 고려하세요.

명령을 명시적으로 따르는 것이 매우 중요한 경우, 그 중요성을 반영하는 용어를 추가합니다.

• 긴급성 및 중요성(즉시, 긴급, 중요, 필수, 의무)
• 권한 및 실행(필수, 의무, 엄격하게 실행)
• 결과 및 경고(위반은 다음을 초래할 수 있음, 준수하지 않을 경우 다음을 초래할 수 있음, 미준수는 다음을 초래할 수 있음, 엄격한 처벌 적용, 무관용)
• 명확성 및 직접성(금지 필수, 금지, 허용 불가, 항상/절대)

데이터에 답변을 그라운딩하면 에이전트의 안정성과 신뢰성이 크게 향상됩니다. 그라운딩된 응답은 추측이나 오래된 지식이 아닌 사실에 입각한 정보를 기반으로 합니다. 검색 증강 생성(RAG)은 에이전트가 기술 자료에 액세스하고 이를 사용하여 더 정확하고 상황에 맞는 답변을 공식화할 수 있도록 널리 채택된 기술입니다. 사용자의 쿼리에 따라 에이전트는 검색 증강 생성(RAG)을 사용하여 해당 데이터 소스에서 관련 정보를 검색한 다음, LLM에 제출하기 전에 이 정보로 프롬프트를 보강합니다. 검색 증강 생성(RAG)을 사용하는 에이전트는 에이전트 상호 작용의 품질, 정확성 및 전반적인 유용성이 높아 사용자 신뢰도와 만족도를 개선합니다. 검색 증강 생성(RAG) 모범 사례는 공개적으로 사용 가능한 Agentforce 및 검색 증강 생성(RAG): 더 나은 에이전트를 위한 모범 사례 백서에 광범위하게 설명되어 있습니다.

지식과 명령 비교

지식과 명령의 구분은 지침과 유연성 사이의 적절한 균형을 맞추는 데 중요합니다. 이는 지식과 명령이 서로 다른 목적을 이행하기 때문입니다.

• 지식: 지식은 에이전트가 답변을 생성하면서 액세스할 수 있는 도서관이라고 생각하면 됩니다. 문서, 기술 자료, 백서 등이 그 예입니다. 여기에는 정책 및 일반 회사 규칙이 포함될 수 있습니다. 지식은 이메일, 통화 스크립트, (에이전트) 대화 기록과 같은 거래 파일도 참조할 수 있습니다. 마지막으로 지식에는 정형 데이터 형식의 긴 텍스트 필드가 포함됩니다. 지식은 일반적으로 검색 증강 생성(RAG)을 통해 에이전트에 전달됩니다.
• 명령: 명령은 에이전트에 각 작업을 언제 사용해야 하는지 명확히 알려주는 최소 규칙 집합이라고 생각하면 됩니다. 명령은 또한 필요한 어조와 같은 가드레일을 전체 대화에 할당할 수 있습니다. 명확성이나 의도를 그대로 살리면서 명령을 더 간결하고 유연하게 만들 수 있는 경우가 많습니다. 가능한 모든 고객 시나리오에 대해 구체적인 응답이 포함된 엄격한 스크립트를 제공하는 대신, 에이전트가 다양한 상황에서 적합한 작업을 선택하는 데 도움이 되는 일반적인 지침과 원칙을 구현하는 것을 고려하세요.

검색 증강 생성(RAG)

검색 증강 생성(RAG)은 지식을 위한 지능형 데이터 계층 역할을 합니다. 다양한 형식의 정보에 액세스할 권한을 에이전트에 부여하며 질문에 답변하기 위한 관련 텍스트 조각을 제공합니다. 검색 증강 생성(RAG)을 사용하면 에이전트가 불필요한 콘텐츠로 LLM 프롬프트에 과부하를 주거나 컨텍스트 창에 너무 많은 정보를 제공하지 않고도 더 정확한 LLM 응답을 얻을 수 있습니다.

런타임 시 검색 증강 생성(RAG)은 다음 세 단계를 실행합니다.

1. 검색: AI 시스템은 대규모 데이터베이스 또는 지식 소스를 검색하여 LLM 프롬프트에 대한 관련 정보를 수집합니다. 이는 기존 키워드 기반 검색에 비해 더 정교한 기술인 시맨틱 검색을 사용하여 수행됩니다. 정확한 용어와 일치시키는 키워드 검색과 달리 시맨틱 검색은 단어 이면에 숨겨진 의미나 맥락을 이해합니다. 정확하게 일치하는 단어를 찾기보다는 용어 간의 개념이나 관계를 기반으로 관련 정보를 식별합니다. 키워드 검색은 이 검색 프로세스에서도 중요한 역할을 하여 특정 용어나 이름과 일치하는 키워드로 시맨틱 검색을 강화합니다. 이 검색 유형을 하이브리드 검색이라고 합니다.
2. 증강: 검색된 정보가 프롬프트에 추가됩니다.
3. 생성: LLM은 검색된 지식으로 증강된 프롬프트 덕분에 상황에 맞는 적절하고 보다 정확한 응답을 생성합니다.

Agentforce에서 검색 증강 생성(RAG)은 프롬프트 템플릿과 함께 또는 독자적으로 사용할 수 있습니다.

1. 프롬프트 기반 검색 증강 생성(RAG): 이 접근 방식에서 응답을 생성하는 방법을 지정하는 명령은 프롬프트 템플릿의 프롬프트 명령에 있습니다. 이 경우 응답은 전적으로 LLM이 생성하는 내용에 좌우됩니다. 프롬프트 명령 외에도 Einstein Studio의 LLM 구성 설정처럼 응답에 영향을 미치는 방법이 있지만, 이로 인한 결과는 여전히 결정적이지 않습니다.
2. 추론 엔진 기반 검색 증강 생성(RAG): 에이전트는 프롬프트 템플릿을 사용하지 않고 플로 또는 Apex 클래스를 통해 청크를 검색하여 변수에 저장하는 작업을 사용합니다(다음 섹션 참조). 이 접근 방식에서는 추론 엔진이 LLM 대신 검색된 데이터를 기반으로 직접 답변을 생성합니다. 응답 생성을 제어하는 명령은 프롬프트 템플릿 명령이 아니라 에이전트 명령입니다. 검색된 콘텐츠를 보유하는 변수는 계속해서 작업에 대한 입력으로 명시적으로 전달될 수 있습니다. 변수의 콘텐츠에 대한 기본 액세스 권한을 부여하여 추론 엔진에 제공할 수도 있습니다. 이 접근 방식에는 단점이 있습니다. 콘텐츠와 책임으로 추론 엔진에 과부하를 줄 수 있는 잠재적인 위험이 있습니다. 게다가 프롬프트와 달리 추론 엔진의 LLM 매개 변수는 구성할 수 없습니다. 반면, 추론 엔진은 검색된 청크와 대화 기록을 모두 사용하여 답변을 생성할 수 있습니다.

권장 방법은 옵션 1입니다. 이 방법은 추론 엔진이 수행해야 하는 작업 수를 줄여 답변 품질을 개선합니다. 다음 섹션에서는 이 규칙의 예외를 살펴봅니다. 이 규칙에서는 콘텐츠가 대화 내내 보존되므로, 작업에 명시적으로 제공됩니다.

검색 증강 생성(RAG) 모범 사례

• 스크립팅된 검색 증강 생성(RAG) 명령 방지: 구체적인 질문에 대해 특정 문서에 직접 명령을 연결하는 대신, 검색 증강 생성(RAG)의 인텔리전스를 활용하여 가장 관련성 높은 데이터 소스와 정확한 텍스트 조각을 동적으로 찾을 수 있습니다. 검색 증강 생성(RAG)의 항목 일치 프로세스는 정확한 질문-소스 매핑뿐만 아니라 질문에 대한 광범위한 이해를 기반으로 합니다.
• 주제 통합: 관련 질문 범주를 단일 주제로 그룹화합니다. 검색 증강 생성(RAG)은 더 넓은 주제 내에서도 질문 유형에 따라 관련 답변을 효과적으로 식별할 수 있습니다. 예를 들어, 유지 관리 및 배터리 문제와 같은 제품 문제를 더 포괄적인 주제로 집계할 수 있습니다.

변수에 검색 증강 생성(RAG) 출력 저장: 상호 작용 제한 수에 도달하면 검색 증강 생성(RAG) 출력을 변수에 저장합니다. 이렇게 하면 표준 임계값을 넘어 에이전트 상호 작용을 안내할 수 있는 정보에 액세스할 수 있습니다. 관련 예는 다음 섹션에서 제공됩니다.

특정 비즈니스 프로세스에는 구체적인 작업 순서나 조건을 적용하여 작업이나 주제를 트리거하는 등 훨씬 더 예측 가능한 실행이 필요합니다.

이러한 결정론적 동작을 달성하는 데 변수를 사용할 수 있습니다. 변수는 작업 입력 또는 출력 역할을 할 수 있는 단기 에이전트 메모리의 구조화된 형태로 작동합니다. 또한, 변수의 상태는 특정 주제와 작업의 트리거를 제어할 수 있습니다.

변수가 결정을 지원하는 방법

변수는 다음과 같은 방식으로 에이전트의 안내형 결정론을 달성하는 데 도움이 될 수 있습니다.

1. 지속적인 동적 그라운딩: 변수를 통해 에이전트는 후속 상호 작용의 영향을 받지 않는 중요한 정보를 유지하면서 세계에 대한 이해를 지속적으로 업데이트할 수 있습니다. 이 방법을 사용하면 검색 증강 생성(RAG)을 통해 검색되는 비정형 데이터 또는 사용자 프로필 정보 등의 정형 데이터일 수 있는 중요한 정보가 대화 길이에 관계없이 대화 전반에 걸쳐 유지됩니다.
2. 작업 입력/출력: 변수는 작업의 입력과 출력으로 모두 사용할 수 있습니다. 작업은 명시적으로 변수를 참조하며, 작업의 실행은 이러한 입력과 출력을 설정하는 추론 엔진에 의존하지 않으므로 에이전트의 결정성을 높입니다.
3. 필터링: 변수는 작업 또는 주제의 조건부 실행을 결정하는 데 사용할 수 있습니다. 변수는 작업 실행에서 작업과 결정성 간의 특정 정보 플로를 허용합니다. 이 기능은 이메일처럼 특정 입력 변수가 검증되지 않은 경우 작업을 시작할 수 없는 보안 규칙에 특히 중요합니다.

Agentforce의 변수 유형

Agentforce에는 2가지 유형의 변수가 있습니다.

• 컨텍스트 변수는 사용자 및 대화 세션에 대한 정보를 저장하는 시스템 생성 변수입니다.
• 사용자 지정 변수는 사용자가 인스턴스화할 수 있습니다. 변수가 결정론을 지원하는 3가지 방법 중 하나에 사용되는 모든 종류의 정보를 보유합니다.

변수 유형은 다음 기능을 지원합니다.

고객 응대 문제 해결 에이전트라는 사용 사례를 통해 변수를 더 자세히 살펴보겠습니다. 이 예제에서는 변수가 지속적인 동적 그라운딩, 작업 입력/출력, 필터링의 3가지 목적 모두에 사용됩니다.

이 예제에서는 에이전트가 고객이 기술 디바이스 문제를 해결하는 데 도움을 줍니다. 문제를 해결하려면 일반적으로 여러 단계를 거쳐야 합니다. 에이전트는 사람 서비스 에이전트의 업무를 모방한 서비스 경험을 제공해야 합니다. 이렇게 하려면 에이전트가 고객에게 모든 문제 해결 단계를 한꺼번에 제공해서는 안 됩니다. 대신 단계별 지침과 함께 고객이 응답하는 방식에 따라 앞서 다룬 단계로 돌아가기도 하며 단계를 넘나들 수 있어야 합니다.

이를 달성하기 위한 한 가지 과제는 대화 내내 모든 문제 해결 단계를 유지할 수 있는 에이전트의 능력입니다. 저장할 수 있는 상호 작용 수가 제한되어 에이전트의 메모리에 제약이 있으므로, 대화가 길어지면 추론 엔진의 컨텍스트에서 이러한 단계가 제외될 수 있습니다.

이 과제를 해결하려면 변수를 사용하여 문제 해결 단계 전반에 걸쳐 추론 엔진을 동적으로 그라운딩하면 됩니다. 정보를 검색하고 변수에 저장하면 대화 내내 사용 가능한 상태로 유지되며 업데이트할 수 있습니다. 추론 엔진은 이 변수에 저장된 정보를 사용하여 동적 그라운딩을 수행합니다.

이 예제에서는 주제에 2가지 작업이 포함되어 있는데, 일관된 데이터 플로를 유지하려면 두 작업이 모두 필요합니다. 첫 번째 작업은 모든 문제 해결 단계를 포함하는 변수를 채우는 데 사용됩니다. 두 번째 작업은 문제 해결 과정 중에 해당 변수를 활용합니다.

1. 작업 1: '문제 해결 입력 단계'. 에이전트가 문제를 처음 접했을 때 트리거되는 초기 작업입니다. 에이전트는 검색 증강 생성(RAG)을 사용하여 색인화된 기술 자료에서 필요한 모든 해결 단계를 추출합니다. 작업은 결과 출력을 '해결 단계'라는 변수에 저장합니다.
2. 작업 2: '문제 해결 도중에 사용'. 이는 문제 해결 프로세스 중에 사용할 가능성이 가장 높은 다음 문제 해결 단계를 출력하는 프롬프트에 기반한 작업입니다. 에이전트는 문제를 해결하는 동안 이 작업을 사용하라는 지시를 받습니다.

원래 고객 질문은 두 작업에 모두 입력됩니다. 두 번째 작업에는 '해결 단계' 변수의 내용이라는 또 다른 입력이 있는데, 이 변수는 첫 번째 작업에 의해 설정됩니다. 두 번째 작업은 문제 해결 단계 자체를 검색하지는 않지만, 변수를 통해 첫 번째 작업에서 입력으로 가져옵니다. 다음 다이어그램은 이러한 두 작업 간의 데이터 플로를 보여줍니다.

'문제 해결 도중에 사용' 작업은 항상 문제 해결 단계 작업에서 검색한 원래 문제 해결 단계를 참조합니다. 이 데이터 플로는 대화 길이에 관계없이 문제 해결 단계가 일정하게 유지되고 항상 제공되도록 보장합니다.

이 예제에 정의된 작업을 실행하려면 '항상 '해결 입력 단계' 먼저 실행'과 같은 특정 명령이 필요합니다. 하지만 에이전트가 사용하는 LLM의 비결정적 특성을 고려하면 경우에 따라 다른 순서로 이어질 수 있습니다. 결정적인 실행 순서를 보장하려면 변수에 조건부 필터를 적용하여 적절한 작업 순서를 실행합니다. 에이전트는 변수 '해결 단계'의 값을 읽고 이 변수에 값이 있는지에 따라 2개의 필터를 정의합니다.

• 문제 해결 단계 작업은 '해결 단계' 변수가 비어 있는 경우에만 실행할 수 있습니다.
• '해결 단계' 변수가 채워진 경우에만 '문제 해결 도중에 사용 작업'을 실행할 수 있습니다.

이러한 조건부 필터는 이제 작업 실행 순서를 결정적으로 적용합니다. '문제 해결 도중에 사용'은 '문제 해결 단계'가 작업을 완료할 때까지 기다려야 하므로 '해결 단계' 변수에 항상 값이 있어야 합니다.

올바른 작업 실행을 보장하려면 문제가 완전히 해결된 경우 '해결 단계' 변수를 재설정하는 세 번째 작업을 거쳐야 합니다. 결과적으로 에이전트는 새로 발생 가능한 다른 문제를 지원할 수 있도록 필요한 상태로 재설정됩니다. 이 세 번째 작업을 '해결 변수 비우기'라고 합니다. 전체 작업 다이어그램은 아래에 나와 있습니다.

변수는 문제 해결 에이전트가 다음을 허용하여 고객 문제를 해결하는 데 매우 중요합니다.

• 지속적인 동적 그라운딩: 변수는 문제 해결 단계를 저장하여 상호 작용의 길이나 횟수에 관계없이 대화 전반에 걸쳐 사용할 수 있도록 합니다. 이렇게 하면 에이전트가 맥락에서 벗어나지 않도록 방지할 수 있습니다.
• 데이터 플로: 변수는 작업 간의 데이터 플로를 촉진합니다. 예를 들어, '해결 단계' 변수는 문제 해결 단계 작업에서 검색된 문제 해결 단계를 저장하고 '문제 해결 도중에 사용' 작업에 대한 입력으로 제공합니다.
• 결정론: 변수를 필터로 사용하여 특정 작업 실행 순서를 적용할 수 있습니다. 가령 '문제 해결 도중에 사용' 작업은 해결 단계 변수가 채워진 경우에만 실행되므로, 문제 해결 단계 작업이 먼저 실행됩니다.

생성형 AI 시대에 예측형 AI는 생성형 기능을 안내, 개선 및 컨텍스트화하는 기본 인텔리전스를 형성한다는 점에서 여전히 매우 중요합니다. 생성형 AI는 텍스트, 이미지, 동영상 등의 새로운 콘텐츠를 생성하는 데 중점을 두지만, 예측 모델은 실시간 비즈니스 데이터의 입력을 기반으로 미래를 예측합니다. 비즈니스 결과의 예로는 고객 이탈 가능성, 전환 가능성, 사례 에스컬레이션 확률, 고객 평생 가치, 사례 분류 등이 있습니다. 예측은 트렌드와 수치를 분석하여 사용자 요구 사항을 예측하고, 출력을 개인화하고, 결정을 내리고, 콘텐츠 관련성을 실시간으로 최적화하는 데 도움이 될 수 있습니다. 예를 들어, 개인화된 학습이나 의료, 재무 계획과 같은 응용 분야에서 예측형 AI는 개별 컨텍스트와 향후 시나리오에 맞춰 생성형 출력을 보장합니다. 예측형 및 생성형 AI가 함께 강력한 시너지 효과를 발휘하여 미래를 예측하는 능력과 창의성이 어우러진 더 지능적이고, 적응력이 뛰어나며, 영향력 있는 기술 솔루션을 만들어 냅니다.

예측 모델 출력을 에이전트 워크플로에 통합하는 방법

예측 모델 출력을 에이전트 워크플로에 통합하려면 Agentforce 자산에 예측 모델 작업을 추가하기만 하면 됩니다. 모델 빌더는 예측 모델을 구축 또는 등록(BYO)할 수 있는 수단을 제공하며, 에이전트는 이러한 모델을 사용하여 예측합니다. 결과 예측 및 예측 변수는 사용자 지정 변수에 저장할 수 있습니다. 에이전트는 이러한 변수 값을 특정 작업과 주제에 대한 입력으로 사용하고, 이를 조건부로 실행할 수 있습니다.

예측 모델과 통합된 사용 사례 예제

• 세분화: 고객 세분화를 위해 다중 클래스 분류를 수행하고 결과 세그먼트를 사용하여 특정 작업을 필터링합니다. 프리미엄 계층 고객을 위해 프리미엄 작업을 예약하는 것을 예로 들 수 있습니다.
• 에스컬레이션 가능성: 서비스 사례에 대한 에스컬레이션 가능성을 예측합니다. 이 가능성이 특정 임계값을 초과하면 사례를 더 빠르게 해결하거나 사람 에이전트에게 신속하게 에스컬레이션하는 작업을 실행할 수 있습니다.
• CPG: 판매 증가(예측 모델로 계산된 점수)가 특정 임계값을 초과하는 경우에만 프로모션을 계획하세요.
• 커머스: 구매 성향이 특정 임계값을 초과하는 경우에만 제품을 제안합니다.

특정 비즈니스 프로세스는 정확한 순서로 실행되어야 하며, 실행 중에 사용자 입력이 필요하지 않습니다. 이 경우 플로, API 또는 Apex를 통해 사전 결정된 단계 플로를 시행할 수 있습니다. 프로덕션 시 적극 활용하는 기존 플로가 있다면, 에이전트에서 이를 유지하고 사용하여 해당 비즈니스 프로세스를 실행할 수 있습니다. 다음 모든 예제에는 에이전트가 사용자 입력 없이도 실행할 수 있는 미리 정해진 일련의 단계가 포함됩니다. 이 경우 에이전트 동작은 실행할 결정론적 프로세스, 필요한 입력을 수집하는 방법, 출력을 해석하고 처리하는 방법을 식별하는 것으로 구성됩니다.

순차적 단계(경험상 3단계 이상)가 대부분이고 변수에 대한 종속성이 많은 비즈니스 프로세스는 명령으로 실행하기에는 너무 복잡하고 번거롭습니다. 이 경우에는 이 섹션에 나와 있는 결정론적 작업 유형을 사용하여 하드코딩하면 됩니다. 마지막으로, 이러한 구현에는 해결된 프롬프트 템플릿을 사용하는 LLM 호출과 같은 비결정적 요소가 포함될 수 있습니다. 따라서 완전히 결정적이고 종합적일 필요는 없으며, 여전히 에이전트가 알고 있는 유동성을 원하는 수준으로 보여줄 수 있습니다.

마케팅 여정의 단계 순서는 고정된 규칙에 따라 달라지며, 대화형 사용자 입력에 의존하지 않습니다. 따라서 플로를 Agentforce 작업으로 사용할 수 있습니다. 플로 또는 Apex 클래스를 호출할 수 있는 솔루션 구성 요소에서 백그라운드 또는 이벤트 트리거 작업을 완료하기 위해 호출 가능한 작업을 생성할 수 있습니다. 플로 또는 Apex 클래스에 호출 가능한 작업을 추가하고 에이전트가 완료하는 작업과 에이전트를 트리거하는 조건을 지정합니다. 호출 가능한 작업은 에이전트의 컨텍스트 변수를 전달하고 중요한 정보를 제공할 수도 있습니다.

Salesforce 플로를 사용하여 후속 작업 생성, 리마인더 이메일 전송, 레코드 업데이트와 같은 일상적인 작업을 자동화할 수 있습니다. 플로는 업무의 효율성과 생산성을 높입니다. 에이전트는 플로 작업을 사용하여 플로를 실행할 수도 있습니다. 결정론으로 인해 플로는 비즈니스 프로세스를 특정 순서로 실행해야 할 때 에이전트 동작을 지시할 수 있는 좋은 방법입니다. 플로 동작이 선호되는 경우는 주제에 '세 작업을 순서대로 수행할 것'과 같은 다른 명령이 포함되어 있을 때입니다. 3단계 이상의 순서를 적용하면 명령과 변수를 통해 관리하기가 번거로워집니다.

플로는 프롬프트를 호출하여 비결정적 요소를 포함할 수도 있습니다. 플로의 프롬프트 노드는 프롬프트 템플릿을 호출하고 플로의 다른 요소에 전달될 수 있는 응답을 수집합니다. 이러한 추가 요소는 다시 프롬프트 노드가 되어 가령 이전 응답을 요약하여 프롬프트 체인을 생성할 수 있습니다. 이는 프롬프트 체이닝 규칙이 정해진 요소에 따라 정의되고 사용자 입력에 의존하지 않는 경우에 특히 유용합니다. 한 예로, 에이전트 검색 증강 생성(RAG)은 플로에서 미리 정의된 리트리버나 프롬프트 순서를 통해 구체적인 데이터 소스에 특정 순서로 액세스할 수 있는데, 예를 들어, 사용자의 국가 문서에서 먼저 데이터를 검색한 뒤 필요에 따라 다른 소스를 참조하는 식입니다. 이 체인 메커니즘은 관련 정보를 신뢰할 수 있게 순서대로 추출합니다.

플로, Apex 및 API 작업과 마찬가지로 사전 정의된 작업 순서를 코딩할 수 있다는 점에서 결정론적 성격을 띱니다. 이러한 작업에는 프롬프트 템플릿 또는 LLM 호출과 같은 비결정적 요소가 포함될 수 있습니다. 하지만 정의에 따라 이러한 단계를 결정적으로 실행하므로, 적절한 시점에 작업을 호출하고 필요한 입력을 수집하고 출력을 처리하여 에이전트 가변성을 줄입니다. 이러한 책임은 여전히 에이전트 명령에 의해 관리되어야 하므로, 결정론적이지 않습니다. Apex 및 API 작업은 플로 작업과 동일한 사전 코딩 작업입니다.

신뢰할 수 있는 에이전트 동작을 달성하려면 대규모 언어 모델(LLM)의 고유한 유연성과 엔터프라이즈 수준의 제어 및 예측 가능성 간 필요성을 균형 있게 유지하는 체계적인 접근 방식이 필요합니다. 이 문서에서는 지능적이고 자율적일 뿐만 아니라 일관되게 정확하고 비즈니스 프로세스에 부합하는 에이전트를 생성할 수 있는 '안내형 결정론'을 구현하기 위한 계층화된 전략을 간략하게 설명했습니다. 신뢰할 수 있는 에이전트를 구축하기 위한 핵심은 제어 메커니즘을 점진적으로 구현하는 데 있으며, 각 메커니즘은 새로운 안정성 계층을 추가합니다.

1. 기초 주제 및 작업 설계: 이 프로세스는 에이전트의 기능을 별개의 주제와 세분화된 작업으로 신중하게 구성하면서 시작됩니다. 의미론적으로 구별된 논리적인 그룹화를 구성하면 추론 엔진이 혼동으로 인해 잘못된 작업을 선택할 위험을 줄여 예측 가능한 동작의 기반을 마련할 수 있습니다.
2. 명시적 명령: 이러한 기반으로 구축된 에이전트 명령은 한 차원 높은 제어 기능을 제공합니다. 이러한 명령은 가드레일 및 지침 역할을 하며, 상호 작용을 과도하게 스크립팅하지 않고도 추론 엔진이 범위 내에서 작업을 실행하고, 회사 정책을 준수하고, 대화 플로를 관리하는 방법을 안내합니다.
3. 검색 증강 생성(RAG)을 활용한 데이터 그라운딩: 데이터 그라운딩은 에이전트를 검증된 지식 소스에 연결하여 사실과 관련성을 통해 응답을 개선합니다. 검색 증강 생성(RAG)과 같은 접근 방식을 통해 에이전트는 기술 문서 및 회사 데이터에서 실시간으로 정확한 정보를 가져와 추측을 최소화하고 신뢰성을 높일 수 있습니다.
4. 변수를 통한 컨텍스트 및 상태 관리: 더 복잡한 상태 기반 상호 작용의 경우, 변수는 단기 메모리의 형태를 도입합니다. 이를 통해 에이전트는 컨텍스트를 유지하고, 대화 전반에 걸쳐 중요한 데이터를 보존하며, 변수 상태에 따라 작업 실행을 조절하여 결정론적인 운영 순서를 강제할 수 있습니다.
5. 플로, Apex 및 API를 통한 결정론적 실행: 변함없이 엄격하게 실행해야 하는 비즈니스 프로세스의 경우, 결정론적 작업을 통해 가장 높은 수준의 제어를 달성할 수 있습니다. 에이전트를 Salesforce 플로, Apex, API와 통합하면 사전 정의된 순서를 정확하게 따를 수 있어 중요한 단계에서 사용자 입력 또는 LLM 입력에 의존하지 않아도 됩니다.

개발자는 사려 깊은 설계와 명확한 명령부터 데이터 그라운딩, 상태 관리, 결정론적 프로세스 자동화에 이르는 제어 계층을 체계적으로 적용하여 일관된 비즈니스 성과를 내는 신뢰할 수 있는 에이전트를 구축할 수 있습니다. 이러한 전략적 접근 방식은 Agentforce 에이전트가 엔터프라이즈 환경에서 필요한 정확성과 일관성을 가지고 중요한 비즈니스 기능을 수행하도록 보장합니다.