刚接手一个涉及位姿图优化的项目时，我最常听到的一句话是“Ceres不是现成的吗？直接调一下就行”。可真当自己把数据灌进去，迭代几十次还在原地打转，或者结果稳定但速度慢到没法上线的时候，才会意识到：Ceres Solver虽然把非线性最小二乘的骨架都搭好了，但“用起来”和“用得好”之间，隔着大量工程细节。这篇文章想分享我在几个实际项目里沉淀下来的Ceres优化技巧，覆盖建模、参数化、求解器配置、自动求导的取舍，以及一条完整的收敛失败排查思路。适合刚把Ceres跑通、正准备往项目里塞的开发者，也适合遇到性能瓶颈正在挠头的朋友。
1. 优化效果差的根源通常不在求解器，而在问题建模
先讲一个我踩过的典型坑。某视觉定位项目里，早期版本把相机位姿、地图点、IMU零偏全部扔进一个残差块，权重矩阵直接给单位阵，损失函数也没设——用的就是最朴素的平方损失。结果优化出来的轨迹在回环闭合处明显扭曲，部分地图点漂得离谱。一开始怀疑Ceres的参数没调好，后来逐项排查才发现，问题几乎都出在建模层。
1.1 信息矩阵和权重：优化器并不知道哪些观测“更可信”
Ceres最小化的是残差平方和，或者说带权重的平方和。如果你不显式设置信息矩阵，默认就是单位权重，意味着每条残差边对系统的贡献完全一样。这在传感器噪声尺度接近时问题不大，但视觉重投影误差、IMU预积分误差、轮式里程计误差的量纲和噪声特性完全不同。当视觉误差以“像素”为单位（通常几像素到几十像素），IMU预积分误差以“米/秒”或“弧度”为单位时，两类残差混在一起，数值上谁大谁就主导。
我当时的做法，是把每类残差的协方差矩阵拆出来，取逆作为信息权重。这一步在很多博客里只是一句带过，实际工程里却是整个优化质量的分水岭。一个可参考的做法是先做一次不带权重的优化，取残差统计方差作为初始协方差，再迭代一两次让权重趋于合理。
需要提醒的是，信息矩阵的绝对值大小本身意义不大，关键是相对比例。某个残差块的权重比其他块大一两个数量级，优化器就会优先“伺候”它。反过来，如果某个传感器噪声很大，你却给它定了过高权重，等于拿不可靠数据绑架整个优化。这属于Ceres使用里最容易被忽视、又最常见的问题之一。
1.2 损失函数的角色：鲁棒核不是装饰品，是必需品
第二个坑是完全没有使用鲁棒核函数。真实数据里，特征匹配经常混入错误匹配，激光匹配偶尔也会给错位姿增量。单纯的平方损失会让这些“离群残差”在平方放大之下反客为主——一个误差100像素的错误匹配，杀伤力相当于10个误差10像素的正确匹配。于是优化器为了讨好这个异常观测，把整个轨迹拉向错误方向。
Ceres里解决这个问题很简单，在AddResidualBlock时传入一个LossFunction实例，比如HuberLoss、CauchyLoss、SoftLOneLoss。以Huber为例，它在一定阈值内保持平方损失，超出阈值后切换为一范数增长，压制大残差的影响力。阈值通常设在残差尺度的1.0到3.0之间，具体要看你的残差单位。
实际项目里的进阶做法是两阶段优化：第一阶段使用较强鲁棒性的核函数（比如TukeyLoss）先把明显的离群数据压住，跑一轮迭代让整体状态进入合理邻域；第二阶段再改用二次损失（或很小的Huber阈值），把第一阶段过滤后的数据做精细调整。这样既能躲开离群点，又不会让鲁棒核的“温和”拖累最终精度。这个技巧在SLAM后端的位姿图优化里非常管用。
1.3 参数块数值量级：未归一化之前，别谈收敛速度
还有一个非常容易被忽略的建模问题：参数的数值量级差异过大。比如平移参数可以是几十米，而旋转参数用四元数表示时四个分量都在[-1, 1]之间。如果同时优化这两类参数，梯度方向会被平移项主导，旋转维度上的更新步长要么过小导致收敛极慢，要么过大直接越出有效区域。Ceres的trust region策略虽然会根据梯度动态调整步长，但极端量级差异仍会显著影响性能。
实践中一个很实用的做法，是把所有参数归一化到相近量级，或者在问题定义时使用参数化包装类，让优化器面向的“参数”天生处于合理数值范围内。比如把平移量先除以一个尺度因子（如场景包围盒半径），在残差计算里再乘回来。这样数值条件数好，迭代收敛速度快很多，很多所谓“Ceres不收敛”的疑难杂症，其实只是数值条件太差。
2. 旋转参数的建模方式：从直接优化四元数到局部参数化的跨越
接着要聊的是参数化问题，这也是Ceres优化技巧中最核心、最容易出问题的环节。刚接触Ceres时，我见过不少人把四元数当成四个普通标量直接丢进参数块，然后 Align 完上一层，把四元数归一化强制修正。这种方式也许能在小扰动下勉强工作，但本质上是有隐患的。
2.1 为什么四元数不能当普通向量优化
四元数用于表示三维旋转时，有一个约束条件：它的模长必须是1。如果把它当作普通四元数组来优化，梯度更新会破坏这个约束，导致“旋转”不再是一个合法旋转。每步更新后手动归一化，属于治标不治本：归一化相当于在优化空间中做额外的非线性投影，会破坏梯度方向的一致性，让优化路径变得曲折。而且四元数还存在“双重覆盖”的问题——q和-q表示同一个旋转，这会在某些优化场景中引起符号不连续。
Ceres提供的QuaternionParameterization（以及新版API里的QuaternionManifold）正是为了解决这个问题。它定义了一个4维空间中的3维子流形，并且提供了一个局部坐标映射：其核心思想是参数块的维度保持为4，但更新计算在3维切空间里完成，再将切空间更新通过指数映射/旋转合成到最新的4维状态上。用大白话说，优化器只对3个自由度的“增量”做决策，再把这个增量用合法的方式作用到四元数上，从而始终保持在单位球面附近。
2.2 局部参数化与雅可比矩阵的关系：为什么“绕过约束”如此重要
理解局部参数化的关键在于雅可比矩阵的计算。在Ceres里，残差块对参数块的导数默认是全导数，也就是把四元数的4个分量当独立变量来处理。但当你使用局部参数化后，Ceres会自动把残差对参数块的导数转换到切空间上，相当于告诉优化器“真正可以变化的只有3个方向”。这不仅仅是数学上更正确，工程上的收益非常直接：优化变量少了一个维度，线性求解器的规模变小，迭代更稳，收敛需要的步数也明显减少。
如果跟我一样是从手写高斯牛顿时代过来的开发者，可以把这个过程理解成在迭代更新之前做了一次“约束投影”，但Ceres把这件事从底层替你做好了。需要注意的坑是：自定义局部参数化的Plus和ComputeJacobian必须与你的残差雅可比推导一致。多数情况下用Ceres内置的旋转参数化就足够，但如果你在残差里同时对四元数做变换，需要确定你的四元数乘法约定（Hamilton vs JPL）和Ceres默认约定是否一致。这个细节不对，优化器虽然不报错，结果就是各种诡异。
2.3 SE3的建模：位姿作为整体该如何处理
对于包含位姿的SLAM场景，很多教程会把位姿表示成四元数+平移的double[7]，并在AddParameterBlock时对前4维设置四元数参数化。这个方案确实能用，但我后来更喜欢显式地定义一个新的参数块结构（比如用struct封装7个double数组），并且在残差构造时也按这个整体来处理。因为位姿图优化中，边连接的是两个位姿之间的相对变换，这个变换的计算天然需要“整体位姿”的概念；手动拆开容易写错顺序和符号。
这里还有一个衍生技巧：如果某个位姿已经有良好初值，甚至部分维度已经完全确定，可以用SetParameterBlockConstant固定整个参数块；如果只是某个维度需要固定，可以在自定义参数化里只开放需要的自由度。比如在平面机器人场景中，把位姿从SE3降维成SE2，优化变量直接从6自由度降到3自由度，速度和稳定性都有可见提升。
3. 求解器配置清单：线性求解器、预处理与迭代策略的工程经验
聊完建模和参数化，接下来是很多人最关心的部分：求解器配置。Ceres的Solver::Options有一大堆字段，默认配置跑小Demo很舒服，但一旦问题规模上来，不针对性地设置会立刻被打回原形。这部分我按工程里的实际决策顺序来讲，而不是按照文档字段顺序。
3.1 线性求解器的选择依据：小问题用稠密，大问题必须稀疏
Ceres把优化拆成外层 trust region 迭代和内层线性求解两步。内层求解器的选择直接影响每步迭代的时间和内存。我习惯根据“有效参数块数量”和“雅可比矩阵结构”来做决策：
- 参数块总量几百以内，残差块比较密集（比如一个小的图优化问题），用DENSE_QR通常是最稳的。
- 中等规模（几千个参数块），结构已经很稀疏，但还可以整体稠密化求解，DENSE_SCHUR是一个折中。它在视觉BA里表现不错的例子是中等规模的SFM。
- 真正大规模稀疏问题（几万到几百万参数块），SPARSE_SCHUR或SPARSE_NORMAL_CHOLESKY是主力。SPARSE_SCHUR对视觉BA特别友好，因为其Schur补结构天然消除了一部分变量。
- 如果内存紧张，或者矩阵规模大到分解起来困难，可以把SPARSE_NORMAL_CHOLESKY与迭代法（CG）配合，它能避免显式分解，但收敛速度和预处理器强相关。
我踩过的坑是：一个大概10万参数块的位姿图问题，默认用了DENSE_QR，结果每步迭代直接吃掉几十GB内存，根本没有迭代到第二步就进程挂了。换成SPARSE_SCHUR之后内存占用降到原来的零头，单步迭代时间反而更快。
3.2 预处理器：隐匿的性能阀门
如果选择了迭代线性求解器，预处理器就是最关键的一环。Ceres提供多种预处理器，包括JACOBI、IDENTITY、SCHUR_JACOBI、CLUSTER_TRIDIAGONAL和CLUSTER_JACOBI。这些名字听着唬人，实际作用就是给线性迭代器提供一个好的“加速起点”。我用过几个典型场景：
- 结构比较规则的BA问题，SCHUR_JACOBI往往比JACOBI更有效。
- 图优化中如果簇结构明显，CLUSTER_TRIDIAGONAL能大幅加速收敛。
- 当初次尝试不确定选哪个，我会先开JACOBI跑一组看看迭代次数，再换CLUSTER类对比迭代总数和时间，以实际数据下结论。文档里的理论性能分析可以做参考，但工程上跑一遍数据永远是最诚实的答案。
3.3 迭代策略的几个关键参数：怎么看日志，怎么停止
很多人会在Options里设置max_num_iterations，然后等它迭代完，再看最终cost。但实际调优时，建议把minimizer_progress_to_stdout设为true，Ceres会打印每步的cost、cost_change、梯度范数、trust region半径等信息。读这些日志比盯着最终结果更能发现问题。
我自己常用的健康检查顺序是：
- cost是否持续下降。如果某一步cost上升且tr_ratio为负，说明当前步没有接受，trust region在缩小；偶尔几次是正常的，但连续多次说明模型线性化质量差。
- gradient的范数是否数量级下降。如果迭代了30步，梯度范数还在初始值的量级徘徊，说明可能陷入某个区域的平台，参数化或鲁棒核的设置可能需要调整。
- 大部分步骤的迭代时间是否稳定。如果某一步突然慢很多，多半是线性求解器的分解遇到结构变化，要留意参数块数目是否在迭代中被动态改变。
迭代停止条件上，function_tolerance、gradient_tolerance和parameter_tolerance都要根据问题尺度设定。不要直接照抄某个博客的参数，例如在像素级视觉残差下把function_tolerance设为1e-12就是不合理的，噪声本身就有好几像素。
此外，use_nonmonotonic_steps在某些困难问题里很好用。它允许优化器偶尔接受cost上升的一步，以跳出局部极小。我在一个多模态配准项目里试过，默认单调策略跑几轮就卡住，打开非单调步之后反而一路下探到更优解。代价是终点附近可能细微震荡，通常用后期把该选项关掉再精调几步来弥补。
4. 自动求导的取舍：从调参效率到运行性能的平衡
Ceres支持三种残差求导方式：自动求导（AutoDiff）、数值求导（NumericDiff）和解析求导（自定义CostFunctor）。Ceres的自动求导非常强大，但对嵌套复杂检查的残差函数，又容易写出模板实例化极慢的代码。这节谈谈我在实战中怎么做取舍。
4.1 三种求导方式的适用场景
自动求导适合绝大多数情况，特别是你还在快速迭代算法时。只要CostFunctor里包含的运算足够“纯”（几乎全是数学操作，不要有分支和输出日志），Ceres会正确又高效地给出一阶导数。遇到对性能极为敏感的残差块，并且解析导数可以简单推导时，才建议手写解析求导。若干燥的数学推导容易出错，一定要先用GradientChecker做验证。
数值求导对我来说主要用于验证阶段——当某段手写雅可比怎么都调不收敛时，换成NumericDiff跑一遍，看问题是否消失；如果消失，几乎可以断定是雅可比写错了。这种用法比把它作为主力求导方式更合理。
4.2 CostFunctor的写法细节：为什么你的自动求导这么慢
很多人以为自动求导慢是Ceres的问题，其实多数时候是自己CostFunctor写得太重。有两个高频原因：
第一，残差函数内部包含了大量检查性代码、分支判断、甚至日志输出。这些代码在每次求解迭代中都会被反复执行，而且模板导致代码膨胀。解决办法是把超出残差计算的逻辑移到外部，残差函数保持又短又纯。
第二，把多个残差写成一个很大的残差块，试图减少残差块数量。比如把几十个约束点塞进一个残差，自动求导时Ceres需要对这个庞杂函数整体做链式求导，模板递归深度大，编译慢，运行时也慢。拆成多个独立残差块，让Ceres分别求导，实际上会更快。这个结论我当时也有点意外，但用性能剖析工具实测后确凿如此。
4.3 固定参数块与结构稀疏性带来的性能红利
问题规模大时，固定一部分参数块可以显著降低求解器负担。比如在由粗到精的优化策略里，第一步固定外参，只用结构分量优化；第二步固定结构分量，精调外参。这种策略不仅让每步迭代的变量变少，也降低陷入错误局部最优的概率。Ceres里用SetParameterBlockConstant非常简单，但工程里搭配它设计“分阶段优化”才是真正的技巧。
同样的道理适用于显式地利用结构稀疏性：Ceres的雅可比默认是压缩稀疏行格式，它会在第一次残差求值时自动探测雅可比稀疏模式。但如果你的参数块数量巨大，而每个残差只与少数参数块关联，在AddResidualBlock之前，可以预估并设置好结构。一个简单的经验是，避免让单个残差块关联过多不同的参数块，否则稀疏模式会迅速变稠密，后续所有线性代数操作都会变慢。
5. 一次收敛失败排查实录：梯度检查与迭代日志怎么读
讲到这里，可以串一遍完整的排障思路。有一个真实场景：某跨平台系统里做雷达与视觉联合标定时，Ceres迭代了一百多次仍在震荡，最终结果也不理想。排查过程非常值得复述一遍。
5.1 第一步：确认残差与雅可比的一致性
当时残差是手写的解析雅可比，所以我第一个怀疑对象就是雅可比公式出错。方法是Ceres里的GradientChecker。具体用法是构造一个Problem，把对应的残差块和梯度检查器绑上去，然后手动喂一组参数。它会数值化地比较你提供的解析雅可比与自动求导或数值差分结果。这一查就发现某一步链式求导时少乘了一个旋转矩阵。修正后梯度模长开始按预期下降，这验证了“先把求导搞对，再谈调参”的原则。
5.2 第二步：观测迭代日志中的“震荡”模式
修复雅可比之后，迭代虽然能下降，但仍然出现了周期性震荡。日志里能看到这样的模式：某几步cost迅速下降，但紧接着一步大幅反弹。这说明trust region在“收-扩”之间循环，常见原因是参数块中存在符号不连续或非光滑映射。在这个案例里，最终定位到标定板位姿初值的某个角度分量处于奇异点附近。把初值用解析方式重投影到平滑区域后，震荡立即消失。
如果日志呈现的是另一种模式——cost几乎不变，梯度却很小，那么很可能是数值量级问题，需要回看第一节提到的归一化。
5.3 第三步：信息权重与鲁棒核按层级补上
修完数值层面的问题后，结果已经能收敛，但精度还差一点。此时再检查各残差块的信息权重，发现一个传感器观测的信息矩阵比实际噪声大了约一个数量级。拿前一次迭代的残差算一个噪声方差，重新标定信息矩阵后，整体精度才有了实质提升。同时给匹配类残差补上了Huber核，再把第一阶段离群点筛除后换回二次损失精调。经过这三步，最终结果既稳又准，单次优化耗时还比之前少了一半。
5.4 留下一个“性能基线脚本”
最后分享一个工作习惯：每次调整Ceres配置时，我都会留一个独立的小型数据集和基线脚本，固定评估指标（比如在验证集上的平均重投影误差、优化耗时、内存峰值）。这样后续每次改参数化、换线性求解器，都能快速跑一遍对比，不用靠记忆判断是变好还是变坏。很多“优化技巧”不是玄学调参，而是通过可控实验得出的数据结论。
Ceres Solver的灵活性很大，它把优化骨架搭好，但每个环节如何配置、如何根据数据调整，都需要扎实的工程判断。我实践下来的核心体会是：先在建模层把权重、核函数、参数化设计正确，再去调求解器参数，最后用日志和基线数据验证每一次改动。如果你正被某个Ceres优化问题卡住，不妨也先从这几个层面逐项过一遍，大概率能少走弯路。
