假设正在优化一个报销单识别工具。上传图片太大，于是加了压缩：4 MB 变成 1 MB，上传数据量减少了。
接下来却发现，图片上的 126.80 被识别成了 128.80。文件确实变小，用户核对金额的工作反而增加了。
这是一个教学模拟，图片大小、金额和后续情节均为说明问题而设。它提示我们：判断一次优化，要追到用户原来要完成的事，同时看它把代价转移到了哪里。 中间某项指标变好，值得记录；是否值得保留这项改动，还要继续判断。
一、先说清楚，这次到底要改善什么
用户需要从报销单中取得可核对的日期和金额。图片上传只是过程中的一步。
因此，“文件压到 1 MB 以下”和“报销信息更容易核对”是两项不同要求。前者可以用文件大小检查，后者要打开实际识别结果，和原图比较。
如果团队只盯压缩率，就容易继续提高压缩强度，把文字压得更模糊。如果直接盯“整体成功率”，又可能不知道错误出在哪里。两个层次都需要，关键是说明它们之间的关系。
Google SRE 的服务级目标章节从用户关心的行为讨论指标选择，也区分用户侧体验与容易取得的服务端代理指标。这个思路适用于这里：先确定用户需要的结果，再选择能解释结果的中间观察。
在原任务里写一句具体目标就够了：减少图片传输负担，同时保留小字金额的可辨识度；检查最终页面展示的日期和金额是否仍然正确。这样，压缩率就不会悄悄替代用户目标。
二、把同一张图片，沿实际路径走一遍
想确认问题，不必先新增一个综合评分系统。沿图片经过的地方逐段比较：
一个经常被遗漏的情况是：压缩函数的测试通过，上传按钮却继续走旧路径。还有一种情况是识别正确，页面仍显示上次缓存。仅检查压缩文件，无法分辨这些问题。
预期金额应来自事先人工核对的样本，不能把同一个识别器的另一次输出当作正确答案，否则两边可能一起读错。
发现“126.80 变成 128.80”之后，修复也应对应原因：若压缩损伤了小数点，就调整压缩策略或为这类图片保留足够清晰度；若页面展示了旧结果，就修正结果关联。不能只增加重试次数，再把偶然一次正确当作完成。
三、先分清三种进展，才知道下一步改哪里
沿这条路径，我们可能得到三种有价值但不同的结果。
局部修复。 压缩后的图片保留了小数点，相关样本可以辨认。这解决了一个具体缺陷，识别器和页面是否都改善，还要沿后续路径检查。
测量修正。 评测脚本以前把所有 PNG 文件判为失败，现在支持了它们。评测结果会变化，但同一张图片的实际识别输出并没有因此改变。需要保留旧脚本的错误记录，并用一致口径重新比较，不能把评分变化记成模型能力提升。
用户任务改善。 在可比较的报销单样本中，上传负担减少，最终日期和金额仍可核对，并且没有增加不可接受的等待或人工修正。这才对应最初的任务目标。
三者都值得做。问题是不能在复盘里只写一句“识别系统升级成功”，让下一位维护者猜究竟改善了什么。
四、ETF Agent 的真实材料里，也要分清这些层次
我们曾记录过一次持仓遗漏：工具返回了 50 条，送进模型的中间整理只保留 20 条，回答漏掉了黄金持仓。当时把通用条目上限调整到 60，保留原有硬容量限制和敏感字段处理，修复了那个明确的截断点。
这说明当时的输入遗漏得到了有界修正。它并不自动说明整份投资研究更准确：还要看后续模型实际收到了什么、使用了什么，以及报告内容是否改变。详见结果外置与完整性。
另一类问题来自观察工具。长输入输出的采集缺口，曾让部分执行内容甚至回合在读取时不可见。补上缺失标记，会让排查更可信，却不会让过去的模型重新执行一次。详见可信观测。
独立评测器也出现过输出预算不足、评分格式无法解析的情况。调整评测器预算后，相关格式失败消失；工作模型原来过短、未覆盖要求的回答仍然不合格。这是测量工具的修复，应与回答质量的变化分开记录。
还有一个反例同样重要：有界测试触发了网页内容压缩，核对实际生产配置后，却没有证据表明默认研究路径已经遇到相同瓶颈。我们因此没有继续添加一套新摘要机制。测试揭示一种可能分支，与生产当前确有该问题，也需要区分。
图片案例帮助理解这些关系；这些真实材料则说明，为什么我们开始重视“收益究竟落在哪一层”。
五、完整性更好，成本也可能更高
假设为保留文字，把部分图片恢复到更高分辨率。上传量增加了，但金额识别更可靠。这可能是值得接受的选择，不能仅因为文件变大就判为退步。
也不能反过来，只要识别更准，就忽略等待时间、调用费用和人工修正。应把取舍写清楚：在哪类图片上，需要什么清晰度，额外成本是多少，是否存在同样有效但代价更小的做法。
在 Agent 中，扩大结果输入、丰富工具说明、增加检查模型，都可能产生类似取舍。工具说明更充分，可能帮助选择，也会增加输入负担；删除必要说明，又可能使工具更难正确使用。不能为了压低 Token 而悄悄缩减已准入的合法工具或遗漏保护条件。
权限、隐私和资金执行约束先要满足，不能拿速度或质量高分抵扣。其余可权衡的目标，再放在同类任务里一起看。
六、一次比较怎样才有参考价值
回到压缩方案，先保存一批与问题相关的样本：正常清晰图片、小字金额、倾斜拍摄、原本就模糊的图片。样本数量根据本次问题确定，不编造一个全行业都适用的门槛。
用同一份输入和预先核对的日期金额比较前后版本。尽量保持识别器版本、任务要求等条件一致，记录实际压缩大小、最终内容、耗时及调用情况。模型有波动时，按要作出的决定增加必要的重复观察，不拿一次幸运输出下结论。
不能悄悄把仍然无法判断的图片移出分母，也不能把“金额正确”和“只要有输出”当作同一个通过标准。评测规则改变时，先恢复可比口径，再讨论收益。
如果现在只验证了小数点不再丢失，就记录这项局部修复。正确性问题需要及时处理，不必等到长期收益统计齐全；尚未验证的整体收益留待后续确认。
对于 Agent，原文的这张关系图表达了同样的追查顺序：工具取得结果，整理为获准输入，提交给模型，形成结果并保存，最后检查交付。旁边的记录帮助逐段对照，不自动替任何一步宣布成功。
graph TD
ToolResult --> AuthorizedProjection
AuthorizedProjection --> SubmittedModelInput
SubmittedModelInput --> GeneratedResult
GeneratedResult --> DurablePublication
DurablePublication --> UserDelivery
ToolResult --> ExecutionReceipt
AuthorizedProjection --> CoverageReceipt
SubmittedModelInput --> InputReceipt
DurablePublication --> PublicationReceipt
ExecutionReceipt --> EvidenceReconciliation
CoverageReceipt --> EvidenceReconciliation
InputReceipt --> EvidenceReconciliation
PublicationReceipt --> EvidenceReconciliation
图中英文节点保留系统交接名称。它是分析示意，不要求新增同名字段或数据库：复用已有记录，核对同一次任务在各处发生了什么即可。
七、下一次“优化完成”，把结论说到恰当的位置
修改一个确定的截断条件，可以先用针对性用例验证；调整实际输入或识别方法，再检查对应真实路径；要声称用户体验或研究质量提高，才需要与该主张相称的任务比较。每次改动都做全套昂贵实验，同样会拖慢研发。
压缩案例的任务可以这样写：保存问题原图及人工核对值；确认损失发生在压缩、识别还是展示；只修改造成差异的位置；先验证这个反例，再用代表性样本观察正确性和额外代价。
完成时也给出具体结论：压缩后的小数点保住了，或者页面已经显示对应文件的识别结果，或者这轮只修好了评测脚本。哪个成立就说哪个，不用一个笼统的“整体变好”覆盖全部。
能说清改好了哪一段、结果有没有传到用户、代价增加在哪里，局部优化才有机会成为系统进步。
延伸阅读与交流
本文对应第九原则：局部改善不等于整体进步，也关联上下文中的事实与用户任务成功。关于评测口径，可继续读测试与评测；关于可选能力的成本，见代码与系统演化。
欢迎在 GitHub 公开文集交流反例；如果文章对你有帮助，也欢迎点一个 Star。
在正式技术站点阅读本篇｜GitHub 开源文章仓库（欢迎 Star 和交流）
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
It is assumed that a claim recognition tool is being optimized. The image was too big to upload, so it was compressed: 4 MB became 1 MB and the amount of data uploaded decreased.
And then it turns out that 126.80 on the picture was identified as 128.80. It was true that the documents had become smaller and that the checking of amounts by users had increased.
This is a simulation of teaching, and the size of the picture, the amount and the subsequent circumstances are illustrative. It tells us to judge an optimisation, to follow what the user was going to do, and to see where it shifted the cost. The improvement of an intermediate indicator is worth recording; it is worth retaining the change and continues to be judged.
First, let's get this straight.
Users need to obtain verifiable dates and amounts from claims. Image upload is just a step in the process.
Thus, “document under 1 MB” and “reimbursement information easier to reconcile” are two distinct requirements. The former can be checked for file size, while the latter needs to open the actual identification results and compare them with the original figure.
If the team simply focuses on the compression rate, it is easy to continue to increase the compression intensity and to overwhelm the text. If you look directly at “the whole success rate”, you may not know where the error was. Both levels are needed, and the key is to explain the relationship between them.
The Google SRE service level goal section discusses the selection of indicators from user-interested behaviour and also distinguishes user-side experience from easily available service-end proxy indicators. This approach applies here: first, to determine the outcome that the user needs, then to select intermediate observations that explain the result.
It is sufficient to write a specific goal in the original task: to reduce the burden on the transmission of pictures while retaining the discernability of small words; and to check whether the date and amount displayed on the final page is still correct. In this way, compression rates do not quietly replace user targets.
Take the same picture and follow the actual path.
In order to identify the problem, there is no need to add an integrated rating system. Compared to the location by which the pictures were taken, by section:
One frequent omission is that the compression function is tested and the upload button continues to follow the old path. In another case, the correct identification was made and the page still shows the last cache. Only the compressed file is checked and it is not possible to distinguish these problems.
The expected amount should come from sample, which was manually checked in advance, and another output from the same identifier could not be considered as the correct answer, otherwise the two sides might read the error together.
Found "126.80 to 128.80" Thereafter, the repairs should also correspond to the causes: If the compression damages the decimal, adjust the compression policy or retain sufficient clarity for such images; if the old results are displayed on the page, fix the result association. The number of retrys cannot be increased only, and one more chance is correctly considered to be complete.
iii. Distinguishing three things before you know where next step is.
Along this path, we may have three valuable but different outcomes.
Local rehabilitation. The compressed picture retains decimal points and the associated sample is identifiable. This addressed a specific shortcoming, whether the identifiers and the page were improved and checked along subsequent paths.
Measurement correction. The scripts were judged to have failed in all PNG files and now support them. The evaluation results will change, but the actual identification output of the same picture has not changed. There is a need to maintain the erroneous records of old scripts and recomparisonate them with a consistent calibre, so that scoring changes cannot be recorded as model capabilities.
Improved user assignments. In the comparable claim form sample, the upload burden is reduced, the final date and amount are still reconcilable and no unacceptable waiting or manual correction is added. This corresponds to the original mission objectives.
All three are worth doing. The problem is not to write a single sentence in the flash drive: “Identification system upgrades have been successful”, allowing the next maintainer to guess exactly what has improved.
IV. ETF Age also needs to distinguish between these levels.
We've recorded an omission: the tool returned 50, the medium of the model was left with only 20, and the answer was that the gold holder was missing. That clear cut-off point was repaired by adjusting the generic entry ceiling to 60, retaining the original hard capacity limit and sensitive field processing.
This indicates that the input omissions were modified at the time. It does not automatically indicate that the entire investment study is more accurate: it also depends on what the follow-up model actually receives, what it uses, and whether the content of the report has changed. Details are provided on the externality and completeness of the results.
Another category of questions comes from observation tools. The capture gap for long-input output has made partial implementation and even round reading invisible. The completion of the missing tags would make the sorting more credible, without allowing the previous model to be re-executed. See more on credible observations.
There have also been instances in which the output budget is inadequate and the rating format cannot be analysed. The format failed to disappear after adjusting the assessor budget; the response to the previously short, uncovered requirements of the work model remained unsatisfactory. This is the repair of the measurement tool and should be recorded separately from changes in the quality of the answers.
It is equally important to recall that there is no evidence that the default study path has encountered the same bottlenecks after the boundary tests triggered the compression of web content and checked the actual production configuration. We therefore did not continue to add a new summary mechanism. The test revealed a possible branch, which also needs to be distinguished from the current production problem.
Photo cases help to understand these relationships; the real material explains why we are beginning to focus on “what level of proceeds falls”.
V. Improved integrity and possibly higher costs
Reverts part of the picture to higher resolution, assuming the text is retained. The upload volume increased, but the amount was more reliably identified. This may be an acceptable option and should not be set back simply because the document is larger.
Nor can it be reversed by neglecting waiting times, call costs and manual corrections as long as they are better identified. The choice should be made clear: in what type of picture, what clarity is required, what additional costs are, and whether there are equally effective but less costly practices.
In Agent, expanded input of results, enrichment of tools, and increased inspection models can all generate similar trade-offs. A fuller description of the tool may help in choice and also increase the input burden; removing the necessary description may make it more difficult to use the tool correctly. Token cannot be quietly reduced by the legal instruments or the missing protective conditions that have been reached.
permission, privacy and financial enforcement constraints must be satisfied without a high-speed or quality credit. The remaining trade-offs are seen together in the same mandates.
VI. What is the value of a comparison?
Go back to the compression program and save a collection of samples related to the problem: normal clear pictures, small words, tilted pictures, otherwise vague. The number of samples is determined on the basis of this question and does not create an industry-wide threshold.
Comparison of date amounts with the same input and pre-checked version. (b) Maintain, to the extent possible, consistent conditions such as identifier versions, mission requirements, and record actual compression size, final content, time-consuming and callable. When the model fluctuates, the necessary double observations are added to the decision to be taken, without a lucky output.
Images that are still uncalculated cannot be moved quietly out of the denominator, nor can “the correct amount” and “the output” be treated as the same pass criteria. When the evaluation rules change, the comparative calibre is restored before the proceeds are discussed.
If only decimal points are now certified as not missing, this partial restoration is recorded. The question of correctness needs to be addressed in a timely manner, without waiting for full long-term income statistics; the overall gains that have not yet been validated are left for subsequent confirmation.
In the case of Agent, this relationship chart in the original language expresses the same tracing sequence: the tool produces the results, is organized as approved input, is submitted to the model, results are formed and stored, and the delivery is finally checked. Next to the records help to cross-reference paragraphs and do not automatically declare success for any step.
graph TD
ToolResult --> AuthorizedProjection
AuthorizedProjection --> SubmittedModelInput
SubmittedModelInput --> GeneratedResult
GeneratedResult --> DurablePublication
DurablePublication --> UserDelivery
ToolResult --> ExecutionReceipt
AuthorizedProjection --> CoverageReceipt
SubmittedModelInput --> InputReceipt
DurablePublication --> PublicationReceipt
ExecutionReceipt --> EvidenceReconciliation
CoverageReceipt --> EvidenceReconciliation
InputReceipt --> EvidenceReconciliation
PublicationReceipt --> EvidenceReconciliation
The English node in the figure retains the name of the system interface. It is an analytical illustration that does not require the addition of the same name, field, or a database: re-use existing records and check what is happening in different parts of the same mission.
VII. Next “optimization of completion” to put conclusions in the right place
The modification of a defined cut-off condition can be verified first by means of a specific case; by adjusting the actual input or identification method and then checking the true path; and by claiming that the user experience or the quality of the research has improved, the task needs to be compared with that claim. Each change is accompanied by a full set of expensive experiments, which also slows down development.
The task of compressing the case could be written as follows: to preserve the original map of the problem and the manual check value; to confirm whether the loss occurred in the compression, identification or presentation; to modify only the location that caused the difference; to verify the reverse example before observing correctness and additional costs with representative sample.
Specific findings were also made: the decimal points were saved after compression, or the result of the identification of the corresponding document was shown on the page, or only the evaluation script was fixed. Any establishment is defined as such and is not covered by a general “better whole”.
Local optimization offers an opportunity for systemic progress by clarifying which paragraphs have been modified, whether the results have reached the users and where the costs have increased.
Extension reading and communication
This corresponds to the ninth principle: local improvements do not amount to overall progress, but relate to the fact that context and the success of the user mission. With regard to calibration, tests and assessments can continue to be read; for the cost of optional capabilities, see code and system evolution.
Welcome to the GitHub public collection; if the article helps you, ask Star.
Read this GitHub open source article repository at official technology sites (welcome Star and communication)
Auto-fetched and translated by AI Atlas. All rights belong to the original author.