这是上一轮检索效果优化的需求：
  参考
  searcher.py 
  rerank_client.py 
  schema.py 
  es_query_builder.py 
  config.yaml 
  相关性检索优化说明.md 
  
  在ES返回到rerank期间增加一轮粗排+一轮精排。
  1. ES召回，600
  2. 粗排：600->240。配置文件增加粗排相关配置，包括输入条数（配置为700，ES拉取的条数改为粗排输入条数），然后增加粗排的融合公式配置，参考现有的reranker融合公式即可、只是去掉其中的重排模型项。
  3. 现在的sku选择、为reranker生成title后缀这一套逻辑，是放在粗排后，因为精排也是一个reranker模型（只不过是一个轻量级的，bge-reranker），需要用这个title后缀。
  4. 精排：240-80，使用bge-reranker，但是，因为reranker只能选一个backend，考虑如何重构。现在，精排也是一个独立的进程、独立提供端口，服务。但是，因为跟重排逻辑是一致的（即使有部分不一致也应该分离不一致的点进行配置化），所以共用代码，只是根据需要启动两个实例，避免代码冗余。
  5. 重排：80，也是用当前的重排代码，调用单独的实例（即现在使用的实例），返回后，经过融合公式，到分页，也参考现在的融合公式，但是，加入一项精排模型打分。
  测试时，使用跟我同样的环境./scripts/service_ctl.sh reranker backend 重启相关服务进行测试
  
  你已经完成了一般修改，已把三段排序链路接上了，主改动在 search/searcher.py、search/rerank_client.py、config/schema.py、config/loader.py、config/services_config.py 和 config/config.yaml。
  
  现在链路是：
  ES 拉取 coarse_rank.input_window 条 -> 粗排按 text/knn 融合裁到 coarse_rank.output_window -> 再做 SKU 选择和 title suffix -> 精排调用轻量 reranker 裁到 fine_rank.output_window -> 最终重排调用现有 reranker，并在最终融合里加入 fine_score。同时把 reranker client/provider 改成了按 service_profile 选不同 service_url，这样 fine/final 可以共用同一套服务代码，只起不同实例。
  
  并且，你对调试展示进行了重构。你已经把结果卡片和全局调试面板都改成按漏斗阶段取值和展示，在 app.js 里把 ES 召回、粗排、精排、最终 rerank 分开渲染了。
  现在每条结果的 debug 会按阶段展示：
  ES 召回：rank、ES score、norm score、matched queries。
  粗排：rank/rank_change、coarse_score、text/knn 输入、text_source/text_translation/text_primary/text_support、text_knn/image_knn、factor。
  精排：rank/rank_change、fine_score、fine input。
  最终 rerank：rank/rank_change、rerank_score、text/knn score、各 factor、fused_score，以及完整 signals。
  
  请你仔细阅读漏斗环节的这些代码，特别是关于打分、重排序、debug信息记录方面的。
  
  
  现在，请注意，需要优化的是：
  1. Fine Rank环节似乎没有进行融合公式的计算、继而进行重排序，请修复。
  2.从软件工程的视角review代码： 
  因为增加了多重排序漏斗，数据的记录、传递，交互的接口，是否设计足够合理，存在哪些问题。
  请从软件工程的角度审视这些逻辑，是否有需要梳理、清理和重写的地方。
  3. Fine Rank和Final Rerank环节信息记录优化：
  这两个环节都要体现融合公式的输入、关键因子、以及融合公式的得分。为了避免代码膨胀，Fine Rank和Final Rerank
  都可以采用一个字符串记录这些关键信息，字符串内包括融合公式各项的名称和具体数值，以及最终结果。你也可以继续沿用当前的记录方式，需要你对比一下哪种代码量更少、更清晰简洁。
  也要仔细思考当前的代码，真实的计算和信息的记录，是否存在分离的情况，是否存在冗余和分叉。这种情况是不允许的，存在隐藏的风险，以后改了正式逻辑而没有改调试信息，将导致不一致。
  务必注意，当前已经有相关的信息记录逻辑，注意不要叠补丁，可以适当修改、或者清理重写，而不是新增，要使得代码更简洁和干净，并保证信息记录与真实逻辑一致。
  
  
  涉及代码较多，请耐心阅读，以上都是一些需要深度思考的任务，慢慢来，留足够多的时间来review和重新设计。
  
  
  
  
  
  
  因为增加了两个环节，多了很多变量。
  以这些为效果评估的测试集，调试参数。这次的调整范围是，融合公式中的各个
  falda negra oficina
  red fitted tee
  黒いミディ丈スカート
  黑色中长半身裙
  чёрное летнее платье
  修身牛仔裤
  date night dress
  vacation outfit dress
  minimalist top
  
  仔细思考这些漏斗中重要的信息如何呈现。对应的修改前端代码。
  注意包括整体漏斗信息的呈现，以及每条结构中独自的信息。
  我需要这些信息，辅助各环节融合公式的调参，根据我的需求，深度思考该如何设计，要呈现哪些信息，如何呈现。
  可以对现有的逻辑做适当的重构，重新整理。
  
  
  
  
  fine 实例也需要在config.yaml中体现，并且需要被server_ctl.sh管理，参考现在是怎么管理reranker的。fine和reranker分别调用哪个模型（两者代码功能，但是只是启动不同的实例），请你深度思考后决定。这里是需要参考当前代码、根据实际需要（原来只有一个reranker、现在多了一个精排，也要调用一个重排模型，因此带来的必要的部分重构。
  
  1. Fine Rank环节的信息都是N/A，是没有配置吗。fine rank是使用bge-reranker，复用当前reranker模型的代码，但是需要单独起一个服务、单独加载一个模型。
  2. Ranking Funnel、Fusion Factors、Signal Breakdown
  这些是不是整合起来、按漏斗收集、整理信息、以及进行呈现比较好。
  ES 召回的环节，展示Matched Queries各项打分、ES的总分、norm后打分、排序位置，等等关键信息
  粗排：粗排融合公式的各项输入、重要中间结果和参数、最后得分，排序位置以及上升/下降了多少。等等关键信息。
  精排：同样例举关键的输入、中间过程、输出、排序和位置变化等。
  reranker：类似
  
  因为涉及的环节较多，非常要注意的一个点是：不要每次修改都在原来的基础上，为实现目标而打补丁，应该观察一下所涉及的代码现在是怎么做的，务必注意如何适当的清理掉现有逻辑，该如何对其进行修改，来达到目的，以达到代码的精简，避免冗余、分叉。
  
  
  
  
  
  1. Fine Rank 这个环节没有体现融合公式的输入、关键因子、以及融合公式的得分。为了避免代码膨胀，Fine Rank和Final Rerank
  都可以采用一个字符串记录这些关键信息，字符串内包括融合公式各项的名称和具体数值，以及最终结果。