Building AI solutions by using ML APIs or foundational models

Natural Language API with content classification is the correct choice because it provides predefined content categories that can classify text without requiring training data. Option A (AutoML Natural Language) would require labeled training data, which they don't have. Option B is incorrect as the Natural Language API doesn't support custom model training - that's what AutoML is for. Option D (Vertex AI custom training) would require significant ML expertise, training data, and development time, making it unsuitable for a quick, low-code solution.

AutoML Vision Edge is specifically designed for creating optimized models that can be deployed on mobile and edge devices, supporting offline operation with low latency. Option A won't work offline as Vision API requires internet connectivity. Option B deploys to cloud infrastructure (Vertex AI), not mobile devices. Option D also requires internet connectivity and would have higher latency due to the round-trip to cloud services. AutoML Vision Edge exports models in TensorFlow Lite format, perfect for mobile deployment.

Healthcare Natural Language API is specifically designed for extracting medical entities from clinical text, including medications, dosages, and medical conditions. It's pre-trained on medical data and requires no ML expertise. Option A (Vision API) is for image analysis, not text extraction from clinical notes. Option C (AutoML) would require labeled training data and ML expertise to train a custom model. Option D (Document AI) is better suited for document processing and layout understanding rather than specialized medical entity extraction from unstructured clinical notes.

Vision API Safe Search detection is pre-trained to detect adult, violent, medical, racy, and spoof content, making it ideal for content moderation at scale without requiring custom training. It's a fully managed service that automatically scales. Option A would require collecting and labeling sensitive training data, which is complex and potentially problematic. Option C requires managing infrastructure and model serving, adding unnecessary complexity. Option D (Matching Engine) is designed for similarity search, not content moderation classification.

The combination of Speech-to-Text API (to transcribe audio) followed by Natural Language API (for sentiment analysis and entity extraction) provides a flexible, low-code solution for analyzing call recordings. Option B (Contact Center AI) is designed for real-time agent assistance and virtual agents, not batch analysis of existing recordings. Option C (AutoML Tables) works with structured data, not audio or text analysis. Option D (Dialogflow CX) is for building conversational interfaces, not analyzing completed conversations for sentiment and entities.

Vision API Product Search is specifically designed for visual product search use cases, allowing you to create a product catalog and find similar products based on visual similarity. It's a fully managed, low-code solution. Option B is impractical as AutoML Vision classification isn't designed for search and has label limitations. Option C requires more ML expertise to generate embeddings and manage the vector database. Option D doesn't provide image similarity search capabilities and would require extensive custom development.

Document AI Invoice Parser is a specialized processor pre-trained specifically for invoice parsing, capable of extracting structured data from various invoice formats without requiring custom training. Option A (Vision API OCR) only extracts text, requiring significant custom parsing logic. Option C (AutoML Natural Language) would require training data and doesn't handle document layout understanding. Option D is incorrect as Form Parser isn't a standalone API - Document AI provides form parsing capabilities, and the Invoice Parser is the specialized solution for this use case.

Translation API Basic with glossary feature allows you to use pre-trained translation models while customizing the translation of specific terms (like technical terminology) through glossaries. This provides the right balance of low-code implementation and customization. Option B requires substantial training data for each language pair and significant effort. Option C (Translation API Advanced) is designed for high-volume scenarios with SLA requirements but doesn't offer more customization than Basic with glossaries. Option D requires deep ML expertise and substantial development effort, contradicting the low-code requirement.

Video Intelligence API is specifically designed for comprehensive video analysis, providing shot detection, label detection, text detection, speech transcription, and more in a single, fully managed service. Option A would require significant custom development to process videos frame-by-frame and coordinate multiple API calls. Option C (AutoML Video) is for training custom video classification models when pre-trained capabilities are insufficient. Option D requires extensive ML engineering and infrastructure management, making it unsuitable for a low-code requirement.

Dialogflow CX is specifically designed for building complex, multi-turn conversational interfaces with built-in features for state management, webhook integrations, and agent handoff. It's a low-code platform with visual flow design. Option A only provides intent detection and would require building the entire conversation management system. Option C is for training custom classification models, not managing conversations. Option D (PaLM API) provides powerful language generation but lacks the built-in conversation management, integration capabilities, and visual design tools that make Dialogflow CX suitable for enterprise chatbot development.