示例工程教程人工智能【免费下载链接】AIMLInterviewsThis repo is meant to serve as a guide for Machine Learning/AI technical interviews.项目地址https://gitcode.com/gh_mirrors/ma/AIMLInterviews点击查看免费下载在 ML System Design 面试中预处理是Feature Engineering九步设计公式的第 5 步里最容易开场也最容易被轻视的一环它决定了原始数据能否被模型消费也直接决定生产环境的推理一致性问题。本篇基于 AIMLInterviews 仓库中 非结构化数据预处理笔记结合仓库内 特征工程详解、ML 系统设计主文档 以及图像/视频搜索实战案例系统讲解文本Normalization → Tokenization → Token to ids、图像Resize → Scale → Normalize与视频Decode → Sample → Resize → Normalize的完整预处理流水线并延伸到各类编码器TF-IDF、Word2Vec、BERT、ViT、ViViT的选型逻辑。读完本文你将能在一道图像搜索、视频搜索或多模态检索系统设计题中准确说出每一步预处理的作用、参数约定与常见坑点。一、预处理在 ML 系统设计中的位置在 AIMLInterviews 仓库的 九步 ML 系统设计公式模板 中第 5 步 Feature Engineering 明确把 Feature preprocessing 列为独立子项ML 系统设计主文档 进一步强调预处理主要面向非结构化数据文本Normalize - pre-tokenize - tokenizer model (ch/word/subword level) - post-process (add special tokens)图像Resize, normalize视频Decode frames - sample - resize - scale and normalize。这段描述与 mlsd-preprocessing.md 给出的两条主流水线完全一致说明预处理是贯穿各案例题图像搜索、多模态视频搜索、有害内容检测等的公共前置模块。面试中你不需要在第一轮就深入每个细节但必须能把整条流水线连贯讲出并解释每一步为什么。二、文本预处理从原始字符串到 token idmlsd-preprocessing.md 给出的文本预处理主干是Normalization - Tokenization [Pre-Tokenization - Tokenizer Model - Post-processing] - Token to ids (lookup table, hashing)特征工程详解 将其展开为normalization - tokenization - token to ids并给出三种 token 粒度。下面逐段展开。2.1 Normalization规范化规范化是把文本统一到可比较形式的第一步典型操作包括大小写折叠lowercasingUnicode 归一化如 NFC/NFD处理全角/半角、组合字符去除或替换标点、控制字符压缩空白对中文等语言可能涉及繁简转换、全半角统一。目的让同一语义的写法Hello 与 hello、 与 full在后续 token 化后落到同一个单元降低词表膨胀减少数据稀疏。面试中要提到规范化是语料与查询侧必须一致执行的步骤否则检索/分类系统会出现线上线下一不一致的漂移。2.2 Tokenization分词/Token 化mlsd-preprocessing.md 特意用方括号标出 Tokenization 的内部三段式这是 Hugging Face Tokenizers 风格的标准分解值得在面试中完整复述Pre-Tokenization预分词先用规则粗切如按空格、标点切出候选块确定哪些位置不能跨 token例如数字、URL、多词缩写。它是后面模型决定的切分单位的上界。Tokenizer Model分词模型对预分词结果做真正的切分决策粒度分为三类见下文。Post-processing后处理按模型约定添加特殊 token如[CLS]、[SEP]、s、/s、[PAD]、[UNK]并组装成模型要求的输入结构attention mask、token type ids 等。参考 mlsd-preprocessing.md 的注释add special tokens。三种 Token 粒度来自 mlsd-feature-eng.md粒度说明特点/适用Word tokenization以词为单位切分词表巨大、OOV未登录词问题严重语言无关性差黏着语、复合词爆炸Subword tokenization词与字符之间如 BPE、WordPiece、SentencePiece词表可控、能处理 OOV现代预训练模型默认选择Character tokenization以字符/字节为单位词表极小、序列变长、语义粒度粗多用于噪声大或形态丰富的场景面试加分点说明 subword 之所以成为主流是因为它在词表规模与语义完整性之间取了折中——高频词整词保留、低频词退化为子词片段天然解决 OOV 与罕见拼写问题。2.3 Token to IDs查表与哈希Token 序列最终要映射为整数 ID 才能喂给 embedding 层。mlsd-preprocessing.md 与 mlsd-feature-eng.md 都列出了两种方式Lookup table查表维护一份 vocab → id 的映射表token 化结果直接查表得到 id。可控、可解释但词表需要预先固定新 token 只能落到[UNK]。这是 BERT 等预训练模型的标准做法。Hashing哈希对 token 做哈希直接得到固定范围内的 id无需词表。省去 vocab 存储与更新但存在哈希冲突不同词可能映射到同一 id且不可逆、不可解释。常用于大规模稀疏特征或 streaming 场景。设计取舍一句话查表适合词表稳定、需要 embedding 语义的深度学习场景哈希适合特征海量、训练时间窗短、接受碰撞的快速原型或大规模 LR/GBDT 特征场景。三、文本编码器把 token 变成向量预处理之后模型需要的是向量。 mlsd-feature-eng.md 将文本编码器分为统计方法与ML 方法两大类这也是 ML 系统设计题中Text → Vector (Embeddings)的标准框架。3.1 统计方法BoWBag of Words把文档转成词频向量忽略词序与语法。实现简单但维数高、稀疏且丢失语义顺序。TF-IDF评估一个词相对文档集合的重要性是 TF 与 IDF 的乘积公式必须能默写TF(t, d) term_count / total_terms IDF(t) log(total_documents / document_frequency) TF-IDF(t, d) TF(t, d) × IDF(t)其中term_count是词 t 在文档 d 中出现次数total_terms是文档 d 的词总数total_documents是集合中文档总数document_frequency是包含词 t 的文档数。含义TF 衡量词在本文档中的频度IDF 衡量词在整个集合中的稀有度两者相乘同时压制停用词、突出区分性强的词。ML 系统设计面试里TF-IDF 经常作为检索系统的基线编码器与后续 embedding 方案做对比。3.2 ML 编码器Embedding (lookup) layer可训练层把词/id 映射为连续向量训练中学习语义表示是几乎所有 NN 模型的底座。Word2Vec基于浅层神经网络两种范式必须能对比CBOWContinuous Bag of Words给定上下文窗口内的词预测中心词取上下文词 embedding 的平均来生成目标词。计算高效适合小数据集。Skip-gram给定中心词预测上下文词擅长捕捉细粒度语义关系在大数据集上表现更好。两者都产出稠密连续向量适用于情感分析、语言建模、文本分类等下游任务。Transformer 类如 BERT考虑上下文同一词在不同语境中获得不同 embedding——这是与 Word2Vec 的静态向量最本质的区别。在 多模态视频搜索案例 中项目明确选择 BERT 作为文本编码器理由是文本 query 语义复杂、需要上下文建模。四、图像预处理Resize、Scale、Normalize、色彩空间mlsd-preprocessing.md 在图像一节只保留了标题说明该主题在仓库中被 特征工程详解 与各案例文档覆盖但图像预处理的完整内容分布在仓库多处合并来看标准流水线是Decode - Resize - Scale (0-1) - Normalize (mean 0, var 1) - 色彩模式统一 (RGB/CMYK)依据来自 图像搜索系统案例 第 5 步 Feature preprocessing 的原文Resize (e.g. 224x224), Scale (0-1), normalize (mean 0, var 1), color mode (RGB, CMYK)ML 系统设计主文档 简写为Resize, normalize。Decode解码图像文件JPEG/PNG为像素张量Resize统一到模型输入尺寸如 224×224、256×256保证 batch 内 shape 一致、可批处理注意长宽比与插值方式的选择Scale把像素值从 [0,255] 缩放到 [0,1]除以 255Normalize按通道减均值、除标准差使数据分布接近零均值单位方差帮助模型收敛对应标准mean 0, var 1色彩模式统一 RGB/CMYK 等通道布局避免通道错位。仓库 ML 编码练习题 给出了与图像归一化同构的向量化实现范式——按行做零均值单位方差标准化且用clamp_min(eps)防止除零import torch def normalize_rows(x: torch.Tensor, eps: float 1e-8) - torch.Tensor: if x.ndim ! 2: raise ValueError(fExpected a 2D tensor, received shape {tuple(x.shape)}) if not (x.is_floating_point() or x.is_complex()): raise TypeError(x must have a floating-point or complex dtype) mean x.mean(dim1, keepdimTrue) std x.std(dim1, keepdimTrue, unbiasedFalse).clamp_min(eps) return (x - mean) / std该文件还强调了一个面试必答点随机数据增强训练侧必须与确定性预处理验证/推理侧分离且预处理期望的数值范围、dtype、通道顺序必须与模型训练时一致见 pytorch-ml-coding.md 对 torchvision transforms 的问答。图像搜索案例中预测流水线的写法正是image - preprocess - embedding gen (ML model) - img embedding见 mlsd-image-search.md预处理是 embedding 生成服务的第一环。五、视频预处理Decode → Sample → Resize → Scale/Normalizemlsd-preprocessing.md 给出的视频流水线是Decode frames - sample frames - Resize - Scale, normalizemlsd-feature-eng.md 在Frame-level一节补充了最后一个环节color correction多模态视频搜索案例 也原样复用了这条链。逐步解释Decode frames视频是压缩容器如 H.264先解码为帧序列Sample frames在时间轴上采样帧。常见策略有均匀抽样、随机抽样、关键帧采样、滑动窗口片段抽样。采样密度直接决定计算量与时间信息覆盖是成本 vs 时序理解的核心权衡点Resize统一每帧空间尺寸满足模型输入Scale, normalize同图像把像素缩放到 [0,1] 并按通道标准化Color correction来自 mlsd-feature-eng.md修正帧间色彩不一致光照变化、相机差异避免时间维度上的像素分布漂移干扰模型。5.1 视频编码器Video-level vs Frame-level视频预处理产出的帧集合之后如何变成 embeddingmlsd-feature-eng.md 给出了两条路线这也是视频搜索/推荐系统设计题中的高频对比方案处理方式成本时序理解代表模型Video-level视频级将整个视频作为输入生成 embedding使用 3D 卷积或 Transformer更贵训练、推理速度与算力强直接建模时间维度ViViTVideo Vision TransformerFrame-level帧级从采样帧分别得到帧 embedding再聚合更便宜弱依赖聚合策略ViTVision Transformermlsd-feature-eng.md 对ViT的补充说明很有用ViT 把图像切分为不重叠的 patch通过自注意力机制分析图像内容它与最初为序列数据设计的原始 Transformer 不同——后者依赖一维位置编码。面试中可由此引出patch embedding 位置编码 Transformer encoder这一标准结构以及帧级方案为何能成为性价比默认选项多模态视频搜索案例 即采用该思路并配合 ANN 检索。六、在实战案例中串起来检索系统如何消费预处理结果预处理不是孤立的仓库中的案例文档展示了它如何进入端到端流水线图像搜索mlsd-image-search.mdembedding 生成服务 image - preprocess - embedding gen - img embedding随后用近似最近邻ANN如 Faiss检索相似图。预处理质量直接决定 embedding 空间的稳定性。多模态视频搜索mlsd-mm-video-search.md文本侧走normalization - tokenization - token to ids后接 BERT 编码视频侧走帧解码流水线后接 ViT/ViViT 编码两侧 embedding 用对比学习训练检索用 ANN最终融合文本检索如 Elasticsearch 倒排索引与向量检索结果做重排。这两个案例共同印证了 mlsd-preprocessing.md 里两条流水线的通用性任何涉及非结构化输入的生产级 ML 系统都必须先定义一套确定性的预处理契约。七、面试速记清单与常见追问把本主题压缩成可在面试中 30 秒讲完的框架文本Normalization → TokenizationPre-tokenize → Tokenizer modelword/subword/char → Post-processspecial tokens→ Token to ids查表/哈希。图像Decode → Resize如 224×224→ Scale0-1→ Normalizemean 0, var 1→ 色彩模式统一RGB/CMYK。视频Decode frames → Sample frames → Resize → Scale, normalize color correction。编码器统计基线BoW / TF-IDF能默写 TF、IDF、TF-IDF 公式→ 静态向量Word2Vec 的 CBOW / Skip-gram 差异→ 上下文向量BERT视频侧对比 Video-levelViViT与 Frame-levelViT的成本/时序理解权衡。高频追问均可在仓库中找到依据为什么 tokenization 要分三段——pre-tokenize 确定候选边界tokenizer model 做切分post-process 补 special tokensmlsd-preprocessing.md。CBOW 和 Skip-gram 怎么选——小数据集选 CBOW高效大数据集、要细粒度语义选 Skip-grammlsd-feature-eng.md。归一化要注意什么——均值/方差需在训练集上统计且切分后再做防数据泄漏推理侧与训练侧必须完全一致ml-system-design.md 中 Data leakage 部分数值范围、dtype、通道顺序要对齐pytorch-ml-coding.md。视频为什么先采样——控制计算量帧级方案即采样 帧级编码 聚合是训练/推理成本与时间理解之间的权衡mlsd-feature-eng.md、mlsd-mm-video-search.md。参考文档索引本文主体笔记src/MLSD/mlsd-preprocessing.md文本/视频预处理与编码器展开src/MLSD/mlsd-feature-eng.mdML 系统设计框架与 Step 5 定位src/MLSD/ml-system-design.md模板图像预处理实战参数src/MLSD/mlsd-image-search.md多模态视频搜索中的预处理应用src/MLSD/mlsd-mm-video-search.md归一化的向量化实现与面试问答src/MLC/pytorch-ml-coding.md赞分享示例工程教程人工智能【免费下载链接】AIMLInterviewsThis repo is meant to serve as a guide for Machine Learning/AI technical interviews.项目地址https://gitcode.com/gh_mirrors/ma/AIMLInterviews点击查看免费下载相关推荐多模态视频搜索系统设计AIMLInterviews 面试指南中的文本查询视频检索全流程拆解多模态视频搜索系统设计AIMLInterviews 面试指南中的文本查询视频检索全流程拆解 本文是 AIMLInterviews 仓库 ML 系统设计 htt示例工程教程人工智能AIMLInterviews MLSD 实战文本、图像与视频预处理管线全解析AIMLInterviews MLSD 实战文本、图像与视频预处理管线全解析 导读 本文以 cn/src/MLSD/mlsd preprocessing.md示例工程教程人工智能G-Helper完整指南华硕笔记本的轻量替代10分钟配好性能调校G Helper完整指南华硕笔记本的轻量替代10分钟配好性能调校 华硕笔记本原装控制软件有多拖累你常驻内存几百MB、更新弹窗没完没了、常用功能埋在三层菜单示例工程教程人工智能上一篇MauiReactor源码解析深入理解MVU框架的实现原理下一篇IINA弹幕插件让你的macOS播放器拥有全平台弹幕支持创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AIMLInterviews 指南：ML 系统设计中的非结构化数据预处理——文本、图像、视频全流程拆解
示例工程教程人工智能【免费下载链接】AIMLInterviewsThis repo is meant to serve as a guide for Machine Learning/AI technical interviews.项目地址https://gitcode.com/gh_mirrors/ma/AIMLInterviews点击查看免费下载在 ML System Design 面试中预处理是Feature Engineering九步设计公式的第 5 步里最容易开场也最容易被轻视的一环它决定了原始数据能否被模型消费也直接决定生产环境的推理一致性问题。本篇基于 AIMLInterviews 仓库中 非结构化数据预处理笔记结合仓库内 特征工程详解、ML 系统设计主文档 以及图像/视频搜索实战案例系统讲解文本Normalization → Tokenization → Token to ids、图像Resize → Scale → Normalize与视频Decode → Sample → Resize → Normalize的完整预处理流水线并延伸到各类编码器TF-IDF、Word2Vec、BERT、ViT、ViViT的选型逻辑。读完本文你将能在一道图像搜索、视频搜索或多模态检索系统设计题中准确说出每一步预处理的作用、参数约定与常见坑点。一、预处理在 ML 系统设计中的位置在 AIMLInterviews 仓库的 九步 ML 系统设计公式模板 中第 5 步 Feature Engineering 明确把 Feature preprocessing 列为独立子项ML 系统设计主文档 进一步强调预处理主要面向非结构化数据文本Normalize - pre-tokenize - tokenizer model (ch/word/subword level) - post-process (add special tokens)图像Resize, normalize视频Decode frames - sample - resize - scale and normalize。这段描述与 mlsd-preprocessing.md 给出的两条主流水线完全一致说明预处理是贯穿各案例题图像搜索、多模态视频搜索、有害内容检测等的公共前置模块。面试中你不需要在第一轮就深入每个细节但必须能把整条流水线连贯讲出并解释每一步为什么。二、文本预处理从原始字符串到 token idmlsd-preprocessing.md 给出的文本预处理主干是Normalization - Tokenization [Pre-Tokenization - Tokenizer Model - Post-processing] - Token to ids (lookup table, hashing)特征工程详解 将其展开为normalization - tokenization - token to ids并给出三种 token 粒度。下面逐段展开。2.1 Normalization规范化规范化是把文本统一到可比较形式的第一步典型操作包括大小写折叠lowercasingUnicode 归一化如 NFC/NFD处理全角/半角、组合字符去除或替换标点、控制字符压缩空白对中文等语言可能涉及繁简转换、全半角统一。目的让同一语义的写法Hello 与 hello、 与 full在后续 token 化后落到同一个单元降低词表膨胀减少数据稀疏。面试中要提到规范化是语料与查询侧必须一致执行的步骤否则检索/分类系统会出现线上线下一不一致的漂移。2.2 Tokenization分词/Token 化mlsd-preprocessing.md 特意用方括号标出 Tokenization 的内部三段式这是 Hugging Face Tokenizers 风格的标准分解值得在面试中完整复述Pre-Tokenization预分词先用规则粗切如按空格、标点切出候选块确定哪些位置不能跨 token例如数字、URL、多词缩写。它是后面模型决定的切分单位的上界。Tokenizer Model分词模型对预分词结果做真正的切分决策粒度分为三类见下文。Post-processing后处理按模型约定添加特殊 token如[CLS]、[SEP]、s、/s、[PAD]、[UNK]并组装成模型要求的输入结构attention mask、token type ids 等。参考 mlsd-preprocessing.md 的注释add special tokens。三种 Token 粒度来自 mlsd-feature-eng.md粒度说明特点/适用Word tokenization以词为单位切分词表巨大、OOV未登录词问题严重语言无关性差黏着语、复合词爆炸Subword tokenization词与字符之间如 BPE、WordPiece、SentencePiece词表可控、能处理 OOV现代预训练模型默认选择Character tokenization以字符/字节为单位词表极小、序列变长、语义粒度粗多用于噪声大或形态丰富的场景面试加分点说明 subword 之所以成为主流是因为它在词表规模与语义完整性之间取了折中——高频词整词保留、低频词退化为子词片段天然解决 OOV 与罕见拼写问题。2.3 Token to IDs查表与哈希Token 序列最终要映射为整数 ID 才能喂给 embedding 层。mlsd-preprocessing.md 与 mlsd-feature-eng.md 都列出了两种方式Lookup table查表维护一份 vocab → id 的映射表token 化结果直接查表得到 id。可控、可解释但词表需要预先固定新 token 只能落到[UNK]。这是 BERT 等预训练模型的标准做法。Hashing哈希对 token 做哈希直接得到固定范围内的 id无需词表。省去 vocab 存储与更新但存在哈希冲突不同词可能映射到同一 id且不可逆、不可解释。常用于大规模稀疏特征或 streaming 场景。设计取舍一句话查表适合词表稳定、需要 embedding 语义的深度学习场景哈希适合特征海量、训练时间窗短、接受碰撞的快速原型或大规模 LR/GBDT 特征场景。三、文本编码器把 token 变成向量预处理之后模型需要的是向量。 mlsd-feature-eng.md 将文本编码器分为统计方法与ML 方法两大类这也是 ML 系统设计题中Text → Vector (Embeddings)的标准框架。3.1 统计方法BoWBag of Words把文档转成词频向量忽略词序与语法。实现简单但维数高、稀疏且丢失语义顺序。TF-IDF评估一个词相对文档集合的重要性是 TF 与 IDF 的乘积公式必须能默写TF(t, d) term_count / total_terms IDF(t) log(total_documents / document_frequency) TF-IDF(t, d) TF(t, d) × IDF(t)其中term_count是词 t 在文档 d 中出现次数total_terms是文档 d 的词总数total_documents是集合中文档总数document_frequency是包含词 t 的文档数。含义TF 衡量词在本文档中的频度IDF 衡量词在整个集合中的稀有度两者相乘同时压制停用词、突出区分性强的词。ML 系统设计面试里TF-IDF 经常作为检索系统的基线编码器与后续 embedding 方案做对比。3.2 ML 编码器Embedding (lookup) layer可训练层把词/id 映射为连续向量训练中学习语义表示是几乎所有 NN 模型的底座。Word2Vec基于浅层神经网络两种范式必须能对比CBOWContinuous Bag of Words给定上下文窗口内的词预测中心词取上下文词 embedding 的平均来生成目标词。计算高效适合小数据集。Skip-gram给定中心词预测上下文词擅长捕捉细粒度语义关系在大数据集上表现更好。两者都产出稠密连续向量适用于情感分析、语言建模、文本分类等下游任务。Transformer 类如 BERT考虑上下文同一词在不同语境中获得不同 embedding——这是与 Word2Vec 的静态向量最本质的区别。在 多模态视频搜索案例 中项目明确选择 BERT 作为文本编码器理由是文本 query 语义复杂、需要上下文建模。四、图像预处理Resize、Scale、Normalize、色彩空间mlsd-preprocessing.md 在图像一节只保留了标题说明该主题在仓库中被 特征工程详解 与各案例文档覆盖但图像预处理的完整内容分布在仓库多处合并来看标准流水线是Decode - Resize - Scale (0-1) - Normalize (mean 0, var 1) - 色彩模式统一 (RGB/CMYK)依据来自 图像搜索系统案例 第 5 步 Feature preprocessing 的原文Resize (e.g. 224x224), Scale (0-1), normalize (mean 0, var 1), color mode (RGB, CMYK)ML 系统设计主文档 简写为Resize, normalize。Decode解码图像文件JPEG/PNG为像素张量Resize统一到模型输入尺寸如 224×224、256×256保证 batch 内 shape 一致、可批处理注意长宽比与插值方式的选择Scale把像素值从 [0,255] 缩放到 [0,1]除以 255Normalize按通道减均值、除标准差使数据分布接近零均值单位方差帮助模型收敛对应标准mean 0, var 1色彩模式统一 RGB/CMYK 等通道布局避免通道错位。仓库 ML 编码练习题 给出了与图像归一化同构的向量化实现范式——按行做零均值单位方差标准化且用clamp_min(eps)防止除零import torch def normalize_rows(x: torch.Tensor, eps: float 1e-8) - torch.Tensor: if x.ndim ! 2: raise ValueError(fExpected a 2D tensor, received shape {tuple(x.shape)}) if not (x.is_floating_point() or x.is_complex()): raise TypeError(x must have a floating-point or complex dtype) mean x.mean(dim1, keepdimTrue) std x.std(dim1, keepdimTrue, unbiasedFalse).clamp_min(eps) return (x - mean) / std该文件还强调了一个面试必答点随机数据增强训练侧必须与确定性预处理验证/推理侧分离且预处理期望的数值范围、dtype、通道顺序必须与模型训练时一致见 pytorch-ml-coding.md 对 torchvision transforms 的问答。图像搜索案例中预测流水线的写法正是image - preprocess - embedding gen (ML model) - img embedding见 mlsd-image-search.md预处理是 embedding 生成服务的第一环。五、视频预处理Decode → Sample → Resize → Scale/Normalizemlsd-preprocessing.md 给出的视频流水线是Decode frames - sample frames - Resize - Scale, normalizemlsd-feature-eng.md 在Frame-level一节补充了最后一个环节color correction多模态视频搜索案例 也原样复用了这条链。逐步解释Decode frames视频是压缩容器如 H.264先解码为帧序列Sample frames在时间轴上采样帧。常见策略有均匀抽样、随机抽样、关键帧采样、滑动窗口片段抽样。采样密度直接决定计算量与时间信息覆盖是成本 vs 时序理解的核心权衡点Resize统一每帧空间尺寸满足模型输入Scale, normalize同图像把像素缩放到 [0,1] 并按通道标准化Color correction来自 mlsd-feature-eng.md修正帧间色彩不一致光照变化、相机差异避免时间维度上的像素分布漂移干扰模型。5.1 视频编码器Video-level vs Frame-level视频预处理产出的帧集合之后如何变成 embeddingmlsd-feature-eng.md 给出了两条路线这也是视频搜索/推荐系统设计题中的高频对比方案处理方式成本时序理解代表模型Video-level视频级将整个视频作为输入生成 embedding使用 3D 卷积或 Transformer更贵训练、推理速度与算力强直接建模时间维度ViViTVideo Vision TransformerFrame-level帧级从采样帧分别得到帧 embedding再聚合更便宜弱依赖聚合策略ViTVision Transformermlsd-feature-eng.md 对ViT的补充说明很有用ViT 把图像切分为不重叠的 patch通过自注意力机制分析图像内容它与最初为序列数据设计的原始 Transformer 不同——后者依赖一维位置编码。面试中可由此引出patch embedding 位置编码 Transformer encoder这一标准结构以及帧级方案为何能成为性价比默认选项多模态视频搜索案例 即采用该思路并配合 ANN 检索。六、在实战案例中串起来检索系统如何消费预处理结果预处理不是孤立的仓库中的案例文档展示了它如何进入端到端流水线图像搜索mlsd-image-search.mdembedding 生成服务 image - preprocess - embedding gen - img embedding随后用近似最近邻ANN如 Faiss检索相似图。预处理质量直接决定 embedding 空间的稳定性。多模态视频搜索mlsd-mm-video-search.md文本侧走normalization - tokenization - token to ids后接 BERT 编码视频侧走帧解码流水线后接 ViT/ViViT 编码两侧 embedding 用对比学习训练检索用 ANN最终融合文本检索如 Elasticsearch 倒排索引与向量检索结果做重排。这两个案例共同印证了 mlsd-preprocessing.md 里两条流水线的通用性任何涉及非结构化输入的生产级 ML 系统都必须先定义一套确定性的预处理契约。七、面试速记清单与常见追问把本主题压缩成可在面试中 30 秒讲完的框架文本Normalization → TokenizationPre-tokenize → Tokenizer modelword/subword/char → Post-processspecial tokens→ Token to ids查表/哈希。图像Decode → Resize如 224×224→ Scale0-1→ Normalizemean 0, var 1→ 色彩模式统一RGB/CMYK。视频Decode frames → Sample frames → Resize → Scale, normalize color correction。编码器统计基线BoW / TF-IDF能默写 TF、IDF、TF-IDF 公式→ 静态向量Word2Vec 的 CBOW / Skip-gram 差异→ 上下文向量BERT视频侧对比 Video-levelViViT与 Frame-levelViT的成本/时序理解权衡。高频追问均可在仓库中找到依据为什么 tokenization 要分三段——pre-tokenize 确定候选边界tokenizer model 做切分post-process 补 special tokensmlsd-preprocessing.md。CBOW 和 Skip-gram 怎么选——小数据集选 CBOW高效大数据集、要细粒度语义选 Skip-grammlsd-feature-eng.md。归一化要注意什么——均值/方差需在训练集上统计且切分后再做防数据泄漏推理侧与训练侧必须完全一致ml-system-design.md 中 Data leakage 部分数值范围、dtype、通道顺序要对齐pytorch-ml-coding.md。视频为什么先采样——控制计算量帧级方案即采样 帧级编码 聚合是训练/推理成本与时间理解之间的权衡mlsd-feature-eng.md、mlsd-mm-video-search.md。参考文档索引本文主体笔记src/MLSD/mlsd-preprocessing.md文本/视频预处理与编码器展开src/MLSD/mlsd-feature-eng.mdML 系统设计框架与 Step 5 定位src/MLSD/ml-system-design.md模板图像预处理实战参数src/MLSD/mlsd-image-search.md多模态视频搜索中的预处理应用src/MLSD/mlsd-mm-video-search.md归一化的向量化实现与面试问答src/MLC/pytorch-ml-coding.md赞分享示例工程教程人工智能【免费下载链接】AIMLInterviewsThis repo is meant to serve as a guide for Machine Learning/AI technical interviews.项目地址https://gitcode.com/gh_mirrors/ma/AIMLInterviews点击查看免费下载相关推荐多模态视频搜索系统设计AIMLInterviews 面试指南中的文本查询视频检索全流程拆解多模态视频搜索系统设计AIMLInterviews 面试指南中的文本查询视频检索全流程拆解 本文是 AIMLInterviews 仓库 ML 系统设计 htt示例工程教程人工智能AIMLInterviews MLSD 实战文本、图像与视频预处理管线全解析AIMLInterviews MLSD 实战文本、图像与视频预处理管线全解析 导读 本文以 cn/src/MLSD/mlsd preprocessing.md示例工程教程人工智能G-Helper完整指南华硕笔记本的轻量替代10分钟配好性能调校G Helper完整指南华硕笔记本的轻量替代10分钟配好性能调校 华硕笔记本原装控制软件有多拖累你常驻内存几百MB、更新弹窗没完没了、常用功能埋在三层菜单示例工程教程人工智能上一篇MauiReactor源码解析深入理解MVU框架的实现原理下一篇IINA弹幕插件让你的macOS播放器拥有全平台弹幕支持创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考