首页 / 资讯中心 / 文章详情

DeepSeek 数据工作流实战:从导入清洗到分析生成与部署

DeepSeek 数据工作流实战:从导入清洗到分析生成与部署 ★ FEATURED ARTICLE
简介《DeepSeek详细使用教学》面向希望快速熟悉DeepSeek这一AI数据搜索与分析平台的初学者及日常办公、学习用户围绕注册登录、基础功能认知和完整操作流程展开重点解决上手路径不清、功能入口难找及常见使用问题排查等需求。整份资料为1个doc文档压缩包约38KB篇幅精简适合作为随查随用的入门手册。内容从数据导入、清洗、分析与可视化延伸到文本生成、摘要、情感分析、翻译、任务自动化、工作流优化以及模型训练与部署并补充批量处理、自定义模板、优化设置、简洁表达需求和多次交流尝试等技巧。文末还整理了数据导入错误、文本生成不符合预期、自动化任务执行失败等问题的排查思路。已有667人学习便于读者按模块对照实践逐步掌握DeepSeek的核心用法。1. 从一份详细使用教学说起该在哪一步接进你的活拿到一份《DeepSeek 详细使用教学》多数人从“注册与登录”读起读到“点击生成”就关掉。真正让人卡住的很难说是按钮在哪里真正麻烦的是哪一步该交给它、哪一步必须自己先算清楚。这份教学覆盖数据导入、清洗、分析、可视化、文本生成、摘要、情感分析、翻译、任务自动化、模型训练与部署本质是一份把 AI 当工作台用的操作清单。它适合手里已经有一批 CSV、Excel、JSON 脏数据或者每周要出固定报告、做批量文本处理的人如果你只是想找人聊天这些流程反而是负担。下面按“数据进来、算清楚、写成文、别翻车”的顺序拆成能照着跑的动作。2. 数据导入与清洗CSV、Excel、JSON 三个入口和四条清洗规则导入是整条链路上最不起眼的一步也是出错率最高的一步。平台界面上就一个“导入数据”按钮点下去、选文件、等进度条走完看着像三秒钟的事。但真正决定后面分析能不能用的是文件读进来的那一刻字段类型对不对、空值有没有被误判、日期能不能解析。同一份 CSV本地用表格软件打开一切正常导入后变成一列字符串加一堆 null这类情况我见得太多。原因基本集中在编码、分隔符和类型推断这三件事上。这一章先把三个入口的差异讲清楚再用脚本把体检和清洗固化下来最后说明清洗动作的顺序为什么不能乱。2.1 三个入口的差异与选型CSV 是最常见的入口纯文本、结构扁平、每行一条记录。好处是任何工具都能生成坏处是所有类型信息都只依赖“人以为的”文件里实际只有字符。手机号、订单号、邮编这类字段只要出现过一次不带引号的前导零读进来就会变成数字前面的 0 直接蒸发。Excel 的情况更复杂多 sheet、合并单元格、隐藏行列、公式单元格都会影响读取结果。合并单元格只有左上角有值其余位置读出来是 NaN隐藏行不会因为看不见就被跳过照样进结果公式单元格读到的是缓存值还是公式本身取决于读表引擎。JSON 则是接口返回的典型格式嵌套层级深展开之后行数可能膨胀好几倍一个订单里挂十条明细展平就是一变十。格式典型来源最容易出问题的地方处理建议CSV系统导出、埋点明细编码、分隔符、前导零指定编码全部按字符串读Excel业务台账、人工维护表合并单元格、隐藏行、多 sheet先列 sheet 清单再选JSON接口响应、日志嵌套数组展开后行数膨胀展平后核对行数变化我的习惯是不管最终从哪个入口进平台都先在本地用一段脚本把文件读一遍打印行列数、字段类型和空值率确认没问题再上传。平台端的报错通常只给一句“格式不支持”定位不到具体哪一列本地先过一遍能省掉大量来回试。import json import os import pandas as pd def load_file(path): 按扩展名分流读取先把文件原样读进来不急着做类型转换 ext os.path.splitext(path)[1].lower() if ext .csv: # utf-8-sig 兼容带 BOM 的文件dtypestr 保住前导零 return pd.read_csv(path, encodingutf-8-sig, dtypestr, keep_default_naFalse, sepNone, enginepython) if ext in (.xlsx, .xls): # sheet_nameNone 返回字典先看清有几个 sheet 再决定用哪个 return pd.read_excel(path, sheet_nameNone, dtypestr) if ext .json: with open(path, encodingutf-8) as f: raw json.load(f) return pd.json_normalize(raw, sep_) raise ValueError(f不支持的扩展名: {ext})这段代码的关键在几个参数上。encodingutf-8-sig处理带 BOM 的 Excel 导出文件不加这个参数第一列列名前面会多出一个看不见的字符后面按列名取值全部取不到。dtypestr让所有列先按字符串读避免 pandas 自作主张把“007”变成 7。keep_default_naFalse保留空字符串否则“NA”“null”“None”这些业务里真实存在的文本会被当成缺失值抹掉。sepNone, enginepython让读取器自己嗅探分隔符对付逗号、分号、制表符混用的表很有效。sheet_nameNone返回的是一个字典而不是 DataFrame这是刻意的因为业务表经常把说明放在第一个 sheet数据在第二个先看清楚再取。json_normalize的sep_把嵌套键拼成order_id、user_name这种扁平列名展平后一定要回头核对行数变了就说明有数组被展开。2.2 上传前要看的五个指标文件读进来之后别急着点上传先做一次体检行数、列数、每列类型、空值率、唯一值个数。这五个指标里唯一值个数最容易被忽略但它能救命。一列如果nunique等于 1说明整列是常量放进分析里毫无信息量如果一列唯一值等于总行数那它大概率是主键不该出现在分组维度里如果一列的唯一值数量是几十到几百才适合做分类聚合。空值率超过 30% 的列要么在清洗阶段处理掉要么在分析阶段直接排除不要带着它去跑模型。def profile(df, namedata): 输出一份可读的字段体检表 stat pd.DataFrame({ dtype: df.dtypes.astype(str), non_null: df.notna().sum(), null_rate_pct: (df.isna().mean() * 100).round(2), nunique: df.nunique(dropnaTrue), }) dup df.duplicated().sum() print(f[{name}] 行{len(df)} 列{df.shape[1]} 完全重复行{dup}) return stat.sort_values(null_rate_pct, ascendingFalse) sheets load_file(orders.xlsx) for sheet_name, df in sheets.items(): print(profile(df, sheet_name).head(15)) print(- * 60)这里对每个 sheet 单独跑一次体检输出按空值率降序排列最脏的列排在前面。duplicated().sum()统计的是完全重复的行如果这个数不为零说明导出逻辑可能有问题比如多表关联时产生了笛卡尔积这种重复必须在清洗阶段先删掉否则后面所有汇总都会虚高。2.3 清洗动作的顺序去重、类型、缺失、异常清洗有一个很容易踩的坑动作顺序错了结果就全错。正确的顺序是先去完全重复行再统一类型然后处理缺失最后标记异常值。理由很直接类型没统一时做缺失填充字符串列的“中位数”根本算不出来异常值没识别就填缺失中位数本身已经被极端值带偏了。反过来如果先去重再算中位数样本更干净填充值也更可信。def clean(df, num_cols, cat_cols): df df.drop_duplicates().copy() # 第一步统一类型无法解析的脏值变成 NaN for c in num_cols: df[c] pd.to_numeric(df[c], errorscoerce) for c in cat_cols: df[c] df[c].astype(str).str.strip().replace({: None, nan: None}) # 第二步用中位数填充抗极端值 df[num_cols] df[num_cols].fillna(df[num_cols].median()) # 第三步3 倍 IQR 标记异常只打标不删除 q1 df[num_cols].quantile(0.25) q3 df[num_cols].quantile(0.75) iqr q3 - q1 mask (df[num_cols] q1 - 3 * iqr) | (df[num_cols] q3 3 * iqr) df[_is_outlier] mask.any(axis1) return df cleaned clean(orders, num_cols[amount, qty], cat_cols[channel, city]) print(cleaned[_is_outlier].value_counts())errorscoerce是这段代码里最实用的参数它把“1,234 元”“待定”“-”这类脏值统一变成 NaN而不是直接抛异常中断整条流程。填缺失用中位数而不是均值是因为金额、数量这类业务字段的分布通常右偏均值会被少数大额订单拉高填进去反而失真。IQR 阈值用 3 倍而不是教科书的 1.5 倍是业务数据长尾重的现实妥协1.5 倍会把大量正常的大客户订单误判成异常。最后只打_is_outlier标记不删除是为了保留回溯能力——模型效果不对时还能查出来是不是某一批异常值在捣乱。清洗完再把文件导出成平台能吃的格式上传就只是走个流程cleaned.to_csv(orders_clean.csv, indexFalse, encodingutf-8-sig)indexFalse去掉行号列否则导入后平台会多出一列无意义的索引utf-8-sig保证再用 Excel 打开不乱码。做完这一步导入环节的麻烦基本就清零了。3. 分析与可视化字段选型、图表匹配和三张诊断表导入分析模块之后面对的第一个问题是“选哪些字段”。平台会把你导入的所有列平铺出来让你勾选勾错一个后面整张图都是废的。常见的误操作是把主键扔进分组维度结果出来几千行结果图表根本没法看或者把日期当成普通字符串做分组月份顺序按字典序排成 1 月、10 月、11 月、2 月。这一章讲清楚三类字段各自的用法边界再说明图表类型和分析目的怎么对上号最后给一套在本地先算基准指标的做法用来校验平台输出是否可信。3.1 数值、类别、时间三类字段的用法边界数值字段适合做求和、均值、分位数、同比环比这类计算但前提是它的语义真的是“可以加减的数”。编号、邮编、年份虽然长得像数字实际上属于类别字段把它们当数值求和毫无意义。类别字段适合做分组和占比但基数太大的类别字段要小心比如用户 ID、订单号分组后可能产生上万个组分类数超过 20 的一般先做归并或者只取 Top N。时间字段是所有分析里价值最高的一类但它也是最容易出问题的日期格式不统一、时区不一致、跨年跨月边界处理不当都会让趋势图呈现出完全错误的形状。字段类型适合的分析动作不适合的动作判断标准数值求和、均值、分位数、环比分组维度有单位、可加减类别分组、占比、交叉对比求和、求均值取值可穷举时间趋势、同比环比、周期性直接当字符串分组能被正确解析成日期判断方法很朴素问一句“这个数加起来有没有意义”。金额加起来是总销售额有意义用户 ID 加起来是个莫名其妙的数字没意义。时间字段同理先转成日期类型再用.dt取年月比直接对字符串切片靠谱得多。3.2 图表类型要跟分析目的对上号平台的“可视化”选项卡会列出一排图表类型柱状图、折线图、饼图、散点图应有尽有。选图的依据是你要回答什么问题跟审美基本无关。看类别占比用条形图横向排布能容纳更长的类目名看时间趋势用折线图30 天以上的连续数据用柱状图会挤成一堵墙看两个数值变量的关系用散点图能一眼看出相关性和离群点看分布形态用直方图或箱线图只看均值会漏掉双峰分布这种关键信息。饼图的适用场景很窄类目超过 6 个就开始互相遮挡占比接近时肉眼完全分不出大小。要回答的问题推荐图表常见误用各渠道占比多少条形图8 个渠道塞进一张饼图近 90 天走势如何折线图用柱状图看连续趋势客单价和复购是否相关散点图用饼图表达相关性订单金额分布是否双峰直方图 / 箱线图只看均值不看尾部还有一点经验同一张图里不要混两种量纲。把销售额万元和订单数笔画在同一根 Y 轴上订单数会被压成一条平线读者以为订单没增长。要么拆成两张图要么用双 Y 轴并明确标注后者在正式报告里我一般不用容易引起误读。3.3 先在本地算一遍基准再交给平台出图平台的分析和趋势预测功能省事但我不会把它的输出直接当结论。做法是先在本地用几行 pandas 算出关键指标再拿平台的结果去对对得上才敢往下用。这样做并不是不信任工具只是要给结果留一个可核对的基准线。import pandas as pd df pd.read_csv(orders_clean.csv, dtype{order_id: str}) df[order_date] pd.to_datetime(df[order_date], errorscoerce) df[month] df[order_date].dt.to_period(M).astype(str) monthly ( df.groupby(month) .agg(orders(order_id, nunique), amount(amount, sum), avg_amount(amount, mean), buyers(user_id, nunique)) .reset_index() ) monthly[mom] monthly[amount].pct_change().round(4) # 环比 monthly[yoy] (monthly[amount] / monthly[amount].shift(12) - 1).round(4) print(monthly.tail(12))groupby(month)按自然月聚合nunique统计去重后的订单数和买家数避免同一用户一天下多单被重复计数。pct_change()算环比shift(12)取去年同月算同比这两个指标是业务复盘里最常被问到的。注意最后一年如果数据不完整同比会出现失真的巨大波动报告里要把不完整月份单独标注或者截掉。有了这份基准表平台的趋势预测输出就能对照着看它预测的下月金额和我手工算的环比区间差多少偏差超过合理范围就说明输入字段或者时间粒度选错了。可视化部分同理平台生成的柱状图如果和本地算出的月度汇总对不上优先怀疑聚合维度里混进了空值或者重复行而不是怀疑图表渲染。4. 文本生成与摘要提示结构、输入预处理和批量结果写入自然语言处理模块是这份教学里最容易被高估的部分。点一下“生成”出来一段通顺的文字看着很唬人但拿去交付往往不能用——要么全是正确但无用的套话要么把原文里的数字改错了。问题通常不在模型而在输入。这一章讲三件事提示怎么写才稳定、长文本喂进去之前要做什么预处理、批量跑的时候结果怎么保存和管理每一件都直接决定产出能不能用。4.1 四段式提示结构有效的提示基本都能拆成四段角色、任务、约束、输出格式。角色定基调任务说清楚要干什么约束划出边界字数、必须保留的信息、禁止出现的内容输出格式决定结果能不能直接被程序消费。少了约束输出长度随缘少了输出格式拿回来还得人工整理。举个对比写“帮我总结这段文本”得到的是自由发挥的段落写“你是一名数据分析师。用不超过 150 字概括下面的销售复盘保留所有数字和结论按‘现象—原因—建议’三行输出”得到的就是能直接贴进周报的结构化内容。约束里最有用的两条是字数和“必须保留”。摘要任务里模型最容易丢的就是数字和专有名词明确要求保留能显著降低返工率。输出格式用“每行一个要点”“输出 JSON字段为 title、summary、risk”这类可验证的描述比“排版清晰一点”有效得多。4.2 摘要和情感分析的输入预处理长文本直接丢进去有两个问题超出上下文长度会被截断截断位置往往正好把结论切掉文本里夹带的页眉页脚、导航栏、乱码会稀释有效信息。常见做法是先按段落切块每块控制在 2000 字左右块之间保留 200 字重叠防止一句话被切成两半。摘要分两步走先对每块出要点再把要点合并成最终摘要。情感分析则相反要先把表情符号、链接、 提及这类噪声去掉否则同一条评论在不同清洗策略下可能得出相反的极性。import re def chunk_text(text, size2000, overlap200): 按字符切块块间保留重叠避免句子被切断 text re.sub(r\s, , text).strip() chunks, start [], 0 while start len(text): chunks.append(text[start:start size]) start size - overlap return chunks def strip_noise(text): 情感分析前去掉链接、 提及和多余符号 text re.sub(rhttps?://\S, , text) text re.sub(r\S, , text) text re.sub(r[^\u4e00-\u9fa5a-zA-Z0-9。、], , text) return text.strip()size和overlap两个参数按文本密度调中文 2000 字大约是模型上下文的安全区overlap取size的 10% 左右够用。strip_noise里最后那条正则只保留中文、字母、数字和常用标点把表情和特殊符号一次性清掉这一步对情感分析影响很大很多表情符号携带的情绪强度和文字本身相反。4.3 批量调用与结果写入单个任务手点没问题几十上百条就必须走脚本。批量跑的核心是三件事失败重试、结果写入管理、错误可追溯。我用一个带指数退避的封装函数失败三次后把错误信息写进结果列而不是让整批任务中断。import os import time import requests BASE_URL os.environ[DEEPSEEK_BASE_URL] # 地址以官方文档为准 API_KEY os.environ[DEEPSEEK_API_KEY] def chat(prompt, system你是一名严谨的数据分析师。, timeout60): payload { model: os.environ.get(DEEPSEEK_MODEL, default), messages: [ {role: system, content: system}, {role: user, content: prompt}, ], temperature: 0.3, max_tokens: 800, } headers {Authorization: fBearer {API_KEY}, Content-Type: application/json} for attempt in range(3): try: resp requests.post(f{BASE_URL}/chat/completions, headersheaders, jsonpayload, timeouttimeout) resp.raise_for_status() return resp.json()[choices][0][message][content].strip() except Exception as exc: if attempt 2: return f__ERROR__:{type(exc).__name__} time.sleep(2 ** attempt)temperature设 0.3 是给摘要、抽取、翻译这类需要稳定输出的任务用的写营销文案这类创意任务可以放到 0.7 到 0.9但同一个 prompt 跑两遍结果会明显不同不适合做批量一致性要求高的活。max_tokens按输出长度预估设太小会被硬截断摘要任务 800 通常够用。重试用2 ** attempt做指数退避第一次等 1 秒第二次等 2 秒避免瞬时抖动把整批打断。失败时返回__ERROR__:XXX这种带标记的字符串后续用str.startswith(__ERROR__)一筛就能把失败行单独挑出来重跑比抛异常中断整批靠谱。import pandas as pd df pd.read_csv(reviews.csv, dtypestr) df[clean] df[content].map(strip_noise) results [] for text in df[clean]: results.append(chat(f用不超过 120 字概括下面内容保留数字和结论\n{text})) df[summary] results ok (~df[summary].str.startswith(__ERROR__)).sum() print(f成功 {ok} / {len(df)}) df.to_csv(reviews_summary.csv, indexFalse, encodingutf-8-sig)遍历时逐条调用而不是并发是为了控制频率、避免触发限流条数上千再考虑用线程池并发数从 3 到 5 起步。结果先用一列存原始返回再单独拆字段这样中间出问题还能从原始列里重新解析不用重跑一遍。5. 常见问题排查导入报错、生成跑偏、任务空转的现场复盘前面几章讲的是顺路径这一章讲翻车路径。下面这几条都是我在实际跑数据时撞过的现象看起来五花八门原因往往就那两三个。每条按“现象—原因—解决”写遇到相似症状可以先对号入座。5.1 导入与清洗环节现象一导入提示格式不支持本地打开完全正常。原因通常是编码或者分隔符。Excel 另存的 CSV 默认带 BOM有些平台解析器读到第一个字节就判定失败还有的表用分号做分隔符部分区域设置下 Excel 的默认行为解析器按逗号切切出来只有一列。解决办法是统一转成 UTF-8 无 BOM、逗号分隔再上传转换时顺手把列名里的空格和括号去掉很多平台的字段映射对特殊字符支持不好。现象二手机号、订单号变成科学计数法或者丢了前导零。原因在读取阶段表格软件和解析库都把这一列识别成了数值。解决办法是在读取时强制dtypestr写回时用utf-8-sig编码别用 Excel 直接打开再另存——那一步会把格式又改回去。如果数据已经在平台里了只能重新导入界面上的格式设置改不回来。现象三Excel 导进去少了几百行。这种情况要先查三处隐藏行不会因为隐藏被跳过但筛选状态下另存可能只保存可见行合并单元格只有左上角有值整块区域被当成一行还有一种是表中间夹了空行读取器默认把它当作数据结束标志。解决方式是读取时显式指定sheet_name先打印行数和原始表格的末行号对比对不上就逐个 sheet 排查。5.2 生成与自动化环节现象四生成的内容通顺但很空全是“随着业务发展”“具有重要意义”这类句子。原因一般不是模型能力不够而是输入信息密度太低。要么提示里只给了主题没给素材要么把整篇没有结构的原始文本直接丢进去。解决办法是把关键事实、数字、结论先提取成几条要点再喂进去并在约束里明确“不得出现原文没有的数字”“每个结论必须对应一条依据”。我一般在生成后加一道人工抽检随机挑 5 条对照原文错误率超过两成就要回头改 prompt而不是继续批量跑。现象五任务保存成功但状态一直是未执行。自动化任务这块最常见的坑是参数填了但没保存生效或者触发条件写成了永远不会满足的组合比如“每天 9 点执行”配上“仅工作日且数据更新后触发”而数据源本身是月度更新的。排查顺序是先看任务详情里的下次执行时间没有这个字段说明触发器根本没挂上再看依赖的上游数据源是否可达很多任务失败是卡在数据拉取而不是任务配置。平台界面上如果只显示“已保存”不显示“已调度”基本可以确定是触发器的问题。现象六开了“优化模式”之后结果反而更慢或者更偏。这类开关在不同场景下效果差异很大它本质上是平台预设的一组参数组合不一定适配你的任务类型。做抽取、摘要这类要求稳定的活我一般不勾宁可手动把温度和输出长度固定住做发散型创意任务再打开试。判断标准很简单同一个 prompt 跑三遍结果一致性明显下降就说明当前配置不适合这类任务。6. 进阶用法批量任务、自定义模板和训练后的三个校验数跑到一定量级之后效率提升主要来自两件事把重复动作模板化以及把结果校验流程化。批量处理这块我的做法是先把单条流程跑通、抽检通过再抽 20 条做小批确认输出格式稳定后才放开全量。自定义模板别一上来就做大而全的先固定三样东西固定的输入字段名、固定的提示骨架、固定的输出列后面加字段只是往里填。模板一旦稳定下来同样的活从两小时压到二十分钟很正常。模型训练与部署这一环训练完成不等于能用。我每次都强制看三个数验证集和训练集的指标差距差太多就是过拟合、混淆矩阵里占比最大的误判类别决定上线后最先出问题的地方、以及部署后首周的线上样本与训练样本的分布偏差。前两个在训练结果页就有第三个需要自己抽样对比。血泪经验是本地指标漂亮、上线第一天就崩九成是分布偏差训练数据来自历史某个时段线上流量早就变了。# 上线首周的分布校验类别字段的取值占比是否漂移 train_share train_df[channel].value_counts(normalizeTrue) online_share online_df[channel].value_counts(normalizeTrue) drift (online_share - train_share).abs().sort_values(ascendingFalse) print(drift.head(5)) # 偏差最大的前 5 个类目优先排查偏差超过 10 个百分点的类目就要考虑补样本或者加规则兜底。从那以后我每次上线模型前都会先把这三张表打印出来贴在需求单上缺一张就不签上线。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助?
咨询建站