다음 권장사항은 강력한 에이전트 앱을 빌드하는 데 도움이 됩니다.
자연어로 된 에이전트 이름
명확한 에이전트 이름 의미가 있는 자연어를 사용합니다. 예를 들어 '고객 고객센터 에이전트'는 'company_specialist'보다 더욱 설명적이므로 런타임 시 LLM 성능이 향상됩니다.
간결한 목표
목표는 에이전트의 목적을 간결하게 설명해야 합니다.
고품질 지침 제공
지침은 다음과 같아야 합니다.
- 최종 사용자 문제를 해결하기 위한 단계별 접근 방식을 반영해야 합니다.
- 높은 수준의 지침을 제공하는 간결한 자연어 문장이어야 합니다.
- 명확하고 도구 사용 시나리오를 지정해야 합니다.
각 에이전트에 대해 하나 이상의 예시 제공
에이전트마다 하나 이상의 예시가 있어야 하지만 4개 이상 있는 것이 좋습니다. 예시에는 해피 패스 시나리오가 포함되어야 합니다.
예시가 충분하지 않으면 에이전트에서 예기치 않은 동작이 발생할 수 있습니다. 에이전트가 예상한 방식으로 응답하지 않거나 작동하지 않으면 예시가 누락되었거나 잘못 정의된 것일 수 있습니다. 예시를 개선하거나 새 예시를 추가해 보세요.
지침 및 예시의 정밀도
명확하고 설명적인 지침을 작성하면 도움이 되지만 실제로 에이전트 동작의 정확성을 결정하는 것은 예시의 품질과 수량입니다. 즉, 완벽하게 정확한 지침을 작성하는 것보다 예시를 철저하게 작성하는 데 더 많은 시간을 할애하세요.
예시의 참조 도구
에이전트가 도구를 사용하여 응답을 제공하도록 설계된 경우 이 요청 유형에 해당하는 예시의 도구를 참조하세요.
도구 스키마 operationId 필드
도구에 대한 스키마를 정의할 때는 operationId 값이 중요합니다.
에이전트 지침에서 이 값을 참조합니다.
이 필드의 이름 지정 권장사항은 다음과 같습니다.
- 문자, 숫자, 밑줄만 사용할 수 있습니다.
- 스키마에 설명된 모든
operationId간에 고유해야 합니다. - 제공된 기능을 반영한 의미 있는 이름이어야 합니다.
도구 스키마 검증
도구 스키마를 검증해야 합니다. Swagger Editor를 사용하여 openAPI 3.0 스키마 문법을 확인할 수 있습니다.
빈 도구 결과 처리
에이전트가 대답을 위한 정보를 얻는 데 도구를 사용할 때 도구 결과가 비어 있으면 예기치 않은 에이전트 동작이 발생할 수 있습니다. 경우에 따라 에이전트 LLM이 도구 결과 대신 대답으로 정보를 할루시네이션합니다. 이를 방지하려면 에이전트 LLM이 자체적으로 대답을 시도하지 않도록 구체적인 요청 사항을 추가하면 됩니다.
일부 사용 사례에서는 에이전트 대답이 도구 결과 또는 제공된 데이터에 충분한 근거를 두고 에이전트 LLM의 지식만을 기준으로 대답을 완화해야 합니다.
할루시네이션 완화를 위한 요청 사항 예:
- '도구를 사용해 모든 사용자 질문에 대답해야 합니다.'
- '도구에서 데이터를 다시 가져올 수 없는 경우 사용자 쿼리에 대한 답을 모른다고 대답합니다.'
- '도구에서 데이터를 다시 가져올 수 없는 경우 대답을 제공하지 않습니다.'
Gemini로 스키마 생성
Gemini는 스키마를 자동으로 생성할 수 있습니다. 예를 들어 'Google Calendar용 openAPI 3.0 스키마 예시를 만들어 줘'라고 입력해 보세요.
집중적인 에이전트
크고 복잡한 에이전트를 만들지 마세요. 각 에이전트는 구체적이고 명확한 태스크를 수행해야 합니다. 복잡한 에이전트의 경우 더 작은 하위 에이전트로 나누는 것이 좋습니다.
루프 및 재귀 방지
지침에 에이전트 앱을 연결할 때는 루프나 재귀를 만들지 마세요.
예시에 라우팅 정보 제공
에이전트가 다른 에이전트로 라우팅해야 하는 경우 이 정보를 예시에 제공해야 합니다. 이는 입력 및 출력 예시 섹션의 출력 정보가 있는 종료 예시 필드의 예시입니다.
예를 들어 이 필드의 마지막 문장은 '추가 쿼리를 위해 기본 에이전트로 다시 라우팅'일 수 있습니다.
맞춤설정에 Dialogflow CX Messenger JavaScript 함수 사용
Dialogflow CX Messenger를 사용할 때 다음 함수는 사용자 맞춤설정 정보를 웹 인터페이스에서 에이전트로 전송하는 데 유용합니다.