记不清是从哪一批时序数据开始的了我发现自己一直在盯着那些“先往下走一段、再爬回来”的曲线发呆。水位、流量、价格、传感器读数——几乎所有连续采集的序列里这种形态都反复出现一段下降、一个低点、一段回升。你要是想把这件“眼熟”的事交给程序处理很快会撞上一个尴尬通用工具只给你“局部最小值”可局部最小值是纯点的概念它不管左右两边符不符合“下降后回升”的整体结构。我于是写了“山谷数”——一个专门把序列里的山谷形态识别出来、并量化成起始点、谷底、回升点、深度和宽度的工具。这篇文章就是“山谷数”在2025-2-21版本上的完整复盘怎么定义谷、怎么判定谷、怎么把误判一个个堵住以及最后它变成了一个能批量处理序列的实用件。适合正在做时序数据分析、做形态识别、或者只是被一堆“拐点”搞到头大的朋友参考。1. 为什么专门做“山谷数”从一堆局部最小值说起1.1 一个被算法忽略的“段”的问题我最早做这件事的起因非常朴素。某次帮某团队整理连续水位数据他们想知道历史上出现过几次“明显的下降再回升”每次大概持续多久、落差多大。这种需求如果用人眼去看图熟练的人一天可以扫几条长序列但如果要处理几百条基本就是给自己找罪受。当时我拿现成脚本跑了一下用常见的局部最小值检测逻辑去抓“低点”结果惨不忍睹。算法确实找到了一堆局部最低的位置但里面混了大量毛刺某天偶发的读数抖动、连续小雨导致的阶梯式下降、甚至仅仅因为序列末尾没有回升就戛然而止的部分。这些都不是“山谷”。问题就出在“局部最小值”只回答了一个问题这一点是不是比邻居低它完全没有回答用户真正关心的问题这一点是不是一段结构性下降的终点、后面是不是跟着明显的反弹。我需要的东西不是一个点检测器而是一个“段检测器”——把连续序列切成“下降段、谷底段、上升段”并且对“谷”的形态给出明确约束。这就是“山谷数”最初的定位不再回答“哪里有低点”而是回答“哪里有完整的谷”。2025-2-21版本已经是这个项目的第三轮迭代它的核心目标被我压缩成一句话把一串数字变成一组带名称的形态对象。1.2 现成拐点检测和波形分析工具为什么不好用有人可能问市面上不是有现成的拐点检测算法吗比如一阶差分、二阶导数符号变化、或者一些学术里的极值提取方法。我也试过逐个说说问题。一阶差分找拐点思路是计算相邻两个点的差值符号从负变正的位置记为拐点。这个方法实现很简单但它在噪声面前毫无抵抗力。实际序列里符号频繁反转你会得到海量候选点筛选时不得不上各种滤波而滤波窗口一旦过大真实的、小幅度的谷又会整个消失。二阶导数符号变化的方法类似对参数更敏感。学术一些的工具包也有比如形态学识别、小波变换这类方法效果确实更好但对大多数做业务数据分析的人来说有两个门槛一是参数理论太深不懂信号处理的人根本不知道怎么设二是很多工具包返回的是推断出的“趋势分量”并不直接给你“谷底在哪、深度多少、宽度多长”这种业务人员听得懂的结果。我用了几次就放弃了。所以“山谷数”从一开始没有往通用信号处理的方向靠而是站在业务侧定义问题用户说“明显的谷”背后隐含的是“深度够、宽度够、左右坡的角度够”——这三个条件几乎能覆盖绝大多数日常分析需求而且逻辑极其朴素调参也不需要信号处理背景。1.3 2025-2-21版本与前期版本的差别这个日期版本是项目的第三个发布期和前两版相比改动集中在三块第一是加入了坡度校验。早期版本只看谷底左右两侧是否单调下降和上升结果经常把一条几乎水平的缓坡也算成谷。举个例子一个序列从100慢慢降到99、98.5、98.2然后再慢悠悠回到100深度只有1.8宽度却有20个点这种形态在业务上根本不叫“谷”只能叫“一次缓慢的波动”。坡度校验就是专门用来过滤这种情况的。第二是加入了重叠合并策略。真实数据里经常出现“W型”走势两个谷之间隔得很近。早期版本会傻乎乎地把它们算成两个谷可人眼一看这明明是同一个“大谷里面有个小反弹”。新版本加入了合并逻辑把相邻过近、深度差距过大的候选谷合并成一个更大的结构。第三是重写了输出结构。之前版本返回的是“谷底点索引”使用者拿到之后还得自己去算左右边界2025-2-21版本直接返回结构化字典包含完整的谷对象起始点索引、谷底点索引、回升点索引、深度、宽度、左右坡度。看起来只是输出更友好但做批处理和后续可视化时省了非常多事。2. 从“一个点”到“一段结构”山谷的判定逻辑2.1 三步走先平滑再找候选谷底最后扩展和校验整个识别流程可以拆成三步顺序很重要乱了就翻车。第一步是平滑。我用的不是复杂滤波而是最朴素的移动平均窗口默认设为3个点。你可能会问三个点的窗口有什么用它的作用不是去掉所有噪声而是去掉那些“单点毛刺”——就是前后都正常、唯独中间一个值异常偏低的孤立点。这类毛刺如果不处理下一步找候选谷底时一定命中然后还得花额外的力气去排除不如在源头先压一压。第二步是找候选谷底点。规则很简单一点的值同时小于或等于前一个点和后一个点就记为候选谷底。这里的“小于或等于”里那个等号很重要因为真实数据里常常出现连续三个点数值完全相同的情况如果不允许等号这个平坦的小段就会被漏掉。第三步是扩展左右边界并计算结构参数。从候选谷底出发往左走只要前一个点的值还小于当前点就继续向左扩张直到遇到序列开始、遇到一个比前前一个点更大的点、或遇到一个已经被标记的上升趋势为止右侧同理。左右边界确定后深度和宽度就能算出来了。2.2 山谷成立的三条件深度、宽度、坡度光有左右边界还不行那个“一眼假”的候选会被三个条件拦住。首先是深度条件。深度我用的是“左右边界中较高的一侧与谷底值之差”。为什么不取较低的一侧而取较高的一侧因为如果某一侧的上升没有完全回到原来的水平用较高侧更接近人眼观察到的“这一坑到底有多深”。实际项目中深度阈值我用的是相对值depth_threshold 整体序列的极差 × depth_ratiodepth_ratio默认0.08也就是整个序列最高和最低之差的8%。这个定义天然适应不同量纲的序列不需要每个序列手调绝对数值。其次是宽度条件。宽度定义为谷底索引 - 起始索引回升索引 - 谷底索引也就是左右两段长度之和。默认最小宽度是5个采样点。这个条件的意义在于挡住“一转身就回升”的微型毛刺深度够深但宽度太窄往往是突变噪声而不是结构性的谷。最后是坡度条件2025-2-21版本新增的关键。坡度用左右两侧的平均变化率来算左侧平均坡度 谷底值 - 左侧边界值/ 左侧距离右侧同理取两侧中的较大值作为这个谷的坡度值且要求两侧各自不小于一个下限默认是slope_min 0.3%相对整体极差的比例。这直接解决了早期版本把缓慢波动识别成谷的问题。2.3 一个完整示例的演算过程拿一个简单序列来走一遍流程[12, 15, 14, 10, 8, 9, 13, 18, 16]极差是18-810深度阈值0.8最小宽度5坡度下限3%。平滑后序列不变三点窗口对这个序列没影响。扫描后候选谷底点有两个索引2值14比15和10都高不行排除——不对重算。逐点检查索引0是起点不参与候选判断。索引1值15大于索引0的12不是谷底。索引2值14比15小、比10大不是谷底。索引3值10比前面的14小比后面的8大不是谷底。索引4值8小于索引3的10也小于索引5的9是候选谷底。索引5值9比8大不是。后续点依次都不是。所以这一步只留下一格候选点索引4值8。扩展左边界从索引4向左索引3的值10大于索引4的值8继续索引2的值14大于索引3的值10继续索引1的值15大于索引2的值14继续索引0的值12小于索引1的值15停。所以左边界停在索引0左侧距离4。扩展右边界从索引4向右索引5的值9大于8继续索引6的值13大于9继续索引7的值18大于13继续索引8的值16小于索引7的18停。右边界停在索引7右侧距离3。计算结构参数左侧深度12-84右侧深度18-810按较高侧取深度为10宽度437大于5左侧坡度((15-8)/4 (12-8)/4)/2之类的简化就不细算了实际我按边界值到谷底的差值除以距离再结合极差判定本例明显超过3%。三个条件全部通过判定为一个完整的山谷起始点索引0、谷底索引4、回升点索引7、深度10、宽度7。如果序列尾部再加一个16后面的8比如[..., 16, 8]索引8这个点又低于两侧会再出一个候选但按边界扩展规则它大概率会和前面这个谷的一部分重叠这时候就轮到第三节要讲的合并逻辑上场了。2.4 参数默认值怎么定才合理参数设计是这类工具最容易翻车的地方。我的原则很简单默认值要覆盖70%的常见业务序列剩下的靠配置文件调。直接上参数表参数默认值作用典型调节范围smooth_window3预平滑窗口1~7噪声大就调大depth_ratio0.08深度阈值占极差的比重0.03~0.2min_width5最小谷宽度采样点数3~20slope_min0.003坡度下限相对极差比例0.001~0.01merge_gap5相邻候选谷最小间隔2~10这里depth_ratio是最敏感的参数太小则毛刺全进来太大则只留特大结构。我个人调试时的经验是先用0.08跑一遍看看结果里哪些是不想要的“假谷”再按比例上下微调一般两三次就能找到合适的值。smooth_window不要一开始就调大因为移动平均会拉平真实谷底导致深度被低估。3. 2025-2-21版本的实现技术选择与核心代码3.1 为什么只用Python加三个基础库技术选型上这个版本没有任何花哨的东西Python 3.11、pandas做数据读取和基础清洗、numpy做数值运算、matplotlib做可视化。不用更重的框架因为这类序列形态识别本质上就是数组扫描引入重量级依赖只会拖慢开发和调试速度。数据处理管道也简单读CSV、解析时间列和数值列、清洗缺失值然后进识别核心。如果你的数据存在数据库里完全可以在读取阶段直接从库里查出来再喂给程序核心逻辑不需要做任何改动。3.2 核心函数的划分和接口设计三个核心函数是best_smoothing预平滑、find_candidate_valleys找候选谷底、expand_valley扩展成完整山谷结构外加一个merge_valleys负责合并。每个函数只做一件事注册到主流程里之后无论是测试还是加功能都很清晰。下面给出核心识别段的参考实现代码做了简化以突出主流程import numpy as np def smooth_series(data, window3): kernel np.ones(window) / window padded np.pad(data, window // 2, modeedge) return np.convolve(padded, kernel, modevalid) def find_candidates(smoothed): candidates [] for i in range(1, len(smoothed) - 1): if smoothed[i] smoothed[i - 1] and smoothed[i] smoothed[i 1]: candidates.append(i) return candidates def expand_valley(smoothed, candidate, min_width, depth_threshold): left candidate while left 0 and smoothed[left - 1] smoothed[left]: left - 1 right candidate while right len(smoothed) - 1 and smoothed[right 1] smoothed[right]: right 1 left_edge smoothed[left] right_edge smoothed[right] valley_depth min(left_edge, right_edge) - smoothed[candidate] total_width (candidate - left) (right - candidate) if valley_depth depth_threshold and total_width min_width: return { left: left, valley: candidate, right: right, depth: valley_depth, width: total_width } return None注意这里depth_threshold我实际用的是相对值代码里传入的是一个已经算好的绝对阈值。深度定义在代码里用了min(left_edge, right_edge)这和你前面讲的“取较高侧差值”不同——这里取的是“左侧和右侧中较低的那个边界”也就是确保谷的深度是两侧都不低于基准线的如果你希望采用“高侧差值”的口径把min改成max即可。两种口径各有适用场景关键是一致性。merge_valleys的合并逻辑遍历按谷底位置排序的山谷如果两个山谷的谷底间隔小于merge_gap且其深度差不超过较大者的一半就保留深度更大的那个山谷但把左右边界扩展到覆盖两者覆盖的范围。这个策略会把W型结构合并成一个“大谷”避免过度切分。3.3 参数配置的工程化处理我不建议把参数硬编码在函数里。实际项目里序列可能来自几十个不同来源每个来源的特性都不一样有的是水位数据量级几百有的是流量数据量级几万。用一个配置文件统一管理最省心。我采用的是JSON配置结构大概这样{ depth_ratio: 0.08, min_width: 5, slope_min: 0.003, smooth_window: 3, merge_gap: 5, use_relative_threshold: true }主程序启动时加载配置转成参数字典传入识别核心。如果发现某条序列的结果不理想单独复制一条配置覆盖即可不需要改动代码。这个设计在批量处理多种来源数据时省了极多力气。3.4 输出设计直接把结果画在图上光有数值输出不够人和数据的交互终究靠眼睛。2025-2-21版本我做了一个简单的可视化函数背景画原始序列线谷底位置画一个圆点左边界和右边界分别用虚线竖线标出每个山谷上方标注深度值。这样一张图出来业务人员根本不需要理解算法细节扫一眼就知道识别得对不对。这也是我认为这个工具比纯算法脚本更“好用”的关键让结果可解释、可校验、可挑错。4. 实测和排坑哪些“假谷”骗过了第一版算法4.1 四组测试数据的设计为了验证算法的稳定性我准备四组形态完全不同的序列覆盖最常见的情况组别形态特征预期山谷数A干净周期波山谷规则3B带随机噪声的周期波3~4C长而缓的波浪式下降回升1DW型双谷中间只隔几个点1组A用来验功能正确组B验抗噪能力组C专治“缓坡误判”组D验合并策略。结果第一版算法跑下来A组完美B组多出来2个毛刺谷C组全线崩溃D组输出两个谷。后来一步步加参数、调逻辑才逐步收敛到预期结果。这个调试过程特别有代表性下面挑三个典型的翻车现场细说。4.2 翻车案例一长缓坡被当成山谷怎么治C组数据大概长这样从80开始经过60个点缓慢降到72再经过60个点缓慢升回78。深度只有8宽度却有120个点。第一版算法看到“下降、谷底、回升”都成立宽度深度也够就直接返回一个山谷——从业务视角看完全不对因为这种长期缓慢波动更多反映的是数据的长期趋势偏移而不是一个独立“事件”。修复方式就是我前面提到的坡度校验计算左右两侧的平均变化率用极差归一化低于下限值的谷直接丢弃。加上这个条件后C组被正确过滤这种“形态存在但强度不够”的情况不再误判。这里也暴露了一个更深的问题形态识别的“谷”和业务语义上的“谷”并不总是等价算法只能从形态特征逼近业务语义必要时必须加业务侧规则。4.3 翻车案例二W型双谷合并D组的数据类似这样30、20、10、25、12、26、40中间25那个反弹形成了两个谷。第一版算法返回两个谷一个深度20一个深度14。但人眼一扫就知道这应该是一个“大谷里有个小反弹”整体一个谷就够了。合并逻辑上线后先按谷底间隔过滤两个谷底索引相距才3个点小于merge_gap5再判断深度14 20的一半不符合沟壑明显大小差的情况——等等这里我实际项目中用的条件是“若深度差较大者的一半仍小于较小者深度则合并”也就是说两者相差不算悬殊时合并最后得到一个大谷谷底取原较深者位置左右边界取联合边界深度记20宽度重算。结果是1个谷符合人眼预期。4.4 翻车案例三毛刺噪声全靠预平滑也不行B组数据加了随机噪声幅度大约是整体波动的1%频率很高。第一版和平滑处理跑下来多了两个毛刺谷它们的深度只有整体极差的4%左右但局部看已经超过深度阈值。前面提到阈值是全局的但这个毛刺并不在全局极差范围内所以逃过了一劫——因为全局极差很大毛刺的绝对深度远小于0.08×全局极差。真正的问题出在另一个方向某些序列本身波动范围很小毛刺的绝对深度占全局极差的比例却很高。修复方式有两个漏斗一是预平滑加大到5个点窗口压掉高频毛刺二是在候选谷底校验里加一条“左右窗口内包含的原始点不能超过平滑后单点毛刺判定的上限”。实际项目里最简单有效的做法还是先全局跑一遍把所有被识别出的浅谷手动过一遍看它们是不是都对应真实形态如果是噪声产生的再把depth_ratio往上调10%~20%通常就能干净很多。4.5 性能表现十万个点的序列要跑多久顺手报一组性能数据作为参考用一台很普通的笔记本测试随机生成长度分别为1万、5万、10万的数值序列各跑10次取平均序列长度平均耗时10,0000.06秒50,0000.31秒100,0000.63秒瓶颈几乎全在Python的for循环上。如果后续要处理百万级以上的数据有两个方向一是用numpy向量化改造找候选和扩展部分二是在Python里调用一个C扩展。日常分析场景里十万点内目前这个实现完全够用。5. 工程化的几个细节可视化、报告和批量处理5.1 可视化怎么做才不踩坑画识别结果时容易犯的错是把所有数据点和标记点都画上去结果整张图密密麻麻。最后我只能这样定方案原始序列用细线加低透明度谷底用醒目的圆点左右边界用竖线。这样每个谷从视觉上就是“一条虚线起点、一个圆点谷底、一条虚线终点”一眼能看见结构。颜色选择上谷底统一用深色圆点边界虚线用灰色不要每个谷用不同颜色——同一张图上谷多了会变成彩虹反而看不清楚。需要区分山谷重要性时可以用圆点大小表示深度比颜色区分更自然。5.2 自动生成结果报告配合可视化程序还会输出一个汇总表编号、起始时间、谷底时间、回升时间、深度、宽度、左右坡度。这个表可以直接复制到Excel或者写入数据库也可以作为进一步分析的输入。import pandas as pd def build_report(valleys, timestamps): rows [] for idx, v in enumerate(valleys): rows.append({ valley_id: idx 1, start: timestamps[v[left]], valley_time: timestamps[v[valley]], end: timestamps[v[right]], depth: v[depth], width: v[width], }) return pd.DataFrame(rows)报告的核心作用不是展示识别本身而是把人从“看图挑谷”中解放出来。拿到这张表后你可以直接统计平均深度、最深谷、频次分布等衍生指标整个分析链条一下就顺了。5.3 批量处理多序列时的注意点实际项目中很少只跑一条序列通常是几十条一起处理。批量时会遇到两个隐藏问题。第一个是不同序列量纲差异。如果都按全局极差的8%设阈值量纲大的序列的“相对8%”的量值和量纲小的序列完全不同这会直接导致一部分序列几乎识别不出谷、另一部分却全是谷。解决方案很简单批量处理时按序列分别计算极差不要把多序列拼成一个整体算阈值。第二个是首尾边界问题。如果序列开头是一段下跌、但结尾没有回升这种“半截谷”到底算不算我目前的默认策略是舍弃开头或结尾不完整的候选谷只保留左右边界都在序列范围内的“完整谷”。理由是不完整结构无法计算可信的宽度和坡度强行保留会污染后续统计。5.4 一个必须提醒的误用场景千万别把这个工具的识别结果直接当成交信号或者风险预警——这类判定逻辑本身不含任何因果信息它只能回答“有没有出现一种形态”不能回答“这种形态预示了什么”。我见过有新手拿到一批价格序列检测出谷就当成买入点结果遇到持续阴跌的序列阳谷和阴沟都被识别成“谷”自然怎么用怎么错。所有形态识别工具都只能在后续显著性分析、人工校验配合下发挥作用。6. 后续可以怎么玩从识别到更通用的形态工具6.1 把“山谷”扩展到“山峰”既然有了“下降后回升”的谷结构那“上升后下降”的山峰结构就是同一个逻辑的镜像。把比较符号全部反转再加一个slope_min的符号翻转就能在同一套框架下识别山峰。实际项目中很多场景需要同时看谷和峰比如判断一个周期内高低点分布。改造成本约半小时收益却很大。6.2 交互式参数调节器当前版本跑完一张图后如果参数不理想需要手动改JSON再重跑不够顺手。我计划下一步做一个简单的交互式工具一个窗口展示序列曲线几个滑块控制depth_ratio、min_width、slope_min每动一个滑块图中标记实时刷新。这样调参会变成一件很直观的事而且非常有利于和业务方对齐“什么样的谷才叫谷”的标准。6.3 把山谷特征喂给下游机器学习如果序列分析不只停留在“看一眼”而是要进一步预测趋势那么把这些形态特征——谷数、平均深度、平均宽度、最大深度、谷的频次——作为特征工程的一部分通常比直接用原始序列做模型稳定。原因是这些特征本身就是高层次的抽象能减少模型对噪声的拟合。我自己在后续实验里把“山谷特征”加入预测模型的特征向量之后在几个模拟测试场景里的稳定性确实有明显提升大家可以作为参考。6.4 三条实际体验总结迭代到2025-2-21版本我最大的一个体会是写形态识别算法80%的工作不在算法本身而在处理“人眼一秒钟能判断、代码却要绕十万八千里”的边界情况。缓坡、毛刺、W型、半截谷——每修好一个工具就稳一分。如果你也想做类似的东西我的建议很简单先从最小的定义开始只抓“深度和宽度”两个条件跑通跑通后再拿三组真实数据去虐它把暴露出来的问题一个个修掉最后再考虑合并、可视化和批处理。别一上来就追求大而全形态识别这种东西贪多必失。序列还在不断进来“山谷数”这个版本之后下一件让我觉得有趣的事是让工具自己判断“这个谷对后续趋势有没有影响”。到今天的这版为止它已经能从一串数字里找出结构了已经是件挺有成就感的事。
记不清是从哪一批时序数据开始的了我发现自己一直在盯着那些“先往下走一段、再爬回来”的曲线发呆。水位、流量、价格、传感器读数——几乎所有连续采集的序列里这种形态都反复出现一段下降、一个低点、一段回升。你要是想把这件“眼熟”的事交给程序处理很快会撞上一个尴尬通用工具只给你“局部最小值”可局部最小值是纯点的概念它不管左右两边符不符合“下降后回升”的整体结构。我于是写了“山谷数”——一个专门把序列里的山谷形态识别出来、并量化成起始点、谷底、回升点、深度和宽度的工具。这篇文章就是“山谷数”在2025-2-21版本上的完整复盘怎么定义谷、怎么判定谷、怎么把误判一个个堵住以及最后它变成了一个能批量处理序列的实用件。适合正在做时序数据分析、做形态识别、或者只是被一堆“拐点”搞到头大的朋友参考。1. 为什么专门做“山谷数”从一堆局部最小值说起1.1 一个被算法忽略的“段”的问题我最早做这件事的起因非常朴素。某次帮某团队整理连续水位数据他们想知道历史上出现过几次“明显的下降再回升”每次大概持续多久、落差多大。这种需求如果用人眼去看图熟练的人一天可以扫几条长序列但如果要处理几百条基本就是给自己找罪受。当时我拿现成脚本跑了一下用常见的局部最小值检测逻辑去抓“低点”结果惨不忍睹。算法确实找到了一堆局部最低的位置但里面混了大量毛刺某天偶发的读数抖动、连续小雨导致的阶梯式下降、甚至仅仅因为序列末尾没有回升就戛然而止的部分。这些都不是“山谷”。问题就出在“局部最小值”只回答了一个问题这一点是不是比邻居低它完全没有回答用户真正关心的问题这一点是不是一段结构性下降的终点、后面是不是跟着明显的反弹。我需要的东西不是一个点检测器而是一个“段检测器”——把连续序列切成“下降段、谷底段、上升段”并且对“谷”的形态给出明确约束。这就是“山谷数”最初的定位不再回答“哪里有低点”而是回答“哪里有完整的谷”。2025-2-21版本已经是这个项目的第三轮迭代它的核心目标被我压缩成一句话把一串数字变成一组带名称的形态对象。1.2 现成拐点检测和波形分析工具为什么不好用有人可能问市面上不是有现成的拐点检测算法吗比如一阶差分、二阶导数符号变化、或者一些学术里的极值提取方法。我也试过逐个说说问题。一阶差分找拐点思路是计算相邻两个点的差值符号从负变正的位置记为拐点。这个方法实现很简单但它在噪声面前毫无抵抗力。实际序列里符号频繁反转你会得到海量候选点筛选时不得不上各种滤波而滤波窗口一旦过大真实的、小幅度的谷又会整个消失。二阶导数符号变化的方法类似对参数更敏感。学术一些的工具包也有比如形态学识别、小波变换这类方法效果确实更好但对大多数做业务数据分析的人来说有两个门槛一是参数理论太深不懂信号处理的人根本不知道怎么设二是很多工具包返回的是推断出的“趋势分量”并不直接给你“谷底在哪、深度多少、宽度多长”这种业务人员听得懂的结果。我用了几次就放弃了。所以“山谷数”从一开始没有往通用信号处理的方向靠而是站在业务侧定义问题用户说“明显的谷”背后隐含的是“深度够、宽度够、左右坡的角度够”——这三个条件几乎能覆盖绝大多数日常分析需求而且逻辑极其朴素调参也不需要信号处理背景。1.3 2025-2-21版本与前期版本的差别这个日期版本是项目的第三个发布期和前两版相比改动集中在三块第一是加入了坡度校验。早期版本只看谷底左右两侧是否单调下降和上升结果经常把一条几乎水平的缓坡也算成谷。举个例子一个序列从100慢慢降到99、98.5、98.2然后再慢悠悠回到100深度只有1.8宽度却有20个点这种形态在业务上根本不叫“谷”只能叫“一次缓慢的波动”。坡度校验就是专门用来过滤这种情况的。第二是加入了重叠合并策略。真实数据里经常出现“W型”走势两个谷之间隔得很近。早期版本会傻乎乎地把它们算成两个谷可人眼一看这明明是同一个“大谷里面有个小反弹”。新版本加入了合并逻辑把相邻过近、深度差距过大的候选谷合并成一个更大的结构。第三是重写了输出结构。之前版本返回的是“谷底点索引”使用者拿到之后还得自己去算左右边界2025-2-21版本直接返回结构化字典包含完整的谷对象起始点索引、谷底点索引、回升点索引、深度、宽度、左右坡度。看起来只是输出更友好但做批处理和后续可视化时省了非常多事。2. 从“一个点”到“一段结构”山谷的判定逻辑2.1 三步走先平滑再找候选谷底最后扩展和校验整个识别流程可以拆成三步顺序很重要乱了就翻车。第一步是平滑。我用的不是复杂滤波而是最朴素的移动平均窗口默认设为3个点。你可能会问三个点的窗口有什么用它的作用不是去掉所有噪声而是去掉那些“单点毛刺”——就是前后都正常、唯独中间一个值异常偏低的孤立点。这类毛刺如果不处理下一步找候选谷底时一定命中然后还得花额外的力气去排除不如在源头先压一压。第二步是找候选谷底点。规则很简单一点的值同时小于或等于前一个点和后一个点就记为候选谷底。这里的“小于或等于”里那个等号很重要因为真实数据里常常出现连续三个点数值完全相同的情况如果不允许等号这个平坦的小段就会被漏掉。第三步是扩展左右边界并计算结构参数。从候选谷底出发往左走只要前一个点的值还小于当前点就继续向左扩张直到遇到序列开始、遇到一个比前前一个点更大的点、或遇到一个已经被标记的上升趋势为止右侧同理。左右边界确定后深度和宽度就能算出来了。2.2 山谷成立的三条件深度、宽度、坡度光有左右边界还不行那个“一眼假”的候选会被三个条件拦住。首先是深度条件。深度我用的是“左右边界中较高的一侧与谷底值之差”。为什么不取较低的一侧而取较高的一侧因为如果某一侧的上升没有完全回到原来的水平用较高侧更接近人眼观察到的“这一坑到底有多深”。实际项目中深度阈值我用的是相对值depth_threshold 整体序列的极差 × depth_ratiodepth_ratio默认0.08也就是整个序列最高和最低之差的8%。这个定义天然适应不同量纲的序列不需要每个序列手调绝对数值。其次是宽度条件。宽度定义为谷底索引 - 起始索引回升索引 - 谷底索引也就是左右两段长度之和。默认最小宽度是5个采样点。这个条件的意义在于挡住“一转身就回升”的微型毛刺深度够深但宽度太窄往往是突变噪声而不是结构性的谷。最后是坡度条件2025-2-21版本新增的关键。坡度用左右两侧的平均变化率来算左侧平均坡度 谷底值 - 左侧边界值/ 左侧距离右侧同理取两侧中的较大值作为这个谷的坡度值且要求两侧各自不小于一个下限默认是slope_min 0.3%相对整体极差的比例。这直接解决了早期版本把缓慢波动识别成谷的问题。2.3 一个完整示例的演算过程拿一个简单序列来走一遍流程[12, 15, 14, 10, 8, 9, 13, 18, 16]极差是18-810深度阈值0.8最小宽度5坡度下限3%。平滑后序列不变三点窗口对这个序列没影响。扫描后候选谷底点有两个索引2值14比15和10都高不行排除——不对重算。逐点检查索引0是起点不参与候选判断。索引1值15大于索引0的12不是谷底。索引2值14比15小、比10大不是谷底。索引3值10比前面的14小比后面的8大不是谷底。索引4值8小于索引3的10也小于索引5的9是候选谷底。索引5值9比8大不是。后续点依次都不是。所以这一步只留下一格候选点索引4值8。扩展左边界从索引4向左索引3的值10大于索引4的值8继续索引2的值14大于索引3的值10继续索引1的值15大于索引2的值14继续索引0的值12小于索引1的值15停。所以左边界停在索引0左侧距离4。扩展右边界从索引4向右索引5的值9大于8继续索引6的值13大于9继续索引7的值18大于13继续索引8的值16小于索引7的18停。右边界停在索引7右侧距离3。计算结构参数左侧深度12-84右侧深度18-810按较高侧取深度为10宽度437大于5左侧坡度((15-8)/4 (12-8)/4)/2之类的简化就不细算了实际我按边界值到谷底的差值除以距离再结合极差判定本例明显超过3%。三个条件全部通过判定为一个完整的山谷起始点索引0、谷底索引4、回升点索引7、深度10、宽度7。如果序列尾部再加一个16后面的8比如[..., 16, 8]索引8这个点又低于两侧会再出一个候选但按边界扩展规则它大概率会和前面这个谷的一部分重叠这时候就轮到第三节要讲的合并逻辑上场了。2.4 参数默认值怎么定才合理参数设计是这类工具最容易翻车的地方。我的原则很简单默认值要覆盖70%的常见业务序列剩下的靠配置文件调。直接上参数表参数默认值作用典型调节范围smooth_window3预平滑窗口1~7噪声大就调大depth_ratio0.08深度阈值占极差的比重0.03~0.2min_width5最小谷宽度采样点数3~20slope_min0.003坡度下限相对极差比例0.001~0.01merge_gap5相邻候选谷最小间隔2~10这里depth_ratio是最敏感的参数太小则毛刺全进来太大则只留特大结构。我个人调试时的经验是先用0.08跑一遍看看结果里哪些是不想要的“假谷”再按比例上下微调一般两三次就能找到合适的值。smooth_window不要一开始就调大因为移动平均会拉平真实谷底导致深度被低估。3. 2025-2-21版本的实现技术选择与核心代码3.1 为什么只用Python加三个基础库技术选型上这个版本没有任何花哨的东西Python 3.11、pandas做数据读取和基础清洗、numpy做数值运算、matplotlib做可视化。不用更重的框架因为这类序列形态识别本质上就是数组扫描引入重量级依赖只会拖慢开发和调试速度。数据处理管道也简单读CSV、解析时间列和数值列、清洗缺失值然后进识别核心。如果你的数据存在数据库里完全可以在读取阶段直接从库里查出来再喂给程序核心逻辑不需要做任何改动。3.2 核心函数的划分和接口设计三个核心函数是best_smoothing预平滑、find_candidate_valleys找候选谷底、expand_valley扩展成完整山谷结构外加一个merge_valleys负责合并。每个函数只做一件事注册到主流程里之后无论是测试还是加功能都很清晰。下面给出核心识别段的参考实现代码做了简化以突出主流程import numpy as np def smooth_series(data, window3): kernel np.ones(window) / window padded np.pad(data, window // 2, modeedge) return np.convolve(padded, kernel, modevalid) def find_candidates(smoothed): candidates [] for i in range(1, len(smoothed) - 1): if smoothed[i] smoothed[i - 1] and smoothed[i] smoothed[i 1]: candidates.append(i) return candidates def expand_valley(smoothed, candidate, min_width, depth_threshold): left candidate while left 0 and smoothed[left - 1] smoothed[left]: left - 1 right candidate while right len(smoothed) - 1 and smoothed[right 1] smoothed[right]: right 1 left_edge smoothed[left] right_edge smoothed[right] valley_depth min(left_edge, right_edge) - smoothed[candidate] total_width (candidate - left) (right - candidate) if valley_depth depth_threshold and total_width min_width: return { left: left, valley: candidate, right: right, depth: valley_depth, width: total_width } return None注意这里depth_threshold我实际用的是相对值代码里传入的是一个已经算好的绝对阈值。深度定义在代码里用了min(left_edge, right_edge)这和你前面讲的“取较高侧差值”不同——这里取的是“左侧和右侧中较低的那个边界”也就是确保谷的深度是两侧都不低于基准线的如果你希望采用“高侧差值”的口径把min改成max即可。两种口径各有适用场景关键是一致性。merge_valleys的合并逻辑遍历按谷底位置排序的山谷如果两个山谷的谷底间隔小于merge_gap且其深度差不超过较大者的一半就保留深度更大的那个山谷但把左右边界扩展到覆盖两者覆盖的范围。这个策略会把W型结构合并成一个“大谷”避免过度切分。3.3 参数配置的工程化处理我不建议把参数硬编码在函数里。实际项目里序列可能来自几十个不同来源每个来源的特性都不一样有的是水位数据量级几百有的是流量数据量级几万。用一个配置文件统一管理最省心。我采用的是JSON配置结构大概这样{ depth_ratio: 0.08, min_width: 5, slope_min: 0.003, smooth_window: 3, merge_gap: 5, use_relative_threshold: true }主程序启动时加载配置转成参数字典传入识别核心。如果发现某条序列的结果不理想单独复制一条配置覆盖即可不需要改动代码。这个设计在批量处理多种来源数据时省了极多力气。3.4 输出设计直接把结果画在图上光有数值输出不够人和数据的交互终究靠眼睛。2025-2-21版本我做了一个简单的可视化函数背景画原始序列线谷底位置画一个圆点左边界和右边界分别用虚线竖线标出每个山谷上方标注深度值。这样一张图出来业务人员根本不需要理解算法细节扫一眼就知道识别得对不对。这也是我认为这个工具比纯算法脚本更“好用”的关键让结果可解释、可校验、可挑错。4. 实测和排坑哪些“假谷”骗过了第一版算法4.1 四组测试数据的设计为了验证算法的稳定性我准备四组形态完全不同的序列覆盖最常见的情况组别形态特征预期山谷数A干净周期波山谷规则3B带随机噪声的周期波3~4C长而缓的波浪式下降回升1DW型双谷中间只隔几个点1组A用来验功能正确组B验抗噪能力组C专治“缓坡误判”组D验合并策略。结果第一版算法跑下来A组完美B组多出来2个毛刺谷C组全线崩溃D组输出两个谷。后来一步步加参数、调逻辑才逐步收敛到预期结果。这个调试过程特别有代表性下面挑三个典型的翻车现场细说。4.2 翻车案例一长缓坡被当成山谷怎么治C组数据大概长这样从80开始经过60个点缓慢降到72再经过60个点缓慢升回78。深度只有8宽度却有120个点。第一版算法看到“下降、谷底、回升”都成立宽度深度也够就直接返回一个山谷——从业务视角看完全不对因为这种长期缓慢波动更多反映的是数据的长期趋势偏移而不是一个独立“事件”。修复方式就是我前面提到的坡度校验计算左右两侧的平均变化率用极差归一化低于下限值的谷直接丢弃。加上这个条件后C组被正确过滤这种“形态存在但强度不够”的情况不再误判。这里也暴露了一个更深的问题形态识别的“谷”和业务语义上的“谷”并不总是等价算法只能从形态特征逼近业务语义必要时必须加业务侧规则。4.3 翻车案例二W型双谷合并D组的数据类似这样30、20、10、25、12、26、40中间25那个反弹形成了两个谷。第一版算法返回两个谷一个深度20一个深度14。但人眼一扫就知道这应该是一个“大谷里有个小反弹”整体一个谷就够了。合并逻辑上线后先按谷底间隔过滤两个谷底索引相距才3个点小于merge_gap5再判断深度14 20的一半不符合沟壑明显大小差的情况——等等这里我实际项目中用的条件是“若深度差较大者的一半仍小于较小者深度则合并”也就是说两者相差不算悬殊时合并最后得到一个大谷谷底取原较深者位置左右边界取联合边界深度记20宽度重算。结果是1个谷符合人眼预期。4.4 翻车案例三毛刺噪声全靠预平滑也不行B组数据加了随机噪声幅度大约是整体波动的1%频率很高。第一版和平滑处理跑下来多了两个毛刺谷它们的深度只有整体极差的4%左右但局部看已经超过深度阈值。前面提到阈值是全局的但这个毛刺并不在全局极差范围内所以逃过了一劫——因为全局极差很大毛刺的绝对深度远小于0.08×全局极差。真正的问题出在另一个方向某些序列本身波动范围很小毛刺的绝对深度占全局极差的比例却很高。修复方式有两个漏斗一是预平滑加大到5个点窗口压掉高频毛刺二是在候选谷底校验里加一条“左右窗口内包含的原始点不能超过平滑后单点毛刺判定的上限”。实际项目里最简单有效的做法还是先全局跑一遍把所有被识别出的浅谷手动过一遍看它们是不是都对应真实形态如果是噪声产生的再把depth_ratio往上调10%~20%通常就能干净很多。4.5 性能表现十万个点的序列要跑多久顺手报一组性能数据作为参考用一台很普通的笔记本测试随机生成长度分别为1万、5万、10万的数值序列各跑10次取平均序列长度平均耗时10,0000.06秒50,0000.31秒100,0000.63秒瓶颈几乎全在Python的for循环上。如果后续要处理百万级以上的数据有两个方向一是用numpy向量化改造找候选和扩展部分二是在Python里调用一个C扩展。日常分析场景里十万点内目前这个实现完全够用。5. 工程化的几个细节可视化、报告和批量处理5.1 可视化怎么做才不踩坑画识别结果时容易犯的错是把所有数据点和标记点都画上去结果整张图密密麻麻。最后我只能这样定方案原始序列用细线加低透明度谷底用醒目的圆点左右边界用竖线。这样每个谷从视觉上就是“一条虚线起点、一个圆点谷底、一条虚线终点”一眼能看见结构。颜色选择上谷底统一用深色圆点边界虚线用灰色不要每个谷用不同颜色——同一张图上谷多了会变成彩虹反而看不清楚。需要区分山谷重要性时可以用圆点大小表示深度比颜色区分更自然。5.2 自动生成结果报告配合可视化程序还会输出一个汇总表编号、起始时间、谷底时间、回升时间、深度、宽度、左右坡度。这个表可以直接复制到Excel或者写入数据库也可以作为进一步分析的输入。import pandas as pd def build_report(valleys, timestamps): rows [] for idx, v in enumerate(valleys): rows.append({ valley_id: idx 1, start: timestamps[v[left]], valley_time: timestamps[v[valley]], end: timestamps[v[right]], depth: v[depth], width: v[width], }) return pd.DataFrame(rows)报告的核心作用不是展示识别本身而是把人从“看图挑谷”中解放出来。拿到这张表后你可以直接统计平均深度、最深谷、频次分布等衍生指标整个分析链条一下就顺了。5.3 批量处理多序列时的注意点实际项目中很少只跑一条序列通常是几十条一起处理。批量时会遇到两个隐藏问题。第一个是不同序列量纲差异。如果都按全局极差的8%设阈值量纲大的序列的“相对8%”的量值和量纲小的序列完全不同这会直接导致一部分序列几乎识别不出谷、另一部分却全是谷。解决方案很简单批量处理时按序列分别计算极差不要把多序列拼成一个整体算阈值。第二个是首尾边界问题。如果序列开头是一段下跌、但结尾没有回升这种“半截谷”到底算不算我目前的默认策略是舍弃开头或结尾不完整的候选谷只保留左右边界都在序列范围内的“完整谷”。理由是不完整结构无法计算可信的宽度和坡度强行保留会污染后续统计。5.4 一个必须提醒的误用场景千万别把这个工具的识别结果直接当成交信号或者风险预警——这类判定逻辑本身不含任何因果信息它只能回答“有没有出现一种形态”不能回答“这种形态预示了什么”。我见过有新手拿到一批价格序列检测出谷就当成买入点结果遇到持续阴跌的序列阳谷和阴沟都被识别成“谷”自然怎么用怎么错。所有形态识别工具都只能在后续显著性分析、人工校验配合下发挥作用。6. 后续可以怎么玩从识别到更通用的形态工具6.1 把“山谷”扩展到“山峰”既然有了“下降后回升”的谷结构那“上升后下降”的山峰结构就是同一个逻辑的镜像。把比较符号全部反转再加一个slope_min的符号翻转就能在同一套框架下识别山峰。实际项目中很多场景需要同时看谷和峰比如判断一个周期内高低点分布。改造成本约半小时收益却很大。6.2 交互式参数调节器当前版本跑完一张图后如果参数不理想需要手动改JSON再重跑不够顺手。我计划下一步做一个简单的交互式工具一个窗口展示序列曲线几个滑块控制depth_ratio、min_width、slope_min每动一个滑块图中标记实时刷新。这样调参会变成一件很直观的事而且非常有利于和业务方对齐“什么样的谷才叫谷”的标准。6.3 把山谷特征喂给下游机器学习如果序列分析不只停留在“看一眼”而是要进一步预测趋势那么把这些形态特征——谷数、平均深度、平均宽度、最大深度、谷的频次——作为特征工程的一部分通常比直接用原始序列做模型稳定。原因是这些特征本身就是高层次的抽象能减少模型对噪声的拟合。我自己在后续实验里把“山谷特征”加入预测模型的特征向量之后在几个模拟测试场景里的稳定性确实有明显提升大家可以作为参考。6.4 三条实际体验总结迭代到2025-2-21版本我最大的一个体会是写形态识别算法80%的工作不在算法本身而在处理“人眼一秒钟能判断、代码却要绕十万八千里”的边界情况。缓坡、毛刺、W型、半截谷——每修好一个工具就稳一分。如果你也想做类似的东西我的建议很简单先从最小的定义开始只抓“深度和宽度”两个条件跑通跑通后再拿三组真实数据去虐它把暴露出来的问题一个个修掉最后再考虑合并、可视化和批处理。别一上来就追求大而全形态识别这种东西贪多必失。序列还在不断进来“山谷数”这个版本之后下一件让我觉得有趣的事是让工具自己判断“这个谷对后续趋势有没有影响”。到今天的这版为止它已经能从一串数字里找出结构了已经是件挺有成就感的事。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
