Reading Objectives
This page first reviews AI services, then introduces the path of building your own algorithms. The focus is on creating a capability map: when faced with a need, you should know whether it aligns more closely with generative, retrieval, recommendation, classification, clustering, or regression tasks.
Following the main body are thirteen corresponding Chinese video scripts, maintaining the original explanation order and examples; where references to old products, personal experience, or conceptual simplifications are made, separate translation notes are provided.
After these thirteen segments, seven additional extended scripts on model customization are provided: Introduction, Prompt Engineering, RAG, Fine-Tuning, Function Calling, Embeddings, and MCP. This page totals twenty matching scripts. When encountering identical materials in the second session, direct links to the corresponding sections here will be used.
1. Quick Recap of AI Services
Core capabilities provided by major AI platforms include generative AI for text, image, and audio, as well as tools for classification, clustering, and recommendation. These categories form the foundation of the modern AI toolkit.
Regardless of whether you're using OpenAI, AWS, Microsoft Azure, or Hugging Face, you're likely to encounter these service types repeatedly. Being able to identify and clearly articulate what each service provides is the first step toward deeper comparative analysis.
2. Building Your Own Algorithms
Building your own AI algorithms from scratch is now a less common but still important approach. Many teams use existing models and services, but custom algorithms provide more control and may be necessary for highly specialized requirements.
Development tools include PyTorch、TensorFlow、JAX、scikit-learn ; platforms supporting experimentation and deployment include SageMaker、Colab、Azure ML Studio . Understanding this path helps determine when it's worth building in-house, why it's necessary, and what tools are available.
Note: This section describes tools and pathways, not a detailed verification of current product names, versions, pricing, or available features. Actual selection should always be cross-checked against official documentation.
Video Script One: Mapping AI Service Landscape
First, quickly review the major AI services available in the market, such as generative AI, recommendation engines, and computer vision. Then, introduce the key players providing these tools, such as Amazon Web Services, Microsoft, Google, Meta, and OpenAI.
What needs to be learned goes beyond simply finding tools; it includes how to discover, evaluate, and select tools that match your specific needs, how to customize services using your proprietary data, and why it's now less common than before to build algorithms from scratch.
The goal is to form a clearer map of AI capabilities, so you know how to navigate and find your direction within it.
Video Script Two: Overview of Algorithms
When people commonly refer to 'AI' in daily conversation, they often group together various data-driven algorithms under one umbrella. In practice, the actual tools may combine statistical regression, machine learning, and other AI methods. Here, we first look at commercially oriented services aimed at broad user bases, which share many common usage patterns.
The following section will review several common algorithm categories encountered in real-world products and client projects.
Translation note: The original subtitle broadly labeled these algorithms as 'reinforcement learning algorithms,' which is inaccurate. The regression, classification, and clustering methods introduced later are not all forms of reinforcement learning. This translation preserves the intent that 'multiple data-driven methods are collectively referred to as AI' and clearly distinguishes between concepts. Personal and employer-related introductions unrelated to knowledge have been removed.
Video Script Three: Generative AI
Generative AI can be applied to a wide range of tasks. It uses machine learning models, such as neural networks, to learn patterns from existing data and then generate new text, images, or music.
It does not simply copy and paste training materials, but instead predicts and generates outputs based on learned patterns. ChatGPT is an example of text generation, while Stable Diffusion is an example of image generation. Pre-trained Transformer models and generative adversarial networks are common model approaches in such systems.
For well-defined data sets, such as program source code or service desk tickets, these methods can be particularly useful. This also helps explain why GitHub Copilot became one of the first widely accessible generative AI products.
Translation note: The phrase 'generating new outputs' does not guarantee originality, nor does it ensure that the content is distinct from existing materials or automatically holds usable rights. There is a transcription error in the subtitle regarding the product name; this version corrects it to GitHub Copilot based on context.
Video Script Four: Information Retrieval
Information retrieval is an important way of applying large language models to specific tasks. A typical scenario is: the user poses a natural language question, and the required information is not present in the original training data of the model.
Weather, especially short-term weather forecasting, is a clear example. Training large language models takes time, and the training data usually has a cutoff date, which may lag behind the time of the query by months or even years. Therefore, relying solely on information stored in the model's parameters at training time cannot accurately predict the weather for a future date.
However, if a chat product integrates external tools such as weather queries, it can provide up-to-date weather information for locations like Vancouver. This does not mean the model suddenly knows the future; it means the system can access external information.
This is just one of many examples: a general large language model can be combined with information retrieval capabilities to become a question-answering system tailored to specific datasets. We will explore further how it connects to data.
Translation note: The subtitle says 'now you can get accurate forecasts by asking a certain product,' which is an example from that time and does not guarantee that every account, mode, or query has access to weather tools. Whether actual queries are made and what data is retrieved still needs to be verified.
Video Script Five: Recommendation Engine
Recommendation engines are programs that suggest content such as movies, songs, or products to users. They estimate what you might like next, based on your past choices and those of other users.
Common methods include collaborative filtering, leveraging user relationships, and content-based filtering: identifying content similar to existing preferences and then offering suggestions.
Netflix is a straightforward example. On e-commerce websites, features like 'customers who bought this also bought' or 'you might also like' represent similar capabilities applied to different tasks.
The text also mentions that Netflix launched a recommendation algorithm competition in 2006, inviting external participants to improve its algorithms, with a prize of one million US dollars.
Translation note: The original subtitle referred to this activity as an 'annual competition.' This translation retains the substantive information that the initiative was a prize-driven effort to improve algorithms; the term 'annual' is not supported by the provided materials, and no implication is made that the competition is still ongoing.
Video Script Six: Anomaly Detection
Anomaly detection first analyzes large volumes of normal data to establish a baseline understanding of what constitutes a 'normal state' in a given context, then identifies phenomena that deviate from that state.
These anomalies may indicate fraud, device faults, or human errors. Machine learning methods can help quickly identify unusual events. Financial institutions, banks, and organizations with back-end business processes may leverage such capabilities.
An anomaly is an indicator that requires investigation; it does not mean fraud or failure has been proven.
Video Script Seven: Classification
Classification algorithms learn to assign items into predefined categories. During training, labeled data is provided (for example, images of dogs and cats) so the model learns how to distinguish between them. When encountering new images outside the training set, it can attempt to predict labels based on learned patterns.
Common methods include decision trees, support vector machines, and neural networks.
Early consumer-facing applications of facial recognition demonstrate the practical use of such capabilities. The text cites Facebook's photo recognition around 2015 and Microsoft Cognitive Services' object detection via REST API at the time as examples.
Today, object recognition is present in many products. For instance, photo services can allow users to search for photos based on objects in the image, rather than relying solely on file names. If mobile photos are synced to the service, the system may be able to quickly locate specific objects across large photo collections.
These services showcase how models can assist users in retrieving content from vast image libraries and represent one of the key commercial capabilities discussed here.
Translation note: The historical product examples mentioned here are retained from the original explanation, with personal experiences and anecdotes removed. Classification and object detection are related but distinct tasks: detection often requires locating objects. Systems can make mistakes, and it is not reliable to conclude that 'any object is easily recognizable' based on such results.
Video Script Eight: Clustering
Clustering examines a batch of data and groups items based on their similarity. The key point is that the system does not have preassigned category labels for each object; it instead attempts to discover underlying structures on its own.
Different algorithms have varying requirements regarding the number of groups and grouping methods. Some require a pre-specified number of groups, while others determine groupings based on data and parameters.
The text highlights K-means as a key example, noting its relative simplicity and high efficiency, making it common in commercial applications, and recommends beginners focus on it first.
Translation note: The original subtitle stated that clustering 'does not require a training set, just an algorithm,' which may lead to misunderstanding. Clustering still requires input data, and many methods involve fitting; what it typically lacks is ground-truth labels from supervised learning. The original subtitle also recommended ignoring other methods based on personal experience, which cannot be considered a comprehensive selection guide. K-means is not the only clustering method; others may be more suitable depending on data, similarity definitions, and grouping objectives.
Video Script Nine: Regression
Regression learning predicts a numerical value based on existing attributes and historical data. House price prediction is a good example: by observing how house area correlates with price, a pattern is identified, and prices can be predicted based on area.
Expressing this relationship as a formula yields a model capable of computing predicted values. The text mentions two common forms: linear regression and polynomial regression, which appears in curve-fitting tasks.
The key point is that it predicts a numerical value, not assigning a category.
View textual explanation of the diagram
Classification answers which category a sample belongs to, using scores and thresholds to determine the category; regression predicts a continuous numerical value. When choosing between the two, the cost of false positives, false negatives, or numerical errors must also be considered.
Video Script Ten: Computer Vision
Computer vision enables systems to process and interpret images and videos. This can be analogized to the human eye receiving visual input and the brain processing it, but this analogy does not imply that the model actually perceives images in a human-like way.
The system can recognize faces, animals, objects, and signs. It identifies visual patterns through machine learning and corresponding models.
Self-driving cars provide a clear example: cameras in the vehicle observe the surrounding environment, and the system analyzes images to detect traffic lights, stop signs, vehicles, and pedestrians. The text uses a panoramic view of the vehicle's surroundings to illustrate this process.
Other common applications include facial unlocking, X-ray image analysis, surveillance cameras, mobile robots capable of navigating and perceiving environments, and visual analysis in sports broadcasts.
Translation note: The specific sensors, coverage, and safety capabilities of actual vehicles depend on the real-world systems and cannot be inferred from this conceptual example. Any mention of personal involvement in the field has been removed.
Video Script Eleven: Natural Language Processing
Natural Language Processing (NLP) studies how computers can process human language interactions, including speaking, reading, and writing. Examples like Siri and Alexa are easily accessible.
This field involves a wide range of research directions, with relevant work predating mature commercial services. The text review covers research from the 1970s and 1980s, as well as the Dragon Dictate speech-to-text product that emerged around 1991. It describes early products as expensive and error-prone, and mentions that later companies in this space were acquired.
Translation note: The original subtitle provided an oral estimate of early licensing fees at approximately $12,000 to $14,000, and speculated on their relationship to modern office software, without providing supporting evidence. Here, the historical and uncertain nature of these claims is preserved, and the oral fee or product relationship is not presented as verified facts.
NLP is not limited to speech; it also includes text preprocessing. One example is adding a processing layer between the user interface and a large language model, performing quality checks on prompts before passing them to the model.
Python's Levenshtein-related libraries can be used to compare string differences, such as identifying common spelling errors. In cases with clear rules, the system can first correct common mistakes before sending the input to the model, in hopes of improving results.
Language-related features in applications such as Signal, WhatsApp, and Microsoft Word also help illustrate the broad scope of this field.
Translation note: Edit distance only measures string differences and cannot independently handle full grammatical understanding or fact verification; whether to automatically rewrite user input should also avoid altering the original intent. The library name is rendered as Levenshtein in context.
Video Script Twelve: Reinforcement Learning
Reinforcement learning learns by trying actions and receiving feedback. When actions lead to better outcomes, rewards are given; worse outcomes may result in lower rewards or penalties. This is somewhat analogous to training an animal to perform actions through feedback, though only a conceptual analogy.
The system gradually learns which actions are more likely to yield high returns and adjusts its choices accordingly. Applications in gaming, robotics, autonomous driving, and certain recommendation systems may employ this approach.
The original explanation notes that this section is a conceptual introduction, not personal implementation experience; therefore, personal experience attribution is not retained here.
Translation note: Rewards are signals defined by humans or systems and do not necessarily align with the actual long-term goals. Not all games, driving, or recommendation systems use reinforcement learning.
Video Script Thirteen: Review and Temporal Context
A lot of content was covered earlier. One temporal context to remember is that this text was recorded in Q2 2025 The services and algorithmic applications discussed (especially generative AI) were rapidly evolving at the time.
Significant financial and research investment has kept this field continuously evolving. In a year or two, the service forms may have already changed.
Therefore, if planning to use these services in a real project, technical updates must be considered, and long-term plans should not be based solely on the information available at the time of recording.
The following system reading will continue discussing data foundations and privacy. What services can do is one part; equally important are what data they can access, how they use it, and how it is verified; these factors also determine real-world effectiveness.
Extended Script One: Integrating AI into Your Business
The previous discussion focused on out-of-the-box capabilities. The next section turns to how to customize an AI system by combining one's own data, tone, and rules. Techniques such as prompt engineering, retrieval augmentation, fine-tuning, embeddings, and function calling are all viable approaches. To make the system more aligned with business needs, it's important to understand how each method alters the system's behavior.
Extended Script Two: Prompt Engineering
A prompt is a way of telling the AI what you'd like it to do; it's not just asking a question. It can be structured and purposeful, including instructions, questions, background context, examples of ideal responses, and boundaries that should not be crossed.
Many chat interfaces use different character roles. A system role defines overall behavior, for example, 'you are a helpful assistant'; changing the role description to a specific domain may alter the response style, but does not confer genuine professional expertise or guarantee accuracy.
User roles represent requests made by users through the application. Assistant roles represent the model's previous responses. Continuity in conversation is possible because the application manages and passes along the relevant history; the sense of continuous dialogue in the interface should not be mistaken for the model automatically retaining full memory.
Translation note: The original explanation stated that 'the assistant role is used to serialize the entire history,' which requires a more precise distinction: history typically includes user, assistant, and tool messages; applications may resend, compress, or manage them via state mechanisms. Model parameter memory, current context, and application-level long-term memory are not the same mechanisms.
The same model can produce different results depending on the prompt structure. For example, 'How is the weather?' versus 'You are an outgoing travel planner assistant; what's the weather like in Paris this weekend, and what clothes should I bring?' differ significantly in context, task, tone, and output expectations. To query current weather, actual weather data must still be obtained; real-time facts cannot be inferred solely from role descriptions.
When writing prompts, clearly define the role and format, provide expected examples, and set boundaries, such as only responding based on the following materials. Then, iteratively refine based on the results. Effective prompts are clear, simple, consistent, and specifically designed toward a defined goal.
Multiple prompts can be chained together, variables passed between them, and templates saved. Prompt engineering requires both design and validation through actual output.
Extended Script Three: RAG: Retrieving Data Before Responding
RAG stands for Retrieval-Augmented Generation. If you want an AI to consult internal documents or a knowledge base before generating a response, RAG is a suitable approach.
Language models have limited context capacity; longer inputs may also increase costs. Instructions, questions, and conversation history all consume context; when conversations grow, do not count only the user's recent input.
Translation note: The original explanation described common window sizes as approximately 4,000 tokens and roughly equated them to 4,000 words, reflecting an outdated context and being inaccurate. Model context windows vary widely, and tokens are not equivalent to words. Specific capacity and billing details should be verified with the actual model; even loading an entire database into a single input may still be impractical due to length, cost, and noise.
RAG typically begins by organizing documents, tables, or FAQs into appropriate chunks and building an index. When using vector retrieval, an embedding model converts each chunk into a vector, which is stored and queried in a vector database. After a user's query, the system first retrieves relevant chunks, then combines the query with the selected chunks and passes them to the generative model.
View textual explanation of the diagram
Data preparation paths include chunking, preserving version-level permission metadata, and indexing. The question-answering path starts with the query and user permissions, retrieves available chunks, passes them to the model for structured response, and then verifies factual accuracy and citation. Missing evidence, selecting the wrong version, or generation distortion represent distinct issues.
Top of the diagram shows pre-processed and indexed data; below, the query triggers retrieval and response. The key point is to provide relevant evidence, not to send all data every time.
Original explanation emphasized the efficiency, cost control, and ease of updates: only transmit necessary content, update the index when data changes, and retraining is not always required. Customer service can look up password reset steps; sales can check the latest quantity discounts; compliance issues can locate relevant retention policy segments.
Translation note: RAG does not automatically guarantee faster, cheaper, more private, or correct responses. Retrieved fragments may still be sent to the model provider; permissions, logging, updates, and citations must be managed. RAG does not make the model 'learn' new facts; it instead provides evidence within the current request. End-to-end latency, quality, and cost comparisons are necessary.
Do not simply feed raw data into the model: design retrieval, sourcing, and validation workflows so that business data can be used as needed.
Extended Script Four: Fine-Tuning
If prompts and document retrieval still fail to meet the task, consider fine-tuning: starting from a pre-trained model, train it further with your own examples to modify specific behaviors, such as vocabulary, tone, formatting, or response patterns.
Legal teams may prefer document formatting aligned with internal standards; medical systems may require handling specific codes; software teams may want documents to follow internal style guidelines. These are custom objectives, and do not guarantee the model will behave like a domain expert after training.
Original explanation stated 'results exactly match expectations'; this should be understood as a target, not a guarantee. Fine-tuning may still hallucinate or fail, and is not a substitute for continuously updated fact databases.
It is better suited for scenarios with large volumes of structured, high-quality examples, where stable behavior or specific output formats are required. Fine-tuning typically increases technical, evaluation, and maintenance effort, so its use should first be justified as truly necessary.
Fine-tuning, prompting, and RAG can be combined: use examples to adjust behavior, use prompts to clarify the current task, and use retrieval to supply up-to-date evidence. These three approaches modify different aspects.
View textual explanation of the diagram
Prompts and examples organize the current task input; RAG supplements external evidence for this input, typically without altering model parameters; fine-tuning uses examples during training to adjust parameters, then uses the new version for inference. Gaps in facts, behavior, and formatting should be diagnosed separately.
Extended Script Five: Function Calling and Tool Usage
Function calls connect conversations with actual business capabilities. For example, when asked for revenue by product line this month, the model should not fabricate numbers, but instead query a report interface and respond based on the actual returned data.
Developers first define callable functions (such as checking the weather, retrieving customer details, or calculating postage) or querying sales by month and region. The model does not execute the code itself; instead, it generates a call request containing the function name and parameters, based on provided tool descriptions. The application checks and executes the request, then passes the result back, upon which the model organizes its response.
The original demo used a travel scenario to illustrate the intermediate process: a user says, 'I might visit Vancouver this week, what should I bring?' The system provides a date and time, along with a description of available weather functions. The model recognizes that weather is needed and proposes a request for Vancouver. The application retrieves the future weather data and returns it to the model, which then provides recommendations such as a coat, shoes, and an umbrella based on temperature and precipitation.
Note: In the original example, the function name was written as 'current weather,' but the returned data included a 24-hour forecast for the future. If a user asks about a week-long trip, the system should verify whether the returned time range covers the required period. The model's inferred location may also be incorrect; the application must validate the parameters and cannot treat inferred inputs as facts.
Tool calling is a multi-step process that may involve multiple model requests, so costs must also account for intermediate calls, context, and retries, not just the final answer length.
By connecting to internal databases, scheduling systems, analytics, or ERP systems, the system can become an entry point for business logic. It can also work alongside multi-step prompts and structured outputs, asking for missing conditions before execution.
View textual explanation of the diagram
The application is responsible for receiving model suggestions, checking user authorization, parameters, and business rules, then executing the tool. Requests that fail are stopped or clarified. Actual execution results must be returned and verified; write operations also require anti-repetition and recoverability design.
The model proposes a call; the application handles permissions, parameters, and actual execution, and finally checks the return status. Especially for operations involving modifications, payments, or message dispatch, boundaries must be commensurate with the potential consequences. Generating a 'completed' message is not evidence of successful execution.
Extended Script Six: Embeddings and Queryable Representations
If RAG is likened to a strategy for finding information, embeddings can be seen as a map that helps determine the direction of search. It represents content as vectors (sets of numbers) enabling semantic relationships to be computed and compared.
The original example used PDF and CSV files. In practice, content must first be extracted, segmented by task, then processed by an embedding model to generate vectors and written into appropriate indexes; not simply passed as binary files to a text interface.
When answering, the system searches for semantically relevant fragments within existing representations, without requiring exact word-by-word matches. For example, a query like 'find onboarding-related materials' can retrieve documents with different phrasings.
Embeddings can also be used for clustering, recommendations, approximate or duplicate content detection. The original explanation described it as a 'vector fingerprint,' a helpful metaphor for understanding; however, it is not a guarantee of uniqueness, irreversibility, or cryptographic verifiability.
It does not replace training or fine-tuning, but instead provides an alternative way to organize and retrieve information. When used, it is essential to ensure that queries and document representations are comparable, and that continuous handling of permissions, versions, deletion, and retrieval evaluation is maintained. Generating vectors is only one step in building a reliable search workflow; it does not mean the system can solve all queries.
Extended Script Seven: The Role of MCP in Connectivity
The original explanation introduced the Model Context Protocol (MCP), using the metaphor of 'glue' or 'envelope' to describe how tools, data, and prompts are organized and provided to AI applications. It also cited different roles such as sales, support, HR, or process analysis, emphasizing that context should be clear, reusable, and point to publicly available protocols.
Note: The original text described MCP as a unified prompt encapsulation that sends roles, rules, and memory to the model; this is not an accurate technical definition of a protocol. MCP more specifically defines how clients and servers exchange capabilities, enabling the host application to discover and use tools, resources, and prompts; it does not automatically create model memory, nor does it guarantee output safety or predictability.
View textual explanation of the diagram
The host is the AI application, responsible for managing how the model is used and for multiple clients. In the diagram, client A connects to the data service endpoint, and client B connects to the ticketing service endpoint; service endpoints can expose tools, resources, or prompts. A unified connection method does not imply automatic assurance of access scope, facts, or execution security.
The host management client is shown in the diagram, with each client connecting to the corresponding server. The server exposes limited capabilities, and the host remains responsible for deciding what to provide to the model and how to execute permissions and confirm boundaries.
Can be further explored in MCP official documentation for protocol and component details. It can work in conjunction with prompts, RAG, embeddings, and tool calls, but these concepts should not be conflated into a single thing.
Related Reading
When comparing existing services, refer to supply chain and selection criteria ; to understand how retrieval enters the response, refer to RAG and business knowledge .
Reference and Extended Reading
The following are editorial additions for queries and learning entry points, which you can refer to as needed.
- scikit-learn official user guide (English / technical documentation): query by task to explore classification, regression, clustering, anomaly detection, and model evaluation.
- Google: Define model objectives, outputs, and success metrics (Chinese): align expected business outcomes, model outputs, and evaluation criteria.
- Google: Overview of recommendation systems (Chinese): understand why recommendations are needed and how recommendation systems help users discover content.