尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
配电网韧性提升:移动储能MPS预配置与两阶段鲁棒优化
前阵子做配电网韧性方向的复现被“应急移动电源预配置”这个题目卡了小半个月。这类工作在电力系统SCI一区期刊里很常见核心思路并不晦涩——极端灾害来临前把移动储能车、应急发电车这类Mobile Power Source提前放到关键节点等故障真正发生后就能快速顶上。但真正动手用Matlab把数学模型敲出来、跑通、调稳定中间全是细节。这篇是这个复现系列的上篇聚焦MPS预配置问题在不确定故障场景下如何决策初始布点。下篇再展开故障后的动态调度与多时段协同。如果你正在做配电网韧性、应急资源优化配置或者只是想把两阶段鲁棒优化落地成代码这篇的经验应该能帮你省下不少折腾时间。1. 问题定位为何韧性提升需要“预配置”视角1.1 韧性与可靠性的本质区别先说清楚“韧性”和“可靠性”到底差在哪。很多刚接触这个方向的人会把它们混在一起但实际上两者的研究对象完全不同。可靠性关注的是长期运行中的平均表现常用指标是系统平均停电频率指标SAIFI和系统平均停电持续时间指标SAIDI考察的是“一年下来用户停了几次电、停了多久”。韧性关注的是极端事件下的表现比如台风、冰灾、地震这类低概率高影响的场景考察的是系统从受灾到恢复的全过程事件发生前能不能提前准备事件冲击中能不能维持关键负荷事件后能不能快速恢复。我复现时画过一张对比表看完基本就能理解两者的研究范式差异维度可靠性韧性关注事件常见故障单点、概率高极端事件多点、概率低、破坏大核心指标SAIFI、SAIDI、EENS失负荷量、恢复时间、韧性曲线下面积决策视角长期规划、常态运行灾前预置、灾中响应、灾后恢复时间尺度全年统计小时级/分钟级应急过程这个区别直接决定了建模方式。可靠性分析通常用概率期望来评估比如N-1校验韧性分析面对的是“最坏情况”更像一个博弈问题——大自然决定哪里断线我们决定如何应对。因此两阶段鲁棒优化天然契合这个场景第一阶段是灾前的“无悔决策”第二阶段是看到具体故障场景后的“最优响应”。1.2 MPS在配电网应急中的角色MPS指的是可以在不同位置之间移动的应急电源包括移动储能车、移动柴油发电车、UPS电源车等。它的价值在于“机动性”平时不需要在每个节点都建固定电源灾害发生后可以把电源资源集中投放到最需要的地方。相比固定式储能或备用发电机MPS的成本更低、使用更灵活但决策也更复杂——因为电源在移动过程中存在时间延迟而且预配置位置的选择直接影响灾后的响应速度。一个典型的工程场景是这样气象部门预测某区域将遭受台风袭击但无法精确预测哪几条馈线会断。这时运维部门有几台移动储能车可供调度必须在台风登陆前决定把它们停靠在哪些节点。如果放在负荷重但线路容易受损的末端可能线路一断MPS所在的节点也跟着失联资源就困死在原地如果放在靠近变电站的主干节点又可能离实际断电区域太远灾后无法及时供电。所以预配置问题的本质是在不确定条件下做位置决策既要考虑候选点的负荷重要性又要考虑灾后网络拓扑的连通性。1.3 上篇与下篇的边界划分我在复现时把整体工作切成两块上篇做预配置下篇做动态调度。严格说这两者在真实系统里是耦合成一个整体决策的但拆开来研究更容易逐层深入。预配置灾前决定MPS的初始位置属于第一阶段的“here-and-now”决策目标是让最坏场景下的失负荷最小。动态调度灾后基于实际故障信息决定每台MPS何时移动到哪个位置、以多大功率放电属于第二阶段的“wait-and-see”决策。上篇文章只讨论预配置意味着我们假设故障发生后MPS就在预配置节点接入并向本地负荷供电不再考虑跨节点移动。这个假设在数学上让第二阶段问题变成线性规划方便用列与约束生成算法求解。移动和时序调度的问题留到下篇专门处理那部分需要引入时间轴和多时段耦合约束复杂度会上一个台阶。2. 数学模型MPS预配置的两阶段鲁棒框架2.1 网络建模DistFlow线性化配电网和输电网的潮流约束不太一样配电网通常是放射状结构用DistFlow方程更合适。完整的DistFlow包含线路损耗项是非线性约束求解效率低。在实际复现中很多论文采用忽略网损的线性化DistFlow模型在12.66kV中压配电网场景下精度足够。线性化潮流约束可以写成节点功率平衡和电压降落关系。对每个节点 j有功功率满足注入功率加上游支路流入功率等于负荷功率与下游支路流出功率之和电压关系近似为上游节点电压的平方减去2倍的电阻乘有功加电抗乘无功。这个模型把原本非凸的潮流问题变成了线性约束可以嵌进大规模优化模型。这里有个很关键的实操点如果直接用电压幅值做变量约束是非线性的用电压平方做变量线性化后就得到一个标准的二阶锥或线性问题。我在代码里用变量V2(i)表示节点 i 的电压平方约束范围设为0.95^2 V2 1.05^2既满足精度要求又避免非线性求解的麻烦。2.2 MPS的物理约束与预配置决策MPS的建模要抓住三个核心要素数量、容量、位置。数量方面工程上可用MPS总数有限比如3台或5台这直接转化为约束sum(x) K其中x(i)是0-1变量表示节点 i 是否预置MPS。容量方面每台MPS有额定功率P_mps和额定能量E_mps功率代表瞬间能带多大负荷能量代表能撑多久。如果应急支撑时段长度为T则能量约束可简化为功率乘以时间小于等于容量p_mps * T E_mps。候选位置的选择也很有讲究。我在IEEE 33节点系统上做测试时并不是所有33个节点都适合放置MPS。优先候选点是三类一是负荷较大的节点MPS就近供电利用率最高二是连接重要用户的节点权重系数更高三是联络开关附近的节点故障后容易通过重构恢复供电。如果对33个节点全放开0-1变量求解规模会变大但预配置的实际意义反而被稀释。2.3 极端事件不确定集设计两阶段鲁棒优化的核心之一是不确定集的设计。配电网韧性研究中极端事件通常表现为多条线路同时断线。我把不确定变量定义为z(e)取1表示线路 e 故障取0表示正常运行。最简单的不确定集是预算约束形式sum(z) Gamma其中Gamma是预期最多同时断开的线路数。比如Gamma 3表示最坏情况下有3条线路同时损坏。这个不确定集的物理含义是极端事件造成多点故障但故障数量有限。Gamma的大小直接影响预配置方案的保守程度——Gamma越大系统要应对的场景越恶劣预置的MPS就越倾向于往更关键的位置放置。除了预算约束还可以加入线路间的相关性约束比如同一馈线上的多条线路同时故障概率更高。为了保持模型的线性结构大多数复现工作只用预算约束加连通性约束我复现时也遵循这个做法。2.4 完整的两阶段鲁棒模型综合上面各要素MPS预配置问题的两阶段鲁棒模型可以写成如下形式第一阶段决策是预配置方案x(i)目标是最小化预配置成本与最坏场景失负荷之和。第二阶段给定故障场景z决策变量包括节点负荷削减量l(i)、MPS出力p_mps(i)、各支路潮流和节点电压。约束条件分为几组第一组是预配置数量限制第二组是MPS接入约束如果节点没有预置MPS则该节点MPS出力为0第三组是故障场景下的配电网运行约束包括线性化DistFlow潮流方程、节点电压上下限、支路容量限制第四组是失负荷约束每个节点的削减量不能超过该节点负荷。目标函数里失负荷项带有权重系数w(i)重要节点的削减代价更高。第二阶段内部是一个完整的最优潮流问题给定故障场景后可以求解得到该场景下的最小失负荷。而我们需要找的是不确定集内导致最大失负荷的最坏场景于是整个问题成为一个max-min结构。这种结构正是列与约束生成算法的用武之地。2.5 列与约束生成算法的迭代逻辑CG算法的思路并不复杂它的关键是把“无穷多个场景”替换成“迭代生成的有限个场景”。主问题求解预配置决策只考虑已生成的故障场景集合子问题在给定预配置方案下寻找最坏故障场景把新找到的场景作为约束加入主问题。两个问题交替求解直到上下界收敛。迭代流程可以概括为四步第一步初始化上下界分别设为正负无穷选取一个初始故障场景通常是无故障场景或全故障场景第二步求解主问题得到预配置方案和当前下界第三步将预配置方案代入子问题求解最坏故障场景得到当前上界第四步判断上下界差是否小于容忍阈值如果满足就停止否则把最坏场景对应的约束加入主问题并返回第二步。这里我特别想说一个细节CG要求子问题的内层是线性规划否则强对偶不成立就无法把max-min问题转化为单层的max问题。上篇我们把预配置后的MPS视为就地接入第二阶段变量全是连续的正好满足这个条件。如果第二阶段还包含移动决策等0-1变量子问题就变成MILP需要更复杂的嵌套式CG处理这也是下篇要重点解决的问题之一。3. Matlab实现从零搭建可复现代码3.1 环境与工具链准备先交代我的复现环境Matlab R2021a版本、Yalmip优化建模工具箱、Gurobi求解器。Yalmip的建模语法比直接调Gurobi的Java接口友好太多尤其是处理0-1变量和稀疏约束时写起来非常顺手。下载Yalmip后把它加入Matlab路径然后在命令行运行yalmiptest验证求解器是否被正常识别。求解器方面MILP和LP我统一用Gurobi因为它的并发MIP求解器在配电网这类中等规模问题上表现很稳。CPLEX也可以但Gurobi的许可证管理更省心。如果你的机器上只有CPLEX代码里的求解器参数改一行就行模型本身不需要动。还有一个建议新建脚本时把数据和模型分开数据部分写在一个脚本里模型部分写在另一个函数里。这样后续做敏感性分析时只改数据文件不用动模型逻辑。我就是用这种方式跑Gamma灵敏度分析的效率提升很明显。3.2 IEEE 33节点算例数据准备IEEE 33节点系统是配电网研究最常用的测试算例之一基准电压12.66kV总共33个节点、37条支路其中5条是联络开关支路原本断开故障后可闭合。总负荷大约3.7MW加2.3MVar。这个规模对于复现预配置问题刚好合适——节点数足够看出布点差异又不至于大到你调试代码时等到怀疑人生。数据准备阶段我把线路阻抗、节点负荷、拓扑连接关系分别存成三个矩阵。% 节点负荷数据有功 MWload_node [节点编号, 有功负荷] load_node [ 1 0.0 2 0.1 3 0.09 ... 33 0.06 ]; % 支路数据 [首端, 末端, 电阻(ohm), 电抗(ohm)] branch [ 1 2 0.0922 0.0470 2 3 0.4930 0.2511 ... ]; % 联络开关支路故障后可闭合重构 tie_switch [8 21; 9 15; 12 22; 18 33; 25 29];需要注意潮流约束里的阻抗要换算成标幺值。我用的基准容量是10MVA基准电压12.66kV阻抗标幺值等于实际欧姆值乘以基准容量除以基准电压的平方。换算完数值都在0.001到0.1数量级求解器处理起来很舒服。如果直接用欧姆值建模约束矩阵的条件数会很差迭代过程中容易出现数值抖动。3.3 主问题核心代码主问题需要决策预配置位置并对已经生成的所有故障场景计算失负荷之和。下面是我实现的主问题骨架为了方便理解省略了完整潮流约束只保留关键结构。x binvar(N,1); % 节点i是否预置MPS eta sdpvar(1); % 最坏场景失负荷指标 Constraints []; % MPS数量限制 Constraints [Constraints, sum(x) K]; % 对每一个已生成的故障场景加入约束 for t 1:length(generated_scenarios) z_t generated_scenarios{t}; % 当前场景的故障支路集合 l_t sdpvar(N,1); % 该场景的负荷削减量 p_mps_t sdpvar(N,1); % 该场景的MPS出力 V2_t sdpvar(N,1); % 节点电压平方 Pij_t sdpvar(E,1); % 支路有功 Qij_t sdpvar(E,1); % 支路无功 % 失负荷目标约束该场景失负荷不超过eta Constraints [Constraints, sum(w .* l_t) eta]; % MPS出力约束没有预置MPS的节点出力为0 Constraints [Constraints, p_mps_t P_mps * x]; % 节点功率平衡、电压约束、支路约束... % 详细约束见函数 build_scenario_constraints() Constraints [Constraints, build_scenario_constraints(...)]; end objective sum(C_place .* x) eta; ops sdpsettings(solver, gurobi, verbose, 0); optimize(Constraints, objective, ops);主问题的本质是把子问题返回的场景当成确定性场景逐个建模用共享变量eta把各个场景的失负荷联系起来。eta在目标函数里的系数就是1但引入它之后目标函数变成线性同时保证最坏场景信息被纳入。场景约束函数里最重要的几个公式是节点功率平衡P_ij 流入 负荷 - 削减 - MPS出力故障支路功率强制为0P_ij M * (1 - z_e)其中M是足够大的常数电压范围约束和MPS功率上限。这些约束加齐以后子问题返回的最坏场景会被“翻译”成主问题的一组线性不等式。3.4 子问题核心代码与枚举验证子问题的目标是在给定预配置方案x*的条件下找到使失负荷最大的故障场景。按照CG理论这个max-min问题通过强对偶转换为单层max问题。但实际操作中如果Gamma不大我建议先写一个朴素的枚举版子问题来做交叉验证——把所有可能的故障场景列出来每个场景求解一次第二阶段的LP记录最坏的那个。这样做有两个好处一是验证CG实现是否正确二是帮你理解子问题的物理含义。枚举版代码逻辑很简单% 枚举版子问题给定x*在所有Gamma故障场景中找最坏场景 worst_obj -inf; worst_z []; all_combs nchoosek(1:E, Gamma); for idx 1:size(all_combs, 1) z_t zeros(E,1); z_t(all_combs(idx,:)) 1; obj_t solve_second_stage(x_star, z_t); % 求解确定性场景LP if obj_t worst_obj worst_obj obj_t; worst_z z_t; end end当E37、Gamma3时组合数是C(37,3)7770个每个场景是一个小规模LP总耗时在几十秒量级完全可以接受。这个枚举版本的价值不在于实用而在于给你一把“标尺”——CG求出的最坏场景目标值必须和枚举结果一致否则算法实现一定有问题。CG版子问题通过引入对偶变量把max-min转化成单层max得到的是最坏场景的解析表达式不用枚举所有组合迭代几次就能收敛。这段代码稍微复杂核心是处理故障变量z(e)与对偶变量的乘积项。处理手法是引入大M常数线性化如果z(e)1则相关对偶变量为0否则自由。初学者在这里最容易出错后面排查笔记会细说。3.5 CG主循环与结果输出主循环就是把主问题和子问题串起来维护上下界并生成新场景LB -inf; UB inf; k 0; gap inf; generated_scenarios {zeros(E,1)}; % 初始用无故障场景 while gap tol k max_iter k k 1; % 1. 求解主问题 optimize(Constraints, obj, ops); x_star value(x); LB max(LB, value(obj)); % 2. 给定x_star求解子问题 [worst_obj, z_worst] solve_subproblem(x_star); UB min(UB, value(worst_obj)); gap abs(UB - LB) / abs(UB); fprintf(迭代%d: LB%.4f, UB%.4f, gap%.4f\n, k, LB, UB, gap); % 3. 将最坏场景加入主问题 generated_scenarios{end1} z_worst; end这里有个容易忽略的细节主问题的下界用value(obj)更新子问题的上界用最坏场景的目标值更新。之所以LB取max而UB取min是因为主问题只考虑了有限场景低估了真实最坏情况子问题在给定预配置方案下求出的目标值对任意可行预配置方案都是上界。迭代到gap小于阈值时得到的预配置方案就是鲁棒最优解。4. 实验效果与关键结果分析4.1 基准方案设计模型跑通后不能只看一个结果就下结论必须设计对照实验。我的对照组设置了四个方案方案描述A无预配置故障后只能削减负荷B随机选取K个节点放置MPSC贪心策略选负荷量最大的K个节点D本文鲁棒预配置模型四个方案在相同的Gamma值下测试用最坏场景失负荷总量做评价指标。方案A本质上是零资源情况是最恶劣的下限方案B用来检验随机布点的效果波动方案C代表工程中常用的经验做法方案D是我们的优化结果。4.2 预配置结果分析在IEEE 33节点系统、K3、Gamma3的参数下我复现得到的一组典型结果如下方案预配置节点最坏场景失负荷MW相比方案A的改善A无2.86-B随机2.12~2.4714%~26%C最大负荷节点18,25,331.8934%D优化得到节点13,24,301.5247%这组结果很能说明问题。贪心方案选的是负荷绝对值最大的节点但预配置的效果不只取决于节点负荷还取决于节点在网络拓扑中的“关键性”。优化方案选出的节点通常兼顾了负荷重要性和灾后连通性比如节点13靠近联络开关支路故障后可以通过重构给更大范围供电。这个差异是预配置模型价值的最直观体现。4.3 收敛性与灵敏度分析CG求解过程中我记录了下界和上界的变化。比较典型的表现是第一次迭代后上下界差距较大第二次迭代加入最坏场景后gap迅速缩小到5%以内第三次迭代基本收敛到1%以内。这表明CG在预配置问题上的收敛速度非常理想实用性强。灵敏度分析方面Gamma从1增加到5最坏场景失负荷量逐步上升优化的预配置方案也发生变化。Gamma较小时优化方案倾向于把MPS集中在少数几个高负荷节点Gamma较大时方案会转向更多分散布点以应对更广泛的线路故障。这种趋势说明了“保守度”和“经济性”之间的权衡——Gamma越大系统的应急准备越充分但预配置可能牺牲部分资源利用效率。5. 实操中最容易踩的坑与排查笔记5.1 子问题不是标准LP对偶假设失效这是我在复现过程中遇到的第一个大坑。一开始我把第二阶段问题加了0-1移动变量进去然后用CG去求解结果上下界始终不收敛甚至主问题目标值大于子问题目标值出现“下界超过上界”的荒谬情况。排查后发现问题出在子问题是MILP而不是LP强对偶不成立把max-min转化为max问题这个过程本身就是错的。如果你的研究场景也必须包含0-1变量有两个出路一是把0-1移动决策放到第一阶段通过扩大第一阶段决策维度来回避二是采用嵌套式CG也就是在子问题内部再跑一层CG。前者在预配置问题里是合理的后者复杂度高建议不到万不得已不要自己硬撸先复现一个纯LP子问题的版本把流程跑通。5.2 数值病态别拿欧姆值直接建模模型的数值稳定性直接决定Gurobi求解效率和正确性。我刚开始用实际欧姆值和MW值建模跑小场景没什么问题一旦Gamma变大、场景变多求解时间飙升甚至出现约束违反警告。后来统一改成标幺值带入数值量级集中在0.01到1之间同样的模型求解速度提升了近一个数量级。大M常数也要克制。M太大会导致线性松弛过松MIP的分支定界效率极差M太小又会切掉可行解。我的做法是逐个约束分析M的物理上限支路潮流M取所有线路容量之和再加一点裕度节点功率平衡的M取最大负荷的2倍。宁可每个约束单独设不同的M也绝不用一个统一的超级大M。5.3 CG迭代慢与初始化技巧CG算法在主问题初始场景为空或只有一个平凡场景时第一次迭代的割往往质量不高。我的经验是迭代前先运行一个快速启发式方案比如把贪心解作为初始预配置方案加入主问题能显著减少前几次迭代的振荡。另外把主问题里的MIP相对间隙从默认的1e-4放宽到1e-3在预配置阶段能进一步提速对最终布点结果几乎无影响。如果连续跑多次实验Gurobi的Warm Start也可以利用起来。在Yalmip里求解后把x的赋值结果打回初始解optimize时可以传入sdpsettings(usex0,1)这样在敏感性分析中能节省大量重复求解时间。5.4 排查问题速查表现象可能原因排查与解决下界大于上界子问题含0-1变量对偶失效检查子问题是否为纯LP移动决策移至第一阶段求解器报数值警告变量量级差异过大全部换算标幺值精细化大M常数多次迭代gap不降主问题缺少有效场景约束检查割生成是否正确对比枚举版目标值预配置结果全部集中在一个节点MPS容量约束未生效检查p_mps P_mps * x是否完整表达无故障场景下最优也削减负荷潮流约束写错或M值过小单场景调试fix根节点电压为1.0再验证功率平衡6. 一个卡了我很久的细节分享最后分享一个在调试中卡了很久、代码写完回头看又特别简单的细节。预配置模型里无预置MPS的节点第二阶段MPS出力必须为0和所有MPS总出力不超过K倍单台容量这两个约束看似等价实际差很远。前者是逐节点约束p_mps(i) P_mps * x(i)后者只是总量约束。我一开始只写了总量约束结果优化器把功率集中分配到一个未预置节点物理上完全不可能实现但模型目标值显示“很优”。有时候论文里的模型公式和实际可计算代码之间隔着大量这种容易被忽略的映射关系。每一个数学约束都要问自己它是否准确地施加到了正确的变量组合上有没有被另一个表面相似的约束替代导致物理意义变了把这个问题想清楚复现工作就成功了大半。下篇我会继续写动态调度部分包括MPS在故障后的移动路径决策、多时段时间耦合约束以及嵌套式CG的实现。到时候再结合具体代码展开。这里先把预配置这块的模型、代码、调试经验都记录下来有正在做相关方向的朋友欢迎一起交流实际运行中遇到的问题。
RELATED

相关推荐

图表设计实战指南:从信息梳理到视觉编码的完整方法论

图表设计实战指南:从信息梳理到视觉编码的完整方法论

1. 从“diagram-design”这个标题里能读出什么第一次看到“diagram-design”这个标题,我脑子里蹦出来的不是某个具体工具,而是一类非常典型的工作场景:有人需要把脑子里那团乱麻一样的逻辑,变成一张别人一眼能看懂的图。这件事听起…

📅 2026/10/21 9:27:51
创意工作者必备:素材管理与项目归档体系搭建指南

创意工作者必备:素材管理与项目归档体系搭建指南

1. 为什么我一直在折腾"artcraft"这件事先说清楚,"artcraft"不是某个官方产品,也不是什么特定软件的名字。这个词拆开就是 art 加上 craft,艺术与工艺的组合。我最早接触这个概念,是在整理一批手工艺作品素材…

📅 2026/10/21 9:27:51
RuoYi-Cloud微服务分离版启动避坑指南:Nacos配置与网关路由排查

RuoYi-Cloud微服务分离版启动避坑指南:Nacos配置与网关路由排查

1. 为什么微服务分离版值得单独写一篇启动避坑指南若依(RuoYi)这个开源快速开发框架,国内做企业级管理系统的开发者应该都不陌生。单体版(RuoYi-Vue)和微服务版(RuoYi-Cloud)是两条主线&#xf…

📅 2026/10/21 9:27:51
MORE NEWS

更多资讯

📰

直流电动机开环调速系统Simulink仿真全解析:从原理到实践

简介:这是一份围绕直流电动机开环调速系统仿真展开的课程设计论文,面向自动化、电气工程等专业学生,以及需要借助Simulink验证调速理论的工程技术人员。内容从直流调速系统的技术背景与基本原理入手,详细介绍了三相晶闸管整流电路…

📰

多通道数据分时传送系统设计:Verilog与Multisim仿真实现

简介:这是一份面向电子/通信类专业课程设计的完整文档,主题是多通道数据分时传送系统的设计,适合正在学习数字逻辑、通信原理或Verilog HDL的在校生参考。文档按课程设计要求逐步展开:先说明并行数据分离重组的背景与设计目标&…

📰

二进制文件对比与编辑:十六进制编辑器核心功能与实操避坑指南

直接处理二进制文件这件事,很多接触过的人第一反应是“用十六进制打开看一眼”,但真正需要频繁对比、定位、修改BIN/HEX文件时,才会发现普通文本编辑器根本扛不住——要么文件太大打开就卡死,要么看不到真实字节内容,要…

📰

危化品仓储检测报告AI审核:IACheck规则引擎与模型协同实践

1. 背景与价值:检测报告审核为何需要智能化 做危化品仓储这一行的人,应该都有过同样的体验:每个月甚至每周都要面对厚厚一沓环境检测报告,气体浓度、温湿度、防爆电气状态、通风系统运行数据,密密麻麻的表格和参数&…

📰

开源代码审查系统open-code-review:从规则引擎到CI门禁的工程实践

1. 项目整体设计与核心思路拆解作为一个在研发一线待了十多年、经历过无数次"代码审查全靠吼、评审记录靠截图"的老兵,我太清楚代码审查这件事在团队里是什么状态了。早期我们团队做评审,基本就是拉个会议室,对着屏幕一顿讲&#x…

📰

低成本长视频理解新思路:智能导航先找关键片段

这两年做长视频理解的同行,应该都有同一个感受:短视频赛道的模型已经卷到天上,但一碰到长视频,大家又集体回到原始社会。要么把视频抽帧抽到地老天荒,要么把整段视频暴力塞进上下文,显卡当场冒烟。我自己做…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬