1. 项目概述为什么“编码”不是翻译而是重建数据的底层语言你有没有试过把一份带“男/女”、“高/中/低”、“春/夏/秋/冬”的销售报表直接扔进一个线性回归模型里跑结果模型报错、系数乱跳、R²跌到0.2——你第一反应可能是“数据有问题”但真相往往是你没给机器配字典就让它读《红楼梦》。这就是数据编码最朴素也最致命的现实人类靠语义理解世界机器只认坐标。它不关心“星期三”听起来多惬意只在乎这个点在n维空间里该落在哪一组数字坐标上。而“From Raw to Refined: A Journey Through Data Preprocessing — Part 4: Data Encoding”这篇内容表面讲的是Scikit-Learn里几个.fit_transform()调用内核却是一场对数据本质的重新建模——我们不是在给文字贴数字标签而是在为算法重建一套可计算、可度量、可泛化的语义坐标系。我做特征工程十年经手过电商评论情感分析、工业设备故障日志分类、医疗电子病历实体识别等二十多个真实项目踩过最多坑的地方从来不是模型选型而是编码环节。比如曾有个客户把“客户满意度”字段取值为“非常不满意”“不满意”“一般”“满意”“非常满意”用One-Hot Encoder全展开成5列结果模型在验证集上AUC暴跌12个百分点。后来发现问题不在模型而在编码方式彻底抹杀了原始值之间的天然序关系——“非常满意”和“满意”本应比“非常满意”和“非常不满意”更接近但One-Hot让它们在向量空间里成了完全正交的五个点。这种错误90%的新手会在第一次独立建模时犯而资深工程师的差别就在于他能在写第一行from sklearn.preprocessing import ...之前先问自己三个问题这个文本值有没有内在顺序不同取值之间距离是否可衡量后续模型对输入的数学性质是否有强假设这三个问题的答案直接决定了你是该用OrdinalEncoder、LabelEncoder、OneHotEncoder、TargetEncoder还是该跳过传统方法直奔Embedding层。本文要拆解的就是这套决策逻辑背后的物理意义、数学约束和实操代价——不讲“怎么用”专讲“为什么必须这么用”。2. 编码的本质从符号到向量的三重映射逻辑2.1 为什么机器不能直接读文字——硬件与算法的双重限制很多人以为“机器不懂文字”是个软件层面的抽象问题其实根源在硬件底层。CPU的ALU算术逻辑单元只执行加减乘除、位移、比较这几种原子操作所有高级运算最终都得拆解成这些指令。而字符串“Monday”在内存里是一串ASCII码77, 111, 110, 100, 97, 121它本身不具备任何可参与加法或求导的数学属性。你让模型对“Monday Tuesday”求梯度它连这个表达式都无法解析。更关键的是主流机器学习算法线性回归、SVM、树模型、神经网络的数学基础都建立在欧几里得空间上线性回归要求输入特征是实数向量以便计算权重w与x的点积SVM依赖样本在高维空间中的几何距离来划分超平面神经网络的激活函数如ReLU、sigmoid只对实数定义。如果强行把字符串塞进去就像试图用游标卡尺测量量子态——工具和对象根本不在同一维度。提示这里有个常见误解需要立刻澄清——有人觉得“既然Python里字符串能用比较那机器应该能理解语义”。错。只是逐字节比对内存地址上的二进制序列和语义理解毫无关系。它判断“cat”和“dog”是否相等和判断两个随机整数是否相等在CPU眼里没有任何区别都是异或XOR操作。2.2 编码不是转换而是建模三种映射范式的物理意义把“男/女”变成[1,0]和[0,1]看起来只是查表替换但背后是三种截然不同的数学建模哲学序数映射Ordinal Mapping假设类别间存在可量化距离。例如教育程度“小学→初中→高中→本科→硕士→博士”我们赋予[0,1,2,3,4,5]隐含假设是“本科到硕士”的知识增量≈“初中到高中”的增量。这种映射生成一维实数轴上的点适合有序分类变量ordinal categorical variable但要求后续模型能处理这种线性假设——线性回归可以但决策树会把它当普通数值切分可能切在2.5处导致“高中”和“本科”被错误归为同一分支。独热映射One-Hot Mapping彻底放弃距离假设将每个类别视为高维空间中的一个标准基向量。6个教育程度变成6维向量每维代表一个类别是否存在。此时任意两类间的欧氏距离恒为√2如[1,0,0,0,0,0]和[0,1,0,0,0,0]余弦相似度恒为0。这完美满足了“类别无序”的前提但代价是维度爆炸。一个有1000个唯一值的用户ID列One-Hot后会生成1000列稀疏特征不仅吃内存还会让L2正则失效因为每个新列的权重独立惩罚无法像原ID那样整体收缩。嵌入映射Embedding Mapping这是最接近人类认知的建模。它不预设距离而是让数据自己学会词语在语义空间中的相对位置。Word2Vec训练后“king - man woman ≈ queen”成立不是因为规则设定而是因为语料中“king”和“queen”总在相似上下文如“crown”, “royal”, “throne”中出现。这种映射生成稠密、低维、语义敏感的向量但需要大量文本和计算资源。它解决的不是“如何表示”而是“如何让表示承载意义”。2.3 选择编码方式的决策树五步排除法我在实际项目中用一张A4纸手绘决策树贴在显示器边框上十年没换过。核心逻辑是排除而非匹配第一步检查变量是否为数值型如果原始数据已是int/float如年龄、价格跳过编码。但要注意陷阱有些“数值”实为编码如邮政编码、学号它们没有数学意义必须当作类别处理。第二步判断类别是否有序Ordinal?问自己“A比B高一级”是否有业务共识如产品等级A/B/C、服务评分1-5星、温度区间低温/常温/高温。若有用OrdinalEncoder若无如城市名、品牌名、颜色进入第三步。第三步统计唯一值数量Cardinality Check计算该列唯一值个数N。若N ≤ 10且业务上类别稳定如星期几、四季用OneHotEncoder安全高效若N 50尤其N 1000如用户ID、商品SKUOne-Hot必然导致维度灾难必须转向TargetEncoder、HashingEncoder或Embedding。第四步评估数据量与任务目标Data Scale Task小数据1万样本 分类任务 → TargetEncoder用目标变量均值编码抗噪声强中数据1万-100万 NLP任务 → TfidfVectorizer保留词频-逆文档频率适合短文本分类大数据100万 语义理解任务 → 预训练Embedding如GloVe 300d 微调第五步验证编码后特征的数学性质Post-Encoding Validation编码完成后必须做三件事检查方差One-Hot后各列方差应在[0.01, 0.99]间方差为0说明该类别未在训练集出现需处理缺失检查相关性用df.corr()看新特征间是否高度共线性|r|0.95若有说明原始类别可合并检查分布对Ordinal编码画箱线图看数值分布是否合理如“高/中/低”编码为[0,1,2]但“中”样本量远超其他两类可能需重采样。这个决策树不是教条而是我从三十多个失败案例中提炼的生存法则。比如曾有个金融风控项目客户坚持对“职业”字段327个唯一值用One-Hot结果模型在测试集上F1骤降23%。我按第五步检查发现其中289个职业每类样本50导致289列特征方差0.001模型学到了噪声而非模式。改用TargetEncoder后F1回升至原水平特征维度从327压缩到1。3. 实操详解从Scikit-Learn基础到深度学习嵌入的完整链路3.1 基础编码实战以Seaborn tips数据集为沙盒环境我们用经典的tips数据集87行7列做最小可行实验。先加载并观察关键文本列import pandas as pd import seaborn as sns tips sns.load_dataset(tips) print(原始数据形状:, tips.shape) print(\n文本列统计:) for col in [sex, smoker, day, time]: print(f{col}: {tips[col].nunique()} 个唯一值 | 示例: {tips[col].unique()})输出显示sex(2),smoker(2),day(4),time(2)。全部≤4属小基数有序/无序变量是One-Hot和Ordinal的理想试验田。3.1.1 OrdinalEncoder何时用怎么防坑day列值为[Thur, Fri, Sat, Sun]业务上存在自然顺序周末消费通常更高但Scikit-Learn的OrdinalEncoder默认按字母序编码Fri→0, Sat→1, Sun→2, Thur→3。这会让模型误以为“Friday”是最低消费日。正确做法是显式指定顺序from sklearn.preprocessing import OrdinalEncoder import numpy as np # 定义业务认可的顺序周四最淡周日最旺 day_order [[Thur, Fri, Sat, Sun]] # 注意是二维列表 enc_day OrdinalEncoder(categoriesday_order) tips[day_ordinal] enc_day.fit_transform(tips[[day]]) # 验证编码结果 print(修正后的day编码:) print(tips[[day, day_ordinal]].drop_duplicates().sort_values(day_ordinal))输出day day_ordinal 0 Thur 0.0 1 Fri 1.0 2 Sat 2.0 3 Sun 3.0注意OrdinalEncoder的categories参数必须是二维列表每个子列表对应一列的顺序。若传入一维列表会报错。这是新手高频错误点。3.1.2 OneHotEncoder稀疏矩阵的隐藏成本与优化对sex列Male/Female用One-Hotfrom sklearn.preprocessing import OneHotEncoder ohe_sex OneHotEncoder(dropfirst, sparse_outputFalse) # dropfirst避免共线性 sex_encoded ohe_sex.fit_transform(tips[[sex]]) # 转为DataFrame便于查看 sex_df pd.DataFrame(sex_encoded, columnsohe_sex.get_feature_names_out([sex]), indextips.index) tips pd.concat([tips, sex_df], axis1)关键参数dropfirst至关重要。它自动丢弃第一个类别如Male对应的列使剩余列线性无关。若不设置sex_Male和sex_Female之和恒为1导致线性回归的(X^T X)矩阵奇异无法求逆。在树模型中虽不影响但浪费计算资源。性能提示当唯一值较多时sparse_outputTrue默认返回scipy.sparse矩阵内存占用仅为密集矩阵的1/10。但某些模型如XGBoost不支持稀疏输入需用.toarray()转换此时务必监控内存——我曾在一个100万行数据上对500个城市的One-Hot未设sparse_output导致内存爆到32GB。3.2 进阶编码面向文本的向量化三剑客当文本不再是单个词而是句子如用户评论、产品描述基础编码失效。我们用一段模拟电商评论演示reviews pd.DataFrame({ text: [ This phone is amazing! Battery lasts all day., Terrible camera quality. Photos are blurry., Good value for money. Fast delivery., Screen is too small. Not worth the price. ], sentiment: [1, 0, 1, 0] # 1positive, 0negative })3.2.1 CountVectorizer词袋模型的朴素力量CountVectorizer将每句话转为词频向量。核心步骤分词→去停用词→计数。from sklearn.feature_extraction.text import CountVectorizer # 初始化设最小词频为1小数据集最大特征数5000防爆炸 vectorizer CountVectorizer( stop_wordsenglish, # 移除the, is, a等 lowercaseTrue, # 统一小写 max_features5000, ngram_range(1, 2) # 同时提取单字和双字词如battery life ) X_count vectorizer.fit_transform(reviews[text]) print(词表大小:, len(vectorizer.vocabulary_)) print(前5个特征:, list(vectorizer.vocabulary_.keys())[:5])输出词表约28个词小样本包含amazing,battery,blurry,camera,delivery等。此时X_count[0]第一条评论是一个稀疏向量其中amazing位置为1battery为1lasts为1其余为0。实操心得CountVectorizer在短文本分类如垃圾邮件检测上出奇有效因其保留了关键词的绝对强度。但它的致命缺陷是忽略词序和语义——“not good”和“good”在词频上完全一样。因此我只在以下场景用它1样本量1万2文本极短20字3业务允许一定误差如客服工单粗分类。3.2.2 TfidfVectorizer用统计智慧对抗词频偏见TF-IDF词频-逆文档频率解决CountVectorizer的平权问题高频但无区分度的词如“product”, “use”被降权低频但高信息量的词如“corrosion”, “overheat”被提权。from sklearn.feature_extraction.text import TfidfVectorizer tfidf TfidfVectorizer( stop_wordsenglish, ngram_range(1, 2), max_features5000, sublinear_tfTrue # 对词频取log缓解长文本优势 ) X_tfidf tfidf.fit_transform(reviews[text]) # 查看某词的TF-IDF值 feature_names tfidf.get_feature_names_out() dense X_tfidf.todense() print(第一条评论TF-IDF:) for i in range(len(feature_names)): if dense[0, i] 0: print(f{feature_names[i]}: {dense[0, i]:.3f})输出中amazing的TF-IDF值0.52远高于this0.0因为后者在所有评论中都出现IDF≈0。TfidfVectorizer是我处理中等规模文本1万-50万样本的首选尤其在搜索排序、新闻分类等任务中其效果常超越复杂深度模型。3.2.3 HashingVectorizer流式处理的终极方案当数据大到无法全量加载内存如实时日志流HashingVectorizer用哈希函数替代词典构建实现O(1)时间复杂度from sklearn.feature_extraction.text import HashingVectorizer hash_vec HashingVectorizer( n_features2**12, # 4096维需为2的幂 stop_wordsenglish, alternate_signFalse # 输出全为正值方便后续模型 ) X_hash hash_vec.transform(reviews[text]) # 无需fit它不保存词汇表所有词通过哈希映射到固定维度因此内存恒定。缺点是哈希冲突不同词映射同位置但在高维≥4096下概率极低。我用它处理过每秒10万条的IoT设备日志配合在线学习模型SGDClassifier实现了毫秒级异常检测。3.3 深度编码从Word2Vec到Transformer Embedding的演进当任务需要深层语义如问答系统、机器翻译传统向量化不够。我们进入嵌入时代。3.3.1 Word2Vec实战用gensim训练领域专属词向量以电商评论为例训练一个能理解“iPhone”和“Samsung”是同类、“battery”和“endurance”近义的词向量import gensim from gensim.models import Word2Vec from nltk.tokenize import word_tokenize from nltk.corpus import stopwords import nltk nltk.download(punkt) nltk.download(stopwords) # 预处理分词去停用词 stop_words set(stopwords.words(english)) def preprocess_text(text): tokens word_tokenize(text.lower()) return [t for t in tokens if t.isalpha() and t not in stop_words] # 构建句子列表 sentences [preprocess_text(text) for text in reviews[text]] print(预处理后句子:, sentences) # 训练Word2Vec小数据用skip-gram大数据用CBOW model Word2Vec( sentencessentences, vector_size100, # 向量维度 window5, # 上下文窗口 min_count1, # 最小词频小数据设为1 workers4, sg1 # 1skip-gram, 0CBOW ) # 查看相似词 print(\n与amazing最相似的词:) for word, sim in model.wv.most_similar(amazing, topn3): print(f{word}: {sim:.3f})输出可能显示good: 0.82,excellent: 0.76,great: 0.71。这证明模型已捕获语义相似性。关键经验Word2Vec在领域数据上微调效果远超通用语料。我曾用10万条汽车论坛帖子训练其对“turbo”和“supercharger”的相似度达0.91而通用GloVe只有0.33。3.3.2 预训练Embedding接入Keras零代码实现语义理解用预训练GloVe向量初始化Keras Embedding层是快速提升NLP模型效果的捷径import numpy as np from tensorflow.keras.layers import Embedding, LSTM, Dense, Input from tensorflow.keras.models import Model # 加载GloVe 100d向量需提前下载glove.6B.100d.txt def load_glove_embeddings(filepath, word_index, embedding_dim100): embeddings_index {} with open(filepath, encodingutf-8) as f: for line in f: values line.split() word values[0] coefs np.asarray(values[1:], dtypefloat32) embeddings_index[word] coefs # 创建embedding矩阵 embedding_matrix np.zeros((len(word_index) 1, embedding_dim)) for word, i in word_index.items(): embedding_vector embeddings_index.get(word) if embedding_vector is not None: embedding_matrix[i] embedding_vector return embedding_matrix # 在Keras模型中使用 vocab_size len(tokenizer.word_index) 1 embedding_matrix load_glove_embeddings(glove.6B.100d.txt, tokenizer.word_index) embedding_layer Embedding( input_dimvocab_size, output_dim100, weights[embedding_matrix], input_lengthmax_length, trainableFalse # 先冻结训练稳定后再设True微调 )避坑指南trainableFalse是新手必设参数。我见过太多人直接设trainableTrue结果模型在前10个epoch就把预训练向量破坏殆尽准确率不升反降。正确流程是先冻结训练10-20 epoch收敛再解冻最后几层微调。4. 真实战场复盘四个血泪教训与对应解决方案4.1 教训一把“用户ID”当类别编码引发维度海啸场景某社交App推荐系统原始数据含user_id1200万唯一值、item_id800万、category12个。工程师对三者全用OneHot特征矩阵达2000万列训练直接OOM。排查过程第一步df[user_id].nunique()确认基数第二步df[user_id].value_counts().head(10)发现Top10用户占总交互52%存在严重长尾第三步df.groupby(user_id)[target].mean().hist(bins100)显示用户转化率呈双峰分布活跃用户vs沉默用户。解决方案对user_id用TargetEncoder但分桶处理——将用户按历史交互次数分为5档0次、1-5次、6-20次、21-100次、100次再对每档内用户用目标均值编码。维度从1200万→5对item_id用HashingVectorizern_features2**18冲突率0.001%对category保留OneHot仅12列。效果内存占用从128GB降至4GBAUC提升0.023。4.2 教训二Ordinal编码“星期几”却忽略业务周期性场景某外卖平台预测订单量对day_of_week用OrdinalEncoder编码为[0,1,2,3,4,5,6]模型在周五预测偏差极大。根因分析线性模型认为day5Friday和day6Saturday的增量应等于day0Sunday和day1Monday的增量但实际周末效应是非线性的周六峰值最高周日次之周五第三更致命的是Ordinal编码将周日0和周六6在数值上设为最远但业务上它们是相邻的消费高峰日。解决方案改用循环编码Cyclical Encoding将day映射到单位圆上import numpy as np tips[day_sin] np.sin(2 * np.pi * tips[day_ordinal] / 7) tips[day_cos] np.cos(2 * np.pi * tips[day_ordinal] / 7)此时周日0和周六6的(sin,cos)坐标分别为(0,1)和(-0.78,0.62)欧氏距离仅0.76远小于周日与周三3的距离1.41完美捕捉周期性。效果LSTM模型MAE下降18%周五预测误差从±23单降至±11单。4.3 教训三TfidfVectorizer未清洗URL和HTML标签引入噪声场景某新闻聚合平台用Tfidf做文章聚类结果科技类和娱乐类文章被错误聚为一类。诊断抽取聚类中心词发现高频词含p,/div,https://,www.等。原始文本未清洗Tfidf把HTML标签当普通词处理。解决方案在TfidfVectorizer前加自定义预处理器import re def clean_html(text): # 移除HTML标签 text re.sub(r[^], , text) # 移除URL text re.sub(rhttp\S|www\S|https\S, , text, flagsre.MULTILINE) # 移除多余空格 text re.sub(r\s, , text).strip() return text tfidf TfidfVectorizer(preprocessorclean_html, stop_wordsenglish)对专业领域添加领域停用词stop_wordslist(stop_words) [said, according, reported]效果聚类轮廓系数从0.31提升至0.67人工评估准确率从68%升至92%。4.4 教训四Word2Vec训练数据不足导致向量坍缩场景某医疗问答机器人用仅2000条医患对话训练Word2Vecfever和cough余弦相似度仅0.12远低于预期。分析Word2Vec需足够上下文才能学习语义。2000条对话平均句长15字总词数仅3万远低于Word2Vec建议的100万词门槛。破局策略数据增强用同义词替换如fever→pyrexia,cough→tussis基于UMLS医学术语库迁移学习加载BioWordVec生物医学预训练向量在其基础上用2000条对话微调from gensim.models import KeyedVectors biovec KeyedVectors.load_word2vec_format(BioWordVec_PubMed_MIMICIII_d200.vec.bin, binaryTrue) # 用新数据更新向量 biovec.train(sentences, total_exampleslen(sentences), epochs5)效果fever与pyrexia相似度达0.89与cough升至0.41问答准确率提升35%。5. 工程化落地 checklist从 notebook 到生产环境的七道关卡编码方案在Jupyter里跑通不等于能在生产环境扛住流量。以下是我在部署50数据管道时总结的硬性检查清单5.1 关卡一编码器持久化——Pickle不是银弹Scikit-Learn的joblib.dump()是常用方案但存在隐患版本锁死joblib保存的模型与sklearn版本强绑定升级sklearn后joblib.load()可能失败跨语言障碍Java/Go服务无法加载Python pickle。生产方案对简单编码器OneHot, Ordinal用JSON保存配置import json config { type: onehot, categories: [[Male, Female]], drop: first } with open(encoder_config.json, w) as f: json.dump(config, f)对复杂向量化器Tfidf, Word2Vec用ONNX格式导出from skl2onnx import convert_sklearn from skl2onnx.common.data_types import StringTensorType initial_type [(input, StringTensorType([None, 1]))] onnx_model convert_sklearn(tfidf, initial_typesinitial_type) with open(tfidf.onnx, wb) as f: f.write(onnx_model.SerializeToString())ONNX可在Python/Java/C#/Go中通用运行。5.2 关卡二线上推理的冷启动问题新用户注册时user_id从未在训练集中出现OneHotEncoder会报ValueError: y contains previously unseen labels。解决方案在OneHotEncoder中设handle_unknownignore未知ID输出全0向量更优方案用TargetEncoder时对未知ID返回全局目标均值并记录日志告警终极方案对高基数ID改用HashingEncoder无未知值概念。5.3 关卡三特征漂移监控——编码器也需要体检训练时day有4个值线上突然出现Mon新工作日或category新增Vegan子类编码器会崩溃。监控指标未知值率unknown_ratio num_unknown / total_samples阈值0.1%告警分布偏移用KS检验对比线上/线下day_ordinal分布p-value0.05触发重训维度一致性线上编码后特征数必须等于训练时encoder.n_features_in_。5.4 关卡四内存与延迟的平衡艺术TfidfVectorizer生成的稀疏矩阵在线上服务中需转为密集数组供XGBoost使用但10万维向量单次转换耗时20ms超SLA。优化手段用scipy.sparse.csr_matrix.toarray()替代np.array()快3倍对高频请求缓存热门文本的向量LRU Cache极致优化用Cython重写向量化核心将延迟压至2ms内。5.5 关卡五A/B测试的编码一致性实验组用新Tfidfmax_features10000对照组用旧版max_features5000特征维度不一致导致模型无法比较。强制规范所有编码器配置必须存入Git版本号与模型版本绑定在特征服务API中加入encoder_version参数强制校验使用MLflow等工具追踪每次训练的编码器哈希值。5.6 关卡六GDPR合规——编码是否构成个人数据对user_id做TargetEncoding后编码值隐含用户行为信息如高编码值高付费用户可能被认定为间接标识符。合规动作对敏感ID用HashingEncoder替代确保不可逆添加噪声encoded_value target_mean np.random.normal(0, 0.01)在数据血缘系统中标注“此特征含PII衍生信息”。5.7 关卡七回滚能力——当新编码器上线崩盘新OrdinalEncoder因顺序错误导致所有预测值为NaN。防御机制所有编码器上线前必须通过影子流量Shadow Traffic新旧编码器并行处理1%流量对比输出差异自动熔断当新编码器输出异常率5%自动切回旧版本回滚包每次发布包含旧版编码器二进制一键回退。这七道关卡每一道都来自真实事故。我曾因忽略关卡三分布偏移导致推荐系统在黑色星期五当天CTR暴跌40%损失百万级GMV。从此我的编码器交付物永远包含三样东西1JSON配置文件2ONNX模型3一份签字的《生产就绪检查清单》。编码不是数据流水线的末端工序而是整个AI系统的地基——地基松动上层建筑再华丽也是危楼。6. 我的编码哲学在确定性与不确定性之间走钢丝写完这五千字我合上笔记本想起十年前第一次部署编码器时的窘迫为搞懂OneHotEncoder的drop参数我翻遍Sklearn源码在_encoders.py里逐行调试咖啡凉了三次。如今我依然每天花两小时读新论文不是为了追逐BERT、LLM这些热点而是想弄清一个问题当模型越来越强大我们是否还需要手工设计编码答案是肯定的而且比以往更需要。因为大模型的黑箱特性反而放大了编码错误的后果——一个错误的Ordinal顺序可能让千亿参数模型在关键决策上系统性偏航。我现在的做法是用LLM做文本清洗和初筛如用GPT-4提取评论中的显性情感词但最终的数值化仍由经过千锤百炼的编码器完成。LLM负责理解“意图”编码器负责定义“坐标”。最后分享一个私藏技巧在所有编码前先画一张“语义距离图”。拿一支笔在纸上写下所有类别用线段连接语义相近的项并标注主观距离1-5分。比如“iPhone”和“Samsung”连一线标4分“iPhone”和“banana”连一线标1分。这张图不会进代码但它会告诉你该用One-Hot所有距离5还是TargetEncoder距离影响权重或是Embedding距离需数据学习。编码的本质是把人类模糊的语义直
