简介：基于机器学习的MBTI人格预测系统项目，面向对自然语言处理与人格分析感兴趣的机器学习初学者及进阶开发者。项目围绕文本数据清洗、特征工程、模型训练与评估展开，完整覆盖从数据处理到系统集成的流程。资源共2000个文件，以1894个Python脚本为主体，配合C/C++扩展文件、TXT说明文档及DOCX项目文档，压缩包约253MB。Python代码涵盖数据预处理、模型构建与界面逻辑，C文件多为底层计算库，便于理解性能优化细节。已有1819人学习下载。内含项目开发计划与可行性报告，并附有完整可运行的代码体系，适合作为课程设计、毕业设计或竞赛项目的参考模板，可直接对照学习调参与评估思路，节省从零搭建的时间。
1. 这个“MBTI预测”项目到底在做什么：先过概念的坎
基于机器学习的MBTI人格预测系统，说白了就是给一段文本打上16型人格标签的文本分类项目。这类选题在社交内容分析、用户画像、个性化推荐里经常出现，也是很多开发者练手NLP的常见方向。但我得先泼一盆冷水：如果你直接拿公开数据集训练一个多分类模型，很大概率会得到“看起来准确率很高、拿到真实场景就翻车”的结果。原因不是模型不够强，而是数据构造、标签拆分、验证方式这三个环节从一开始就走歪了。这篇笔记会把整条链路拆开讲清楚：数据从哪来、特征怎么抽、模型怎么选、坑在哪里，以及最后怎么把预测结果做成产品能用的形态。适合两类人看：一是想用文本分类练手的开发者，二是产品里需要轻量用户画像、但又不想上重型用户建模方案的工程师。
2. 把“没有数据集”变成能训练的数据：三个可行来源与构造脚本
做这个项目，卡住大多数人的第一关不是模型，而是数据。MBTI标注数据不像情感分类那样随手能抓到，公开可用的中英文语料都比较有限，而且质量参差不齐。我一般会把数据来源分成三条线，按成本从低到高排。
2.1 公开标注集、社区自采集、半自动伪标注：三个来源怎么搭
第一条是公开数据集。一些公开数据集平台上能搜到带MBTI标签的社交文本，来源大多是用户自报类型后的发言记录。这类数据量大、标注成本为零，但标签是用户自我报告，本身就有噪声。用之前要看一下四维分布，通常N和F会明显偏多，后面对类别不平衡的处理基本跑不掉。
第二条是社区自采集。如果你有稳定的数据通道，可以在允许的公开范围内，按“我是INTJ”“INFJ路过”这类关键词收集带标签文本。这个方式的好处是语料新鲜、贴近真实场景，坏处是采集和清洗都要自己写脚本，且要尊重各平台的用户协议和隐私边界。我在做类似项目时通常会控制采集规模，先拿几千条把流程跑通，而不是一上来追求几十万条。
第三条是半自动伪标注。当标注数据实在不够时，常见做法是先用已有标注集训练一个初版模型，再让它对大量无标签文本预测，取高置信度样本人工抽查，通过之后并回训练集。这个过程可以滚动几轮，每一轮模型都会比上一轮更能挑出“像样”的语料。注意抽查比例不能太低，我一般每轮抽10%的人工复核，低于85%一致率就回滚。
还有一种路线值得提一下：不做文本，改用结构化数据。让用户回答一版简化的人格测试题，把每道题的选项当成特征去预测四维标签，这个方案在特征可解释性上比文本强很多，而且数据质量可控。它和文本路线不冲突，但如果你手里能收到问卷数据，这个路线更容易出稳定效果。
2.2 清洗与标签规整：非典型人格与文本长度是第一道坎
不管数据从哪条来源进来，清洗环节都要做三件事：长度过滤、文本归一化、标签按四维拆分。长度过滤最容易被人忽略——少于20个字的短文本基本没有足够的人格信号，留着只会增加噪声。文本归一化则要把URL、@用户、重复标点清理掉，但千万别用通用的停用词表把人格相关词汇一并删掉。
标签拆分是更关键的一步。MBTI的16型本质上是四组二分法的组合：I/E、N/S、T/F、J/P。如果直接拿“INTJ”“ENFP”这种完整标签做16分类，会遇到两个问题：一是某些组合在真实分布里极少，比如ESTJ在社交平台文本里样本少得可怜；二是标签噪声会互相传播，一个维度标错了，整个16类结果就废了。所以我在预处理阶段就把标签拆成四个二分类目标，让模型分别学四个维度，效果稳得多。
下面是清洗和标签拆分的核心脚本：
import json import re from collections import Counter AXIS = [('I', 'E'), ('N', 'S'), ('T', 'F'), ('J', 'P')] # 保留MBTI社区常用黑话，避免清洗时被停用词表误删 MBTI_KEYWORDS = {'intj', 'infp', 'entp', 'enfp', 'fi', 'te', 'ne', 'si'} def norm_text(text): text = text.lower() text = re.sub(r'https?://\S+', '', text) # 去URL text = re.sub(r'@\S+', '', text) # 去@用户 text = re.sub(r'([!?。！？])\1+', r'\1', text) # 合并连续标点 text = re.sub(r'\s+', ' ', text).strip() return text def split_label(mbti): """把 'INFJ' 拆成四个维度的极性标签""" out = {} for a, b in AXIS: key = f'{a}_{b}' out[key] = b if b in mbti else a return out def build_dataset(lines, min_len=20): data = [] for line in lines: obj = json.loads(line) uid = obj.get('uid', '') text = norm_text(obj.get('text', '')) mbti = obj.get('mbti', '').upper() if len(text) < min_len: # 过短文本信号不足，丢弃 continue row = split_label(mbti) row['uid'] = uid # 保留用户ID，后续按组划分防泄漏 row['text'] = text data.append(row) print('清洗后样本数:', len(data)) for k in ['I_E', 'N_S', 'T_F', 'J_P']: print(k, Counter(r[k] for r in data)) return data这段脚本有几个参数需要按数据情况调。min_len设为20是经验值，如果语料普遍偏短可以降到15，但再低就容易混入碎片化噪声。MBTI_KEYWORDS这个集合是特意保留的，像“fi”这种词在通用停用词表里会被当噪声过滤，但在MBTI语境里是明确的情感功能信号。split_label把16类标签拆成4个二元标签，后面训练时可以分别评估每个维度的表现。
注意，函数里保留了uid字段。这是为了后面划分训练集和验证集时按用户分组，避免同一个人的多条文本同时出现在两边。这个问题很多人栽过，后面避坑章节会详细展开。
3. 特征工程：从文本里把人格信号抽出来
数据到位后，下一步是让文本变成模型能吃的向量。MBTI预测和普通情感分类不一样的地方在于，人格信号分散在句子的长度、标点习惯、用词偏好、表达密度这些“风格”层面，而不是集中在某个关键词上。所以特征工程要比常规文本分类做得更细致。
3.1 先算最容易拿到的：句长、标点、语气词特征
我一般会先算一批统计特征，因为它们计算成本低、可解释性强，而且对MBTI的某些维度确实有区分度。举例来说，外向型(E)的发言通常句子更短、句数更多、感叹号用得更频繁；直觉型(N)的人更爱用抽象词和比喻；情感型(F)的人语气词、表情符号出现频率明显高；判断型(J)的人表达更结构化，而感知型(P)的人句子更跳跃。
常用的统计特征包括：总字符数、句子数量、平均句长、问句占比、感叹号个数、括号使用次数、第一人称代词频率、Emoji数量。注意这些特征在不同语料上分布差异很大，中文和英文尤其明显。中文没有大小写特征，英文语料里大写单词比例是有区分度的信号，中文就要换成别的特征补位。
import re import numpy as np def stat_features(text): sentences = re.split(r'[。！？!?\.]', text) sentences = [s for s in sentences if s.strip()] words = re.findall(r'\w+', text) feat = { 'char_len': len(text), 'sent_count': len(sentences), 'avg_sent_len': np.mean([len(s) for s in sentences]) if sentences else 0, 'question_ratio': text.count('?') + text.count('？'), 'exclaim_count': text.count('!') + text.count('！'), 'bracket_count': text.count('(') + text.count('（'), 'first_person_ratio': len(re.findall(r'\b(I|我|咱)\b', text)) / max(len(words), 1), 'emoji_count': len(re.findall(r'[\U0001F300-\U0001FAFF]', text)), } return feat这里avg_sent_len按字符数计算而不是按词数，对中英文混合语料更稳妥。first_person_ratio是一个容易被低估的特征——文本里第一人称越多，表达越偏向自我感知强，这个和某些人格维度的相关性在多个语料上都能复现。如果你的语料没有表情符号，emoji_count会恒等于0，留着不碍事，但别指望它贡献区分度。
统计特征单独使用时效果有限，准确率通常比随机高不了太多，但它们是后续和TF-IDF、语义特征拼接时的稳定底座。
3.2 TF-IDF与词袋：MBTI黑话要单独建词典
统计特征之外，词级别的特征是这个项目的主力。TF-IDF在人格预测里的作用比很多人想的大，因为MBTI社区已经形成了比较固定的“黑话”，比如“内耗”“高敏感”“Ni”“Fe人”这些词，天然就是强特征。只要这些词在清洗时没被误删，TF-IDF就能把它们抓出来。
中文文本需要分词，英文按空格切分就行。分词工具的默认词典通常不认识MBTI社区词，比如“infj”可能被切成“inf”“j”，所以要在分词时加入自定义词典。另一个细节是n-gram范围，1到2比较稳，3以上的组合在有限语料里会稀疏；max_features我一般设在20000左右，太大容易过拟合，太小会丢掉长尾表达。
from sklearn.feature_extraction.text import TfidfVectorizer def build_tfidf(corpus, max_features=20000): vec = TfidfVectorizer( max_features=max_features, ngram_range=(1, 2), min_df=3, sublinear_tf=True, token_pattern=r'(?u)\b\w+\b', ) # 如果语料是中文，需要先过自定义分词再传入 X = vec.fit_transform(corpus) print('特征维度:', X.shape[1]) return vec, X这里的核心参数是min_df=3，它会让出现次数少于3次的词汇直接忽略，对减少噪声很有效。sublinear_tf=True把词频做对数缩放，防止高频词（比如“我”“你”）在人格维度上产生虚假的区分为。很多人在这里会忽略的一点是：TF-IDF特征必须只在训练集上fit，验证集和测试集只能做transform，否则词汇表会泄漏未来信息。
3.3 预训练embedding：什么时候必须上，放在哪一层
统计特征和TF-IDF组合起来，已经能跑出一个还不错的baseline。但这类特征的本质是“词汇表匹配”，遇到同义替换或口语化表达就会失效。比如“我真的很累”和“整个人都不好了”表达相近情绪，但词面完全不同，TF-IDF抓不到这种关联。这时候就需要预训练embedding。
我一般会把embedding当作第二路特征使用，而不是完全替代TF-IDF。具体做法是：用预训练模型对每条文本编码成向量，再把TF-IDF向量和统计特征拼接起来，喂给分类器。如果直接只用embedding，长文本里的统计细节会被池化操作抹平，句长、标点习惯这些对人格预测有价值的信号就丢了。拼接策略下，统计特征和语义特征各司其职。短文本场景下embedding权重可以放大，长文本场景下统计特征和TF-IDF仍然占主导。
# 伪代码：embedding编码 + 特征拼接 def encode_embedding(texts, model, batch_size=64): vecs = [] for i in range(0, len(texts), batch_size): batch = texts[i:i+batch_size] emb = model.encode(batch) # 输出 [batch, dim] vecs.append(emb) return np.vstack(vecs) # 训练时做特征拼接 # X_stat: 统计特征矩阵 # X_tfidf: TF-IDF稀疏矩阵 # X_emb: embedding稠密矩阵 # X_all = hstack([X_stat, X_tfidf, X_emb])这里model.encode的池化方式值得留意。常见做法是用CLS向量或平均池化，对短文本来说平均池化通常更稳，因为它不会过分依赖某几个token。如果语料是中文，选embedding模型时优先考虑中文语料上表现好的轻量模型；英文语料选择更多，但要关注模型的最大输入长度。超过512 token的长文本直接截断或分段池化，别指望模型能吸收全部上下文。
4. 模型选型与训练：4个二分类为何优于16分类
特征准备好之后，进入模型环节。这里我先给结论：训练4个二分类器，比训练1个16分类器稳定得多。这不是玄学，而是数据和任务结构决定的。
4.1 模型选型：4个二分类与1个16分类的结果差异
16分类的问题有三个。第一，样本稀疏，平均每类只有总数据量的1/16，很多类样本量连几百条都不到，模型根本学不充分。第二，标签噪声互相传播，一个样本的T/F维度标错了，它就被扔进了另一个完全不同的类型里，而四个维度单独训练时，最多只影响其中一个分类器。第三，类别极不平衡，社交语料里NF型明显偏多，ESTJ这类务实型极少，16分类直接训练会让模型整体偏向高频类。
4个二分类则完全不同。每个分类器只需要关心一个维度，样本天然是五五开的比例，数据利用率更高，也更容易针对每个维度单独调参。比如I/E维度可能用词频特征效果更好，N/S维度可能语义特征更重要，分而治之后每个维度都能找到自己的最优配置。
模型选择上，我做这类项目时一般用逻辑回归作为baseline，效果不行再换LightGBM。逻辑回归在文本特征上是经典强基线，训练快、可解释，而且对稀疏特征处理得干净。LightGBM则在特征拼接场景下能自动找特征组合，但要注意防止在小数据上过拟合。朴素贝叶斯也值得跑一版，速度快，但特征独立性假设在人格文本上不太成立，效果通常比逻辑回归差一截。
4.2 训练脚本骨架：分层采样、类别权重、五折验证
训练环节有三样东西不能省：按用户分组划分数据、类别权重、交叉验证。按用户分组划分是为了防泄漏，同一个人的文本不能被同时分到训练集和验证集；类别权重是因为即使拆成二分类，N/S、T/F在某些数据源里仍然不平衡；交叉验证则是为了得到稳定的效果估计，而不是只看单次划分的运气。
from sklearn.model_selection import GroupKFold from sklearn.linear_model import LogisticRegression from sklearn.metrics import accuracy_score, f1_score def train_axis(X_pool, y_axis, groups, feature_builder): """训练单个维度的二分类器，使用分组五折验证""" gkf = GroupKFold(n_splits=5) accs, f1s = [], [] for train_idx, val_idx in gkf.split(X_pool, y_axis, groups): X_tr = feature_builder.fit_transform(X_pool[train_idx]) X_va = feature_builder.transform(X_pool[val_idx]) y_tr, y_va = y_axis[train_idx], y_axis[val_idx] model = LogisticRegression( max_iter=500, class_weight='balanced', # 自动调整类别权重 ) model.fit(X_tr, y_tr) pred = model.predict(X_va) accs.append(accuracy_score(y_va, pred)) f1s.append(f1_score(y_va, pred, zero_division=0)) print(f'ACC: {np.mean(accs):.4f} ± {np.std(accs):.4f}') print(f'F1: {np.mean(f1s):.4f} ± {np.std(f1s):.4f}') return model代码里class_weight='balanced'的作用是按类别频率反向加权，当N型样本是S型的三倍时，S型的误分类代价会自动放大三倍，有效防止模型躺平在多数类上。GroupKFold按uid分组切分，保证验证集里出现的都是训练集没见过的人，这才是模拟真实上线场景。max_iter=500是逻辑回归收敛的余量，如果你的特征维度很高（比如超过5万维），可以适当加到1000。
一个容易翻车的细节是feature_builder的写法。上面的代码里，每一折都要单独fit_transform训练数据、再transform验证数据，不能在整个数据集上先算好TF-IDF再切分，否则词汇表里就包含了验证集的信息。这个坑会让你的验证指标虚高，但上线后立刻现出原形。
4.3 验证策略：看维度准确率，别被整体准确率骗了
验证阶段最常见的错误是只盯着整体准确率。在MBTI这种天然不平衡的数据上，整体准确率几乎没有参考价值——比如N型占70%的数据里，无脑全猜N就能拿到70%准确率，看着很高，实际什么都没学。正确做法是分维度看四个二分类器的准确率和F1，并且和“全猜多数类”这个无脑基线做对比。
另一个值得做的验证是校准概率。二分类器默认用0.5作为阈值，但人格维度的预测概率分布往往偏向中间区域，很多样本的预测概率落在0.5附近。这时候可以单独从验证集里取概率值，画出分布，或者用校准曲线看一下预测概率和真实频率的偏差。如果概率普遍偏向极端（0.1或0.9），说明模型过拟合；如果全部挤在0.5附近，说明特征没有足够区分度。后面对推理侧的阈值设计也需要这套验证结果支撑。
5. 避坑与排查：五类高频故障的现场还原与修复
这个方向做了几轮之后，我踩过的坑基本都集中在数据、预处理和评估三个层面。下面五条是我认为最具代表性的，按“现象→原因→解决”的结构写清楚。
5.1 数据泄漏与误删黑话词：两个最容易翻车的地方
坑一：准确率虚高到90%，上线后崩到60%。现象是交叉验证阶段整体准确率漂亮得不像话，模型的F1也高，但一上线处理真实用户文本就垮掉。原因几乎可以锁定为数据泄漏：同一个用户的几十条发言被同时分进了训练集和验证集，模型已经“见过”这个人了，验证自然失真。解决方法是严格按uid分组做划分，用GroupKFold，并且训练时把uid作为一个字段跟随样本，随时能追踪到哪些用户参与过训练。
坑二：清洗完成后，模型完全学不到“Ni”“Fe”这类词。现象是模型在验证集上的准确率和只用统计特征时差不多，词级别特征几乎没有贡献。原因通常是清洗环节用了通用停用词表或分词词典，把MBTI社区黑话当作噪声过滤了。解决方法是像前面代码里那样单独维护一份领域词表，在清洗和分词后做一次回填校验。最直观的检查方法是打印TF-IDF词表中权重最大的前50个词，看里面是否有人格相关的词——没有就说明特征工程没吃透语料。
5.2 类别失衡、跨语言特征失效、线上输入漂移
坑三：模型总是输出NF型，尤其偏爱INFJ。现象是统计所有预测结果，I/E、T/F两个维度的预测分布严重偏向某一端，预测结果几乎不出现STJ类。原因就是公开数据集里NF型样本占比太高，模型学会了走捷径。解决方法是双管齐下：一是class_weight='balanced'必须开，二是做完采样或下采样要单独验证小类别的F1而不是只盯整体。如果小类别F1低于0.3，说明该类样本量实在不够，与其硬训不如先去补数据。
坑四：英文语料上有效的句长、逗号密度特征，换到中文语料完全不灵。现象是在英文数据集上四维ACC都能跑到0.75左右，换了中文数据后立刻掉到0.6甚至更低。原因是不同语言的表达习惯差异极大，英文语料里通过大小写、缩写、标点密度反映的人格信号，中文里压根不存在。解决方法是不要迷信“论文里的特征清单”，换语料后要重新做一轮特征重要性分析，把不显著的特征剔掉，并用embedding补位。中文语料里“我/我们”的分布、“了/啊/吧”这类语气词频率反而是更值得关注的特征。
坑五：验证指标稳定，但线上输入是短句，推理结果开始随机波动。现象是模型在长文测试集上F1不错，但用户实际输入只有十几个字，预测结果每次都不一样。原因是训练集与线上输入的长度分布不一致，模型没见过这么短的文本。解决方法是训练时做长度增强：随机截断部分长文本作为训练样本，让模型适应短输入；推理侧还要设定最短长度阈值，低于阈值直接返回“信号不足”而不是硬给标签。这比任何后处理都更诚实。
6. 从单条文本到人格画像：把概率输出做成能用的产品能力
模型训练完毕，如果直接输出16类型标签，使用体验会很差——单条文本的预测本身就带噪声，硬标一个类型给用户看，错了就是全错。我现在的做法是改成概率画像输出：四个维度各输出一个0到1的概率，再决定如何呈现。
def predict_profile(model_dict, vec, text): """ model_dict: {'I_E': model, 'N_S': model, 'T_F': model, 'J_P': model} 返回四维概率画像 """ result = {} for axis, model in model_dict.items(): prob = model.predict_proba(vec)[0][1] # 第二类的概率 result[axis] = round(prob, 3) return result # 输出示例 # {'I_E': 0.312, 'N_S': 0.782, 'T_F': 0.415, 'J_P': 0.655}拿到四维概率后，阈值设置可以直接利用第4章验证阶段得到的校准结果。如果验证集上I/E维度的概率普遍分布在0.35到0.65之间，说明这个维度区分度弱，阈值得适当收紧，比如只有大于0.6才输出E标签；如果N/S维度的概率分布在0.2和0.8两端，0.5阈值就够用。这个差异化阈值策略比统一阈值带来的体验提升要明显得多。
概率画像还有一个好处：它天然支持“不确定就如实说”的交互方式。当某个维度的概率落在0.45到0.55之间时，界面可以直接展示“该用户在这个维度上倾向不明显”，而不是强行给出一个标签。这种做法在用户画像场景里反而更可信——用户不会因为一次分类错误就否定整个系统，而是能理解这是基于有限文本的估计。我在某公司的轻量画像服务里就是这么做的，用户侧的接受度比硬标签高出不少。
我自己早期的项目就是直接输出16类标签，上线后被用户反馈“完全不准”，后来改成概率画像并附带一段解释文案，情况才明显好转。做这个方向，核心心力不该花在追求一个完美的16分类器上，而是把“不确定”这件事用工程手段表达清楚。希望帮到你。
本文还有配套的精品资源，点击获取
