Ngân hàng đề — Microsoft Azure AI Fundamentals

Đáp án

D — Intent Classification (phân loại ý định).

Vì sao đúng

⚠ CLU (Conversational Language Understanding) làm ĐÚNG hai việc: | Việc | Nội dung | |---|---| | ⚠ Intent classification | ⚠ người dùng MUỐN GÌ | | ⚠ Entity extraction | ⚠ trích thông tin trong câu |

⚠ "Đặt vé đi Đà Nẵng ngày mai"
        ↓ ⚠ CLU
⚠ Intent: BookFlight
⚠ Entities:
   ⚠ điểm đến = Đà Nẵng
   ⚠ ngày = ngày mai
        ↓
⚠ Ứng dụng biết phải LÀM GÌ

⚠ CLU là bản kế nhiệm của LUIS, ⚠ nằm trong Azure AI Language.

Vì sao các phương án khác sai

• B (Named Entity Recognition) — ⚠ bẫy tinh vi: ⚠ CLU CÓ trích thực thể, ⚠ nhưng ⚠ NER là tính năng RIÊNG của AI Language, ⚠ không phải đặc trưng nhận diện CLU; ⚠ điều chỉ CLU có là intent.

• A (Language Detection) và C (Key Phrase Extraction) — ⚠ tính năng riêng biệt của AI Language: ⚠ không thuộc CLU.

Ghi nhớ

⚠ Azure AI Language — các tính năng và cái nào thuộc CLU: | Tính năng | Thuộc CLU | |---|---| | ⚠ Intent classification | ⚠ CÓ — đặc trưng của CLU | | ⚠ Entity extraction trong hội thoại | ⚠ CÓ | | ⚠ Sentiment analysis | ⚠ KHÔNG — tính năng riêng | | ⚠ Key phrase extraction | ⚠ KHÔNG | | ⚠ NER dựng sẵn | ⚠ KHÔNG | | ⚠ Language detection | ⚠ KHÔNG | | ⚠ Question answering | ⚠ KHÔNG — tính năng riêng |

Từ khoá nhận diện:

"người dùng muốn gì, ý định" → ⚠ CLU intent classification "trả lời câu hỏi từ tài liệu" → ⚠ Custom question answering "điều phối giữa CLU và QnA" → ⚠ Orchestration workflow "LUIS" → ⚠ tên cũ, nay là CLU

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có intent "None" với đủ ví dụ không | | | Mỗi intent có bao nhiêu utterance mẫu | | | Đã kiểm thử với câu ngoài kịch bản chưa | |

Và thành phần quyết định một chatbot có gây bực bội hay không: khả năng nhận ra rằng nó không hiểu. Một bot ép mọi câu vào ý định gần nhất sẽ liên tục làm sai và người dùng sẽ bỏ đi.

Đáp án

D — Nó có thể tự động dò siêu tham số để giúp tối ưu hiệu năng mô hình.

Vì sao đúng

⚠ Custom Vision che giấu toàn bộ phần phức tạp của học sâu: | Custom Vision tự làm | Nội dung | |---|---| | ⚠ Chọn kiến trúc mạng | | | ⚠ Transfer learning từ mô hình lớn | | | ⚠ Dò siêu tham số | ⚠ đề này | | ⚠ Tăng cường dữ liệu | | | ⚠ Đánh giá bằng cross-validation | |

⚠ Bạn chỉ cần: upload ảnh + gắn tag
        ↓
⚠ Custom Vision lo phần còn lại
        ↓
⚠ Trả về precision, recall, mAP

Vì sao các phương án khác sai

• B (chỉ hỗ trợ phân loại ảnh, không làm được phát hiện đối tượng) — ⚠ SAI: ⚠ Custom Vision hỗ trợ ⚠ CẢ image classification LẪN object detection.

• C (dùng mô hình huấn luyện sẵn không tuỳ chỉnh được) — ⚠ NGƯỢC hoàn toàn: ⚠ tuỳ chỉnh chính là mục đích tồn tại của Custom Vision.

• A (không tích hợp với các dịch vụ Azure khác) — ⚠ SAI: ⚠ tích hợp được với Logic Apps, Functions, IoT Edge và nhiều dịch vụ khác.

Ghi nhớ

⚠ Custom Vision — năng lực phải thuộc: | Năng lực | Nội dung | |---|---| | ⚠ Image classification | ⚠ multiclass hoặc multilabel | | ⚠ Object detection | ⚠ bounding box | | ⚠ Transfer learning | ⚠ chỉ cần 15-50 ảnh mỗi nhãn | | ⚠ Tự dò siêu tham số | | | ⚠ Xuất mô hình | ⚠ domain compact → TF Lite, CoreML, ONNX, Docker | | ⚠ Quản lý iteration | ⚠ train nhiều lần, publish bản tốt nhất | | ⚠ KHÔNG có | ⚠ semantic segmentation |

Từ khoá nhận diện:

"huấn luyện mô hình ảnh với nhãn riêng" → ⚠ Custom Vision "tag dựng sẵn, dùng ngay" → ⚠ AI Vision Image Analysis "chạy trên thiết bị biên" → ⚠ domain compact + export "phân đoạn từng pixel" → ⚠ KHÔNG phải Custom Vision

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Precision và recall là bao nhiêu | | | Có cần xuất ra thiết bị biên không | ⚠ quyết định chọn domain | | Ảnh huấn luyện có giống ảnh thật không | |

Và cách cải thiện mô hình Custom Vision hiệu quả nhất, hơn hẳn việc thêm ảnh ngẫu nhiên: thu thập chính những ảnh mà mô hình đang dự đoán sai. Đó là nơi mô hình còn thiếu hiểu biết nhất.

Đáp án

D — Kiểm soát chất lượng trong sản xuất.

Vì sao đúng

⚠ Kiểm soát chất lượng dùng CAMERA phân tích sản phẩm — đó là thị giác máy tính:

⚠ Camera chụp sản phẩm trên dây chuyền
        ↓ ⚠ Computer vision
⚠ Phát hiện vết xước, méo, thiếu bộ phận
        ↓
⚠ Loại sản phẩm lỗi tự động

Vì sao các phương án khác sai

• A (dịch ngôn ngữ) — ⚠ thuộc NLP, xử lý văn bản.

• B (phát hiện gian lận) — ⚠ thuộc anomaly detection hoặc classification trên dữ liệu giao dịch.

• C (hệ gợi ý) — ⚠ thuộc học máy trên dữ liệu hành vi.

Ghi nhớ

⚠ Phân loại workload AI theo LOẠI DỮ LIỆU đầu vào: | Đầu vào | Loại workload | |---|---| | ⚠ Ảnh, video | ⚠ Computer Vision | | ⚠ Văn bản | ⚠ NLP | | ⚠ Giọng nói | ⚠ Speech | | ⚠ Số liệu, bảng | ⚠ học máy truyền thống, anomaly detection | | ⚠ Hành vi người dùng | ⚠ hệ gợi ý | | ⚠ Prompt | ⚠ Generative AI |

Từ khoá nhận diện:

"camera, ảnh, video, kiểm tra ngoại quan" → ⚠ Computer Vision "dịch, phân tích văn bản" → ⚠ NLP "giao dịch bất thường" → ⚠ Anomaly detection "gợi ý sản phẩm" → ⚠ Recommendation

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Ánh sáng có ổn định không | ⚠ yếu tố số một | | Có đủ ảnh sản phẩm lỗi để huấn luyện không | | | Tốc độ xử lý có theo kịp dây chuyền không | |

Và khoản đầu tư quyết định thành bại của một hệ thống kiểm tra ngoại quan bằng AI, thường bị xem nhẹ: hệ thống chiếu sáng. Ánh sáng ổn định cải thiện độ chính xác nhiều hơn bất kỳ mô hình tinh vi nào.

Đáp án

C — Nó có thể phân biệt các thực thể TRÙNG TÊN bằng cách xét NGỮ CẢNH.

Vì sao đúng

⚠ NER hiện đại dựa trên ngữ cảnh, không phải tra từ điển:

⚠ "Tôi bay tới Washington sáng nay"
        ↓
⚠ Washington = ĐỊA ĐIỂM

⚠ "Washington đã ký sắc lệnh"
        ↓
⚠ Washington = NGƯỜI
        ↓
⚠ CÙNG một từ, KHÁC loại thực thể

⚠ Đây là năng lực mà tra từ điển đơn thuần không làm được — ⚠ mô hình phải hiểu câu xung quanh.

Vì sao các phương án khác sai

• A (không hỗ trợ custom entity recognition) — ⚠ SAI: ⚠ Azure AI Language ⚠ CÓ Custom NER.

• B (chỉ nhận diện được tổ chức và người) — ⚠ SAI: ⚠ có hàng chục loại — địa điểm, ngày giờ, số lượng, email, số điện thoại, sản phẩm, sự kiện.

• D (không có điểm tin cậy) — ⚠ SAI: ⚠ mỗi thực thể đều trả về confidenceScore.

Ghi nhớ

⚠ NER trong Azure AI Language — năng lực: | Năng lực | Nội dung | |---|---| | ⚠ Phân biệt theo ngữ cảnh | ⚠ đề này | | ⚠ Hàng chục loại thực thể dựng sẵn | | | ⚠ Điểm tin cậy cho từng thực thể | | | ⚠ Vị trí (offset, length) trong văn bản | | | ⚠ Entity linking | ⚠ liên kết tới Wikipedia | | ⚠ Custom NER | ⚠ thực thể riêng của bạn | | ⚠ Đa ngôn ngữ | |

Từ khoá nhận diện:

"phân biệt trùng tên theo ngữ cảnh" → ⚠ NER "thực thể riêng của công ty" → ⚠ Custom NER "liên kết tới trang Wikipedia" → ⚠ Entity linking "thực thể y tế" → ⚠ Text Analytics for Health

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có kiểm tra điểm tin cậy trước khi dùng không | | | Có thực thể đặc thù cần Custom NER không | | | Độ chính xác với tiếng Việt là bao nhiêu | |

Và điều làm NER hiện đại vượt xa cách tra từ điển: nó đọc cả câu để quyết định. Cùng một chuỗi ký tự có thể là tên người, tên nơi chốn hay tên công ty, và chỉ ngữ cảnh mới phân biệt được.

Đáp án

C — Azure AI Search.

Vì sao đúng

⚠ Knowledge mining là một trong các loại workload AI chính, và Azure AI Search là dịch vụ cho nó:

⚠ Dữ liệu CÓ và KHÔNG có cấu trúc
   ⚠ PDF, Word, ảnh, CSDL, email
        ↓ ⚠ Azure AI Search + skillset
⚠ Trích xuất, làm giàu, đánh chỉ mục
   ⚠ OCR, dịch, trích thực thể, cảm xúc
        ↓
⚠ Chỉ mục tìm kiếm được
        ↓
⚠ Khám phá tri thức ẩn trong đống tài liệu

Vì sao các phương án khác sai

• B (Machine Learning) — ⚠ quá chung: ⚠ là một lĩnh vực, không phải dịch vụ cho knowledge mining.

• A (Computer Vision) và D (Speech Recognition) — ⚠ là THÀNH PHẦN trong skillset: ⚠ OCR và phiên âm là hai kỹ năng, ⚠ nhưng bản thân chúng không phải quy trình knowledge mining.

Ghi nhớ

⚠ Năm loại workload AI trong đề Fundamentals — bảng phải thuộc: | Workload | Dịch vụ chính | |---|---| | ⚠ Computer Vision | ⚠ AI Vision, Custom Vision | | ⚠ NLP | ⚠ AI Language, AI Speech, Translator | | ⚠ Knowledge Mining | ⚠ Azure AI Search | | ⚠ Document Intelligence | ⚠ AI Document Intelligence | | ⚠ Generative AI | ⚠ Azure OpenAI, AI Foundry |

Từ khoá nhận diện:

"trích tri thức từ khối tài liệu lớn" → ⚠ Azure AI Search "tìm kiếm ngữ nghĩa, vector search" → ⚠ Azure AI Search "nền tảng RAG" → ⚠ Azure AI Search làm kho vector "trích trường từ biểu mẫu" → ⚠ Document Intelligence

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Chỉ mục có được cập nhật khi tài liệu thay đổi không | | | Có dùng tìm kiếm hybrid không | | | Đoạn tài liệu chia nhỏ có hợp lý không | ⚠ quyết định chất lượng RAG |

Và thành phần quyết định chất lượng của một hệ thống RAG mà nhiều người bỏ qua: khâu tìm kiếm, không phải mô hình sinh ngữ. Đoạn tài liệu lấy sai thì mô hình dù giỏi tới đâu cũng chỉ trả lời sai một cách thuyết phục.

Đáp án

B — Giải pháp AI đáng tin cậy và an toàn đòi hỏi KIỂM THỬ và GIÁM SÁT LIÊN TỤC để bảo đảm mô hình hoạt động đúng như dự định.

Vì sao đúng

⚠ Mô hình AI KHÔNG đứng yên sau khi triển khai:

⚠ Triển khai
        ↓ ⚠ theo thời gian
⚠ Dữ liệu đầu vào thay đổi (data drift)
⚠ Hành vi người dùng thay đổi
⚠ Thế giới thay đổi
        ↓
⚠ Mô hình xuống cấp ÂM THẦM
        ↓
⚠ Chỉ giám sát liên tục mới phát hiện được

⚠ Đây là khác biệt lớn giữa phần mềm truyền thống và hệ thống AI: ⚠ phần mềm không tự xấu đi, ⚠ mô hình thì có.

Vì sao các phương án khác sai

• A (chỉ cần cân nhắc với lĩnh vực trọng yếu như y tế, hàng không) — ⚠ SAI: ⚠ mọi hệ thống AI đều cần độ tin cậy; ⚠ một chatbot bán hàng bịa cam kết cũng gây thiệt hại thật.

• C (huấn luyện và kiểm thử xong là triển khai được, không cần lo thêm) — ⚠ chính là quan niệm nguy hiểm nhất.

• D (thiết kế để KHÔNG BAO GIỜ hỏng và có RỦI RO BẰNG KHÔNG) — ⚠ bất khả thi: ⚠ "fail safely" nghĩa là ⚠ hỏng một cách AN TOÀN, không phải "không bao giờ hỏng".

Ghi nhớ

⚠ Reliability & Safety — nội dung phải thuộc: | Nội dung | Chi tiết | |---|---| | ⚠ Kiểm thử kỹ TRƯỚC khi triển khai | | | ⚠ GIÁM SÁT LIÊN TỤC sau triển khai | ⚠ quan trọng không kém | | ⚠ Thiết kế để HỎNG AN TOÀN | ⚠ fail safely, không phải never fail | | ⚠ Có con người giám sát ở khâu rủi ro cao | | | ⚠ Kế hoạch quay lui khi có sự cố | |

Từ khoá nhận diện:

"kiểm thử và giám sát liên tục" → ⚠ Reliability & Safety "không bao giờ hỏng, rủi ro bằng không" → ⚠ bất khả thi, luôn là phương án sai "chỉ cần với lĩnh vực trọng yếu" → ⚠ sai — áp dụng cho mọi hệ thống

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có giám sát drift không | | | Có tiêu chí khi nào huấn luyện lại không | | | Hệ thống hỏng thì hành vi mặc định là gì | ⚠ phải an toàn |

Và khác biệt căn bản giữa triển khai phần mềm và triển khai mô hình AI: phần mềm hoạt động đúng hôm nay sẽ đúng vào năm sau; mô hình thì không. Ngày triển khai là ngày bắt đầu giám sát, không phải ngày kết thúc dự án.

Đáp án

D — Tô màu ảnh (Image coloring).

Vì sao đúng

⚠ Đây là câu PHỦ ĐỊNH — tìm cái KHÔNG có.

⚠ Azure AI Vision KHÔNG tô màu ảnh đen trắng — ⚠ đó là bài toán ⚠ sinh ảnh (generative), không phải phân tích ảnh.

⚠ AI Vision = PHÂN TÍCH ảnh có sẵn
   ⚠ đọc ra thông tin
⚠ KHÔNG PHẢI = TẠO hoặc SỬA ảnh
   ⚠ đó là việc của DALL-E, GPT-image

Vì sao các phương án khác sai

• A, B, C — ⚠ đều là tính năng thật của Azure AI Vision, ⚠ nên không phải đáp án của câu phủ định.

Ghi nhớ

⚠ Azure AI Vision — CÓ và KHÔNG CÓ: | CÓ | KHÔNG CÓ | |---|---| | ⚠ Object detection | ⚠ tô màu ảnh | | ⚠ Face detection | ⚠ sinh ảnh mới | | ⚠ OCR / Read | ⚠ xoá vật thể khỏi ảnh | | ⚠ Tag và mô tả ảnh | ⚠ nâng độ phân giải | | ⚠ Smart crop | ⚠ semantic segmentation | | ⚠ Background removal | ⚠ nhận diện danh tính người | | ⚠ Nội dung người lớn | ⚠ suy đoán tuổi, giới tính, cảm xúc ⚠ đã gỡ 2022 | | ⚠ Video Retrieval | |

Từ khoá nhận diện:

"phân tích ảnh có sẵn" → ⚠ AI Vision "tạo ảnh từ mô tả" → ⚠ DALL-E qua Azure OpenAI "tô màu, phục chế ảnh cũ" → ⚠ KHÔNG phải AI Vision

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Câu hỏi có chữ NOT hay KHÔNG không | ⚠ đọc kỹ trước tiên | | Cần phân tích hay cần sinh ảnh | | | Tính năng đó còn tồn tại không | ⚠ thuộc tính khuôn mặt đã gỡ |

Và cách vấp ngã phổ biến nhất ở câu phủ định trong phòng thi: đọc lướt, thấy một phương án đúng về dịch vụ rồi chọn ngay. Ở câu "cái nào KHÔNG phải", ba phương án đúng chính là ba cái bẫy.

Đáp án

D — Nó cung cấp giao diện trực quan KHÔNG CẦN VIẾT MÃ để xây dựng luồng học máy.

Vì sao đúng

⚠ Azure ML designer là công cụ kéo–thả:

⚠ Kéo module lên canvas
   ⚠ Dữ liệu → Làm sạch → Chia tách
   ⚠ → Huấn luyện → Chấm điểm → Đánh giá
        ↓ ⚠ nối các module bằng đường
⚠ Bấm Submit
        ↓
⚠ Đăng ký mô hình và triển khai
        ↓
⚠ KHÔNG viết một dòng mã nào

⚠ Đối tượng nhắm tới: ⚠ người hiểu nghiệp vụ nhưng chưa thạo lập trình.

Vì sao các phương án khác sai

• A (chỉ dùng được với dữ liệu có cấu trúc) — ⚠ SAI: ⚠ designer làm được cả ảnh và văn bản.

• B (đòi lập trình Python nâng cao) — ⚠ NGƯỢC hoàn toàn với mục đích của designer.

• C (chỉ để trực quan hoá dữ liệu) — ⚠ SAI: ⚠ designer ⚠ huấn luyện và triển khai mô hình thật, không phải công cụ vẽ biểu đồ.

Ghi nhớ

⚠ Ba cách làm việc trong Azure Machine Learning: | Cách | Dành cho | |---|---| | ⚠ Designer | ⚠ kéo-thả, KHÔNG CẦN CODE | | ⚠ AutoML | ⚠ tự thử nhiều thuật toán, ít code | | ⚠ Notebook / SDK | ⚠ toàn quyền, cần biết Python |

Từ khoá nhận diện:

"kéo thả, không cần code, luồng trực quan" → ⚠ Designer "tự chọn thuật toán tốt nhất" → ⚠ AutoML "toàn quyền kiểm soát" → ⚠ SDK trong notebook "kho lưu mô hình đã huấn luyện" → ⚠ Model registry

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Người dùng có biết Python không | ⚠ quyết định chọn designer hay SDK | | Có cần huấn luyện lại theo lịch không | ⚠ dựng thành pipeline | | Compute có tắt khi không dùng không | ⚠ instance tính tiền theo giờ chạy |

Và điều dễ quên nhất khi mới dùng Azure ML, thường phát hiện qua hoá đơn: compute instance vẫn tính tiền khi chỉ bật mà không chạy gì. Đặt lịch tự tắt ngay từ khi tạo.

Đáp án

D — Kiểm tra độ chính xác của mô hình trên dữ liệu MỚI.

Vì sao đúng

⚠ Ba tập dữ liệu, ba vai trò khác nhau: | Tập | Vai trò | |---|---| | ⚠ Training | ⚠ mô hình HỌC từ đây | | ⚠ Validation | ⚠ kiểm trên dữ liệu CHƯA HỌC, chỉnh mô hình | | ⚠ Test | ⚠ đánh giá cuối cùng, chỉ dùng MỘT lần |

⚠ Chỉ chấm trên dữ liệu ĐÃ HỌC
        ↓
⚠ Điểm cao giả tạo
        ↓ ⚠ mô hình chỉ đang HỌC THUỘC
⚠ Ra thực tế → SAI
        ↓
⚠ Validation phát hiện điều đó

Vì sao các phương án khác sai

• A (tăng kích thước dữ liệu huấn luyện) — ⚠ NGƯỢC: ⚠ tách validation ⚠ giảm dữ liệu huấn luyện.

• B (huấn luyện mô hình) — ⚠ đó là việc của tập training; ⚠ dùng validation để huấn luyện là ⚠ phá bỏ toàn bộ mục đích của nó.

• C (lưu trữ dữ liệu thô) — ⚠ không liên quan.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ gần trùng #17958 và #17922 trong cùng đợt.

⚠ Cách chia dữ liệu: | Tỉ lệ | Ghi chú | |---|---| | ⚠ 70/15/15 hoặc 80/10/10 | ⚠ thường dùng | | ⚠ Chia NGẪU NHIÊN | ⚠ trừ dữ liệu chuỗi thời gian | | ⚠ Dữ liệu thời gian: chia theo THỜI ĐIỂM | ⚠ quá khứ huấn luyện, tương lai kiểm | | ⚠ Giữ tỉ lệ nhãn giống nhau | ⚠ stratified | | ⚠ Sai nghiêm trọng | ⚠ để dữ liệu rò rỉ giữa các tập |

Từ khoá nhận diện:

"kiểm trên dữ liệu chưa học" → ⚠ validation "đánh giá cuối cùng, một lần" → ⚠ test set "đúng cao khi huấn luyện, sai khi thực tế" → ⚠ overfitting "chia nhiều lần lấy trung bình" → ⚠ cross-validation

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có dữ liệu nào rò rỉ giữa các tập không | | | Test set có thực sự chỉ dùng một lần không | | | Chênh lệch train và validation là bao nhiêu | ⚠ chênh lớn = overfitting |

Và con số nói lên nhiều nhất về sức khoẻ một mô hình, hơn cả độ chính xác tuyệt đối: khoảng cách giữa điểm huấn luyện và điểm validation. Khoảng cách lớn nghĩa là mô hình đang thuộc lòng chứ không đang học.

Đáp án

D — Dịch có khả năng mở rộng (Scalable Translation).

Vì sao đúng

⚠ Azure AI Translator là dịch vụ đám mây thiết kế cho khối lượng lớn: | Năng lực | Nội dung | |---|---| | ⚠ Dịch hàng loạt tài liệu | ⚠ Document Translation | | ⚠ Hơn 100 ngôn ngữ | | | ⚠ Gọi song song, không cần dựng hạ tầng | | | ⚠ Trả tiền theo lượng ký tự | |

⚠ Hàng nghìn tài liệu
        ↓ ⚠ Document Translation API
⚠ Dịch hàng loạt, GIỮ NGUYÊN ĐỊNH DẠNG
   ⚠ Word, PDF, PowerPoint
        ↓
⚠ Ghi vào kho lưu trữ đích

Vì sao các phương án khác sai

• A (Real-time Translation) — ⚠ bẫy hợp lý nhất: ⚠ đúng là có tính năng thời gian thực, ⚠ nhưng ⚠ thời gian thực nói về ĐỘ TRỄ từng câu, ⚠ không phải ⚠ KHỐI LƯỢNG LỚN như đề hỏi.

• B (Custom Translation) — ⚠ nói về ĐỘ CHÍNH XÁC theo thuật ngữ riêng, không phải khối lượng.

• C (Text-to-Speech) — ⚠ thuộc AI Speech, không phải dịch.

Ghi nhớ

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ câu này ⚠ cùng chủ đề Translator với #17943 và #17961 nhưng ⚠ hỏi khía cạnh KHÁC.

⚠ Azure AI Translator — bốn tính năng phải phân biệt: | Tính năng | Giải quyết | |---|---| | ⚠ Text Translation | ⚠ dịch chuỗi, độ trễ thấp | | ⚠ Document Translation | ⚠ dịch tệp, giữ định dạng, khối lượng lớn | | ⚠ Custom Translator | ⚠ thuật ngữ riêng của ngành | | ⚠ Transliteration | ⚠ chuyển hệ chữ viết, không dịch nghĩa |

Từ khoá nhận diện:

"hàng nghìn tài liệu, khối lượng lớn" → ⚠ Document Translation, scalable "giữ nguyên định dạng Word, PDF" → ⚠ Document Translation "thuật ngữ riêng dịch sai" → ⚠ Custom Translator "dịch tức thời khi trò chuyện" → ⚠ Text Translation thời gian thực

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Cần dịch chuỗi hay dịch TỆP | ⚠ quyết định chọn API nào | | Có thuật ngữ riêng cần giữ đúng không | | | Khối lượng bao nhiêu ký tự mỗi tháng | ⚠ ảnh hưởng chi phí |

Và điều quyết định bạn chọn đúng ở nhóm câu hỏi Translator: đọc kỹ đề đang nhấn vào NHANH, NHIỀU hay ĐÚNG. Ba từ đó dẫn tới ba tính năng hoàn toàn khác nhau của cùng một dịch vụ.