Reading objectives and introduction
This is an English translation of the published reading. We will outline the AI service supply chain, learn how to identify, compare, and select services, and understand different ways to enable general models to use organizational data.
Before choosing tools, first clarify: are you purchasing computing infrastructure, models, development tools, or already-business-facing applications? Different layers address different problems.
1. Overview of AI Service Supply Chain
The original material starts from providers such as AWS, Google, Microsoft, and IBM, comparing infrastructure, tools, and platforms, then examines models and ecosystems from companies like OpenAI, Anthropic, and Hugging Face, as well as specialized services such as information retrieval and classification.
The purpose is not to provide a permanent ranking, but to give procurement and development teams a map to refer to. The openness, capabilities, licensing, support models, and costs of the model must be evaluated against the specific project requirements.
II. How to Find and Evaluate Business Services
First, specify the purpose, type of data, performance requirements, budget, need for proprietary information, and the team's technical capabilities, then compare performance, cost, integration, privacy, and scalability.
Business services may reduce the need for in-house development, but one should not assume existing products are necessarily suitable. Sales demonstrations and actual data results are two different forms of evidence.
Three: Let general models integrate with your own materials
Prompt engineering provides tasks and boundaries in the current input; RAG provides relevant retrieved materials; fine-tuning adjusts model behavior using examples; embeddings support content representation and retrieval; tool calling connects to actual systems; MCP specifications define a way to connect capabilities.
Technical summary in the main text and Seven expanded text passages on AI services and algorithms Share identical subtitle materials; complete translations are uniformly saved on this page. This page retains different explanations on supply chain, selection, and summary.
Note: The original overview referred to MCP as "a new standard for managing model inputs," which is an inaccurate characterization. It enables standardized connections between AI applications and external capabilities, without automatically providing memory or guaranteeing safety. The full original explanation and correction can be found in the expanded section above.
Video script one: Which layer are the suppliers located in?
Let's first create a map of the AI service supply chain: who are the providers, and what do they offer: models, system tools, infrastructure, frameworks, or development workbenches? What are the differences between them? Only by understanding these can we make more informed service selections.
Start with infrastructure. Cloud providers such as AWS, Microsoft Azure, and Google Cloud offer not only computing and storage, but also higher-level development environments that enable data professionals and developers to turn capabilities into practical applications.
The original explanation uses AWS SageMaker as a familiar example, discussing how service providers transform internal development tools into commercial platforms, and mentions an early public release around 2017. This provides historical context and does not imply that the current product form is identical.
As the market matures, many tasks no longer require building models from scratch. The original presenter described that, over a certain period, their client projects increasingly relied on off-the-shelf capabilities and less on custom training. This reflects personal project experience and cannot be generalized to imply that all needs have ready solutions; it does not mean that training or algorithm research has become unimportant.
But before starting construction, it's worth taking time to carefully investigate: are there already suitable services available? Sometimes, clearly redefining the problem helps identify the right approach.
Cloud Platform and Integration Environment
AWS SageMaker and Bedrock offer different layers of functionality: the former targets machine learning development workflows, while the latter provides access to foundational models and application capabilities. A unified entry point may reduce some onboarding efforts, but users should proactively compare options rather than inadvertently missing a feature simply because they're unfamiliar with a particular one.
The original explanation used broad statements when mentioning model providers. The specific models, features, and regions currently supported should be verified in the official directory, and outdated overviews should not be considered a complete list.
Google Cloud and Vertex AI both involve building, training, deploying, and using existing models. The ecosystem an organization originally uses can impact transition and operations. The original presenter noted that some projects enter a Google environment because clients already use it, making it easier to maintain consistency with the existing environment; personal familiarity with a particular path may differ. This highlights that team dynamics and client-specific conditions also influence the choice, not just objective performance rankings.
Organizations with a heavy Microsoft ecosystem will seriously consider Azure. IBM is often cited as an example of vertical industry solutions, such as finance, manufacturing, and other specialized sectors. For projects involving clearly defined rules and strong professional requirements, industry-specific capabilities should be reviewed during the assessment phase; however, specific service validation is still required, not just based on the company name.
Generative model providers
Originally, the explanation shifted toward the rapidly evolving generative ecosystem, describing OpenAI as a general-purpose and user-friendly solution; describing DeepSeek as an alternative service category, and mentioning that certain interface formats are compatible, which can reduce the need for code changes when testing different providers.
Interface compatibility has scope, and one cannot conclude that all parameters, models, tools, and outputs are identical based on that. Statements in the materials about a service being "less than a year old" also need to be contextualized with specific product and recording timestamps, and cannot be taken as accurate representations of the company's history.
It then mentions Anthropic's emphasis on safety, Google DeepMind's research, and Meta's model ecosystem. The original text refers to Meta or certain Mistral models collectively as open-source, which requires further clarification regarding open weights, specific licenses, and actual usage conditions; it is also incorrect to infer that a model must have used all data simply because the platform owns certain data.
Cohere is used to illustrate the path toward business and language applications, while Mistral is used to discuss lightweight and efficiency-oriented directions. These are summaries of the original materials, not fixed characteristics of all versions, and do not equate to completed evaluations under identical conditions.
Hugging Face provides a wide range of models, development tools, and related resources. When entering the models directory, you can browse models suited to specific tasks, model cards, evaluations, and licenses. Some specialized models are trained on unique datasets, which may warrant further investigation; however, an increasing number or top ranking does not automatically indicate suitability for your specific dataset.
The original explanation concludes by once again mentioning Vertex AI, Bedrock, and Azure's machine learning environments, reminding that before starting from scratch, one should be aware of available mature tools. When deciding to build from scratch, such a decision should be based on careful comparison, not simply due to the absence of alternative options.
Video Script Two: Discovery, Comparison, and Selection
How to choose AI or machine learning services for a project? Many services provide HTTP APIs, and teams need to understand request, response, and JSON-based structured formats. The original text also mentions YAML, but the specific format accepted by individual interfaces is determined by the documentation.
Do not assume you must build it from scratch, nor assume that existing services are necessarily suitable. First identify potential candidates, then verify conditions, test, and select.
Put the problem clearly
What are you solving? Translation, chatting, agent tasks, visual recognition, recommendation, summarization, or customer behavior analysis? Different problems require different capabilities. Without a clear problem statement, it's difficult to select the right tool.
Can be phrased as "tag customer service emails by topic." This is simpler, more specific, and easier to evaluate than "adopting AI in the company."
Understand data and requirements
Is the data text, images, audio, video, or tables and numbers? Has it been obtained? Does it have labels? Has it been cleaned? Is it usable? No model can automatically correct all errors in data.
The original text uses text models, visual recognition, and speech services as examples to illustrate the approach of first identifying candidate directions based on tasks, then conducting actual testing.
Requirements must also be specific: Is real-time performance required? How to balance accuracy and speed? Who are the users: ten, one hundred, or a much larger scale? Is this for a prototype, a minimum viable product, or a full-scale enterprise system? Is technical support and service level agreements necessary? What if usage increases by six months; how will the system scale?
These directly affect budgets and plans. One cannot judge long-term investments based solely on the costs of a small number of calls during development.
Private data and team capabilities
Does the task require proprietary products, documentation, or internal rules? Identifying common objects is different from identifying specific items belonging to a particular organization. If private context is required, research retrieval, embedding, fine-tuning, or tool querying may be considered; exact support scope will be confirmed based on service availability.
Honestly recognize the team's capabilities. Do you have machine learning engineers or application developers? Are they familiar with APIs? If not, consider starting with a simpler interface or using existing upload methods. Avoid letting technical direction compromise maintainability.
Teams with less technical expertise should particularly focus on ready-made models, clear documentation, SDKs compatible with their language, and support. Tool complexity should not exceed the range that the team can understand and maintain.
"Five comparisons"
First, performance and quality. Does it work effectively on its own data? Don't rely on sales promotions; instead, run samples. When possible, compare it against competing solutions using the same evaluation criteria.
Second, pricing and limitations. Based on calls, tokens, or a fixed monthly fee? Are trial costs low, but does the cost increase rapidly after deployment? Clarify the cost structure, caps, and any additional steps before making any commitments.
Third, implementation difficulty. Are the interfaces, documentation, and code repositories clear? Does the support team know the relevant languages? If integration takes weeks, or requires extensive retraining, is it still worthwhile?"
Fourth, privacy and applicability requirements. Where are the data stored, is encryption used, who has access, and are there cross-border restrictions? Special attention is required in fields such as healthcare and finance. A service provider's claim of meeting certain standards does not substitute for specific project evaluation.
Fifth, speed and scalability. Will performance degrade as usage increases? Does it support the required concurrency and service conditions? Not only current needs, but also future requirements.
Connect these steps: define the problem, understand the materials and requirements, get to know the team, then compare based on performance, cost, integration, privacy, and scalability. Identifying existing capabilities, testing, refining, and integrating is part of the building process; it's not necessary to develop every component from scratch.
Video Script Three: Balancing RAG with Precise Business Queries
In the previous several customization approaches, the explanations often compare RAG with function calling. Vector retrieval can quickly provide relevant context snippets, but it may not offer the same level of control over the structure and exact scope of the data as a business query does.
For example, "display the sales report from the previous quarter" often implies specific time periods, fields, and calculation methods. Retrieved snippets may be helpful, but do not necessarily constitute the complete report needed.
Include relevant snippets in the prompt and then ask the model to respond based on them, achieving some results with minimal development work. However, for very precise data packages and formatting, explicit programming for querying, verifying, and organizing results may be necessary.
Function calls provide this route, typically requiring more interface work and development capabilities. It is not inherently correct and still requires verification of parameters, permissions, timing, and return values.
Therefore, when quickly building background Q&A, RAG can be studied; when precise business data is needed, tool queries can be added. The two can be combined, and the choice depends on actual requirements, rather than arbitrarily favoring one over the other.
Related Reading
Continue reading when multiple steps are required Business Agents ; How do services actually connect to each other, see MCP and API .
Reference and Extended Reading
The following is an editorial addition.
- AWS Bedrock: Supported Foundation Models : English, query the actual model and region, avoid treating old introductions as the current directory.
- Google Vertex AI Documentation : Chinese, query development and model service capabilities.
- Hugging Face Model Card Guidelines : English, where should one query about purposes, limitations, data, and licensing information?
- MCP Official Getting Started : English, distinguish between protocol connections and prompts, retrieval, and model memory.