또한 재시도를 위한 지수 백오프도 구현해야 합니다.
이러면 API 서비스가 과부하 상태일 때 시스템에서 허용되는 비율을 찾을 수 있습니다.
Cloud API 오류
Google에서 제공하는 클라이언트 라이브러리를 사용하는 경우 지수 백오프가 포함된 Cloud API 오류 재시도가 구현됩니다.
REST 또는 gRPC를 사용하여 자체 클라이언트 라이브러리를 구현한 경우 클라이언트에 대한 재시도를 구현해야 합니다.
재시도하거나 재시도해서는 안 되는 오류에 대한 자세한 내용은 API 개선 제안서: 자동 재시도 구성을 참조하세요.
웹훅 오류
API 호출이 웹훅 호출을 트리거하면 웹훅이 오류를 반환할 수 있습니다.
Google에서 제공하는 클라이언트 라이브러리를 사용하는 경우에도 웹훅 오류가 자동으로 재시도되지 않습니다.
코드는 웹훅에서 수신된 503 Service Unavailable 오류를 다시 시도해야 합니다.
웹훅 오류 유형 및 오류 확인 방법에 대한 자세한 내용은 웹훅 서비스 문서를 참조하세요.
부하 테스트
코드를 프로덕션으로 출시하기 전에 시스템의 부하 테스트를 실행하는 것이 좋습니다.
부하 테스트를 구현하기 전에 다음 사항을 고려하세요.
요약
세부정보
부하 증가
부하 테스트에서는 Dialogflow 서비스에 적용되는 부하를 늘려야 합니다. 서비스는 실제 트래픽에서 거의 발생하지 않는 갑작스러운 부하 버스트를 처리하도록 설계되지 않았습니다. 서비스가 부하 수요에 맞게 조정되는 데에는 시간이 걸리므로 테스트가 원하는 부하를 달성할 때까지 요청 속도를 천천히 증가시킵니다.
API 호출에 대한 청구
테스트 중 API 호출에 대해 비용이 청구되며 호출은 프로젝트 할당량에 따라 제한됩니다.
테스트 더블 사용
부하 테스트 중에 API를 호출할 필요가 없을 수 있습니다. 부하 테스트의 목적이 내 시스템에서 부하를 얼마나 처리하는지 알기 위함이라면 실제로 API를 호출하는 대신 테스트 더블을 사용하는 것이 가장 좋습니다. 테스트 더블은 부하가 걸렸을 때의 API의 동작을 시뮬레이션할 수 있습니다.
Dialogflow API에 액세스하는 데 사용되는 비공개 키를 최종 사용자 기기에 저장해서는 안 됩니다.
이는 키를 기기에 직접 저장하고 애플리케이션에서 키를 하드 코딩하는 경우에 적용됩니다.
클라이언트 애플리케이션에서 Dialogflow API를 호출해야 하는 경우 클라이언트 애플리케이션은 보안 플랫폼의 개발자 소유 프록시 서비스에 요청을 보내야 합니다.
프록시 서비스에서 실제 인증된 Dialogflow를 호출할 수 있습니다.
예를 들어 Dialogflow를 직접 호출하는 모바일 애플리케이션을 만들면 안 됩니다.
이렇게 하려면 비공개 키를 최종 사용자 기기에 저장해야 합니다.
모바일 애플리케이션은 대신 보안 프록시 서비스를 통해 요청을 전달해야 합니다.
성능
이 섹션에서는 Dialogflow 내의 다양한 작업에 관한 성능 정보를 간략히 설명합니다. 지연 시간은 Dialogflow SLA에 포함되지 않지만 응답형 상담사를 설계하고 현실적인 실적 기대치를 설정하는 데 중요합니다.
모니터링 및 알림 도구를 빌드할 때 대규모 언어 모델(LLM) 및 음성 처리는 일반적으로 스트리밍 메서드를 사용하여 처리됩니다.
응답은 가능한 한 빨리 클라이언트로 전송되며, 이는 메서드 호출의 총 시간보다 훨씬 일찍 이루어지는 경우가 많습니다. 자세한 내용은 대규모 언어 모델 (LLM) 권장사항을 참고하세요.
작업당 실적
다음 표에는 Dialogflow 작업의 일반적인 성능에 관한 정보가 나와 있습니다.
작업
참고
흐름 작업: 상태 핸들러
가장 빠른 작업
흐름: 인텐트 감지 (텍스트)
가장 빠른 작업
흐름: 매개변수 감지 (텍스트)
빠른 작동
음성 인식 (스트리밍)
데이터가 처리되고 응답이 최대한 빨리 반환됩니다. 총 실행 시간은 주로 입력 오디오의 길이에 따라 결정됩니다. 총 실행 시간을 사용하여 지연 시간을 측정하는 것은 권장되지 않습니다.
음성 합성 (스트리밍)
총 실행 시간은 기본적으로 출력 오디오의 길이에 따라 결정됩니다. 데이터가 처리되고 응답이 최대한 빨리 반환됩니다.
데이터 스토어: 생성형 AI 사용 중지됨
실제 시간은 데이터 저장소의 크기에 따라 다릅니다.
데이터 스토어: 생성형 AI 사용 설정됨
성능은 데이터 저장소의 크기, 사용 중인 언어 모델, 프롬프트 출력 및 입력의 길이에 따라 달라집니다(순서대로).
생성형 대체
성능은 사용 중인 언어와 프롬프트 출력 및 입력 길이에 따라 달라집니다(순서대로).
생성기
성능은 사용 중인 언어 모델, 프롬프트 입력 및 출력 길이의 복잡성, 턴의 생성자 수에 따라 달라집니다. 한 번에 여러 생성기를 사용하면 언어 모델이 여러 번 호출됩니다.
플레이북 실행
성능은 플레이북의 복잡성, 프롬프트 수, 호출된 도구의 실행 시간에 따라 달라집니다. 프롬프트 출력 및 입력의 길이는 이 성능에 영향을 미칩니다. 여러 언어 모델 프롬프트가 연속적으로 실행되어 총 통화 시간이 늘어날 수 있습니다.
플레이북: 도구
성능은 도구의 기본 실행에 따라 달라집니다.
웹훅 호출
성능은 웹훅에서 코드의 실행 시간에 따라 직접 결정됩니다.
가져오기 / 내보내기 에이전트
성능은 상담사의 크기에 따라 달라집니다.
상담사 교육
성능은 흐름, 인텐트, 학습 문구 수에 따라 달라집니다. 대규모 상담사를 학습하는 데 수십 분이 걸릴 수 있습니다.
환경 만들기
환경을 만들려면 에이전트를 학습해야 하므로 총 시간은 에이전트의 크기와 복잡도에 따라 달라집니다.
주요 사항:
스트리밍: 스트리밍 호출 (음성 인식 및 합성)의 경우 데이터가 도착하면 처리되고 응답은 최대한 빨리 반환됩니다.
즉, 초기 응답은 일반적으로 통화의 총 시간보다 훨씬 빠릅니다.
플레이북: LLM 프롬프트는 플레이북 안내, 대화 컨텍스트, 도구 입력을 기반으로 구성됩니다. 단일 플레이북 호출에서 여러 LLM 프롬프트를 실행할 수 있습니다. 따라서 실행되는 프롬프트의 수와 호출의 복잡도에 따라 플레이북 실행이 달라질 수 있습니다.
중요한 지연 시간 고려사항
지연 시간 보장 없음: Dialogflow SLA는 프로비저닝된 처리량을 사용하는 경우에도 지연 시간을 고려하지 않습니다.
LLM 지연 시간: LLM 처리로 인해 상당한 지연 시간이 발생할 수 있습니다. 이를 상담사 설계 및 사용자 기대치에 반영하세요.
모니터링 및 알림: 모니터링 및 알림을 설정할 때는 LLM 및 음성 서비스의 응답이 스트리밍되는 특성을 고려하세요.
전체 응답 시간이 첫 응답 시간과 같다고 가정하지 마세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eThis guide offers best practices for Dialogflow, emphasizing efficiency, accuracy, and optimal response times.\u003c/p\u003e\n"],["\u003cp\u003eFor production environments, it's crucial to utilize agent versions, reuse session clients, and implement error handling with retries.\u003c/p\u003e\n"],["\u003cp\u003eTo ensure data safety, regular agent backups should be exported, allowing for quick recovery from accidental data loss.\u003c/p\u003e\n"],["\u003cp\u003eWhen calling Dialogflow from client apps, a proxy service should be used to prevent private keys from being stored on user devices.\u003c/p\u003e\n"],["\u003cp\u003eLoad testing is recommended, and it is important to note that the most common actions are speech operations and flow actions, all of which are heavily affected by the large language model prompt output and input length.\u003c/p\u003e\n"]]],[],null,["# Service use best practices\n\nThis guide provides best practices for using the Dialogflow service.\nThese guidelines are designed for greater efficiency and accuracy\nas well as optimal response times from the service.\n\nYou should also see the\n\n[general agent design](/dialogflow/cx/docs/concept/agent-design)\n\nguide for all agent types,\nand the\n\n[voice agent design](/dialogflow/cx/docs/concept/voice-agent-design)\n\nguide specifically for designing voice agents.\n\nProductionization\n-----------------\n\nBefore running your agent in production,\nbe sure to implement the following best practices:\n\n- [Use agent versions](#agent-version)\n- [Reuse session clients](#session-client-reuse)\n- [Implement error handling with retries](#retries)\n\nAgent versions\n--------------\n\nYou should always use agent versions for your production traffic.\nSee\n\n[Versions and environments](/dialogflow/cx/docs/concept/version)\n\nfor details.\n\nCreate agent backup\n-------------------\n\nKeep an up-to-date\n\n[exported](/dialogflow/cx/docs/concept/agent#export)\n\nagent backup. This will allow you to quickly recover if you or your team members\naccidentally delete the agent or the project.\n\nClient reuse\n------------\n\nYou can improve the performance of your application\nby reusing `*Client` client library instances\nfor the duration of your application's execution lifetime.\n\nMost importantly,\nyou can improve the performance of detect intent API calls\nby reusing a `SessionsClient` client library instance.\nGo to the Session API reference \n**Select a protocol and version for the Session reference:**\n\nClose\n\nFor more information on this, see the\n[Best Practices with Client Libraries guide](/apis/docs/client-libraries-best-practices#reuse_client_objects_and_sessions).\n\nAPI error retries\n-----------------\n\nWhen calling API methods, you may receive error responses.\nThere are some errors which should be retried,\nbecause they are often due to transient issues.\nThere are two types of errors:\n\n- [Cloud API errors](/apis/design/errors).\n- Errors sent from your [webhook service](/dialogflow/cx/docs/concept/webhook#errors).\n\nIn addition, you should implement an\n[exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff)\nfor retries.\nThis allows your system to find an acceptable rate\nwhile the API service is under heavy load.\n\n### Cloud API errors\n\nIf you are using a Google supplied\n\n[client library](/dialogflow/cx/docs/reference/library/overview),\n\nCloud API error retries with exponential backoff are implemented for you.\n\nIf you have implemented your own client library using REST or gRPC,\nyou must implement retries for your client.\nFor information on the errors that you should or should not retry, see\n[API Improvement Proposals: Automatic retry configuration](https://google.aip.dev/194).\n\n### Webhook errors\n\nIf your API call triggers a webhook call,\nyour webhook may return an error.\nEven if you are using a Google supplied client library,\nwebhook errors will not be retried automatically.\nYour code should retry `503 Service Unavailable`\nerrors received from your webhook.\nSee the\n\n[webhook service](/dialogflow/cx/docs/concept/webhook#errors)\n\ndocumentation for information on the types of webhook errors\nand how to check for them.\n\nLoad testing\n------------\n\nIt is a best practice to execute load testing for your system\nbefore you release code to production.\nConsider these points before implementing your load tests:\n\nCalling Dialogflow securely from an end-user device\n---------------------------------------------------\n\nYou should never store your private keys\nused to access the Dialogflow API on an end-user device.\nThis applies to storing keys on the device directly\nand to hard coding keys in applications.\nWhen your client application needs to call the Dialogflow API,\nit should send requests to a developer-owned proxy service on a secure platform.\nThe proxy service can make the actual, authenticated Dialogflow calls.\n\nFor example, you should not create a mobile application\nthat calls Dialogflow directly.\nDoing so would require you to store private keys on an end-user device.\nYour mobile application should instead\npass requests through a secure proxy service.\n| **Note:** Some Dialogflow integrations, like Dialogflow Messenger, provide both client code and a proxy service, similar to the description above. The proxy service only responds to requests when the integration is enabled. To improve utility of these integrations, the proxy service may not require authentication. The proxy service API is limited to a small subset of Dialogflow API methods that are required for the integration. In addition, the proxy service never provides Google Cloud or Dialogflow administrative API access without requiring authentication. This limited proxy API reduces the vulnerability for abuse.\n\nPerformance\n-----------\n\nThis section outlines performance information for various operations\nwithin Dialogflow. Understanding latency is important for designing\nresponsive agents and setting realistic performance expectations, although these\nvalues are not part of the Dialogflow SLA.\n\nWhen building monitoring and alerting tools, note that Large Language Models\n(LLMs) and speech processing are typically handled using streaming methods.\nResponses are sent to the client as soon as possible, often much earlier than\nthe total duration of the method call. For more information, see the\n[Best practices with large language models (LLMs)](/vertex-ai/generative-ai/docs/learn/prompt-best-practices).\n\n### Performance per operation\n\nThe following table provides information about the typical performance of\nDialogflow operations:\n\n**Key Notes:**\n\n- **Streaming:** For streaming calls (speech recognition and synthesis), data is processed as it arrives, and responses are returned as soon as possible. This means the initial response is typically much faster than the total time of the call.\n- **Playbooks:** An LLM prompt is constructed based on the playbook instructions, the conversation context and the tool input. Multiple LLM prompts can be executed in a single playbook call. This is why the playbook execution is variable, depending on the amount of prompts issued and the complexity of the calls.\n\n### Important Latency Considerations\n\n- **No Latency Guarantees:** Dialogflow SLAs do not consider latency, even under Provisioned Throughput.\n- **LLM Latency:** Be aware that LLM processing can introduce significant latency. Factor this into your agent design and user expectations.\n- **Monitoring and Alerting:** When setting up monitoring and alerting, account for the streamed nature of responses from LLMs and speech services. Don't assume full response time is equal to time to first response."]]
