feat: collab 批次(可先合)—— Swagger UI / ask trace / index_filter / clippy / /v1 修复 / LLM-judge 基线 - #2
Conversation
- ask_handler 完成/失败分别落 info/warn 事件,默认日志级别即可见, 事件显式携带 request_id 与各阶段耗时(doc_recall/chunk_dense/merge/answer) - 中间件把 request-id 注入 RequestId 扩展,审计 metadata 增加 request_id 字段 - 新增 extensions 注入端到端测试(http_tests)
- memori-parser: 行结束事件里嵌套 if 折叠为 match guard(行为等价) - memori-core: format! 参数去掉多余引用(行为等价) - 修复后 workspace clippy -D warnings 全绿
- AppSettings 新增 index_filter 字段(此前 serde 静默丢弃该配置) - replace_engine 在 set_indexing_config 后应用筛选配置 - 新增 2 个反序列化单测固定解析行为
- build_openai_url:endpoint 已显式带 /v1(无尾斜杠)时不再追加, 修复拼成 /v1/v1 导致 404 的问题;新增幂等单测 - 回归 harness 探活:单次 10s 超时改为 3 次重试(每次 20s + 5s 间隔), 本地模型冷载(实测 12s+)不再被误判为服务不可用
- 报告入库:retrieval_regression_v2_judge_report.json(106 应答题全部判分) - answer_correct_rate 0.401(受限配置下限:1.5B 作答 + 无 rerank) - RETRIEVAL_BASELINE_V2.md 新增作答层基线章节,含环境、数字与解读
- GET /api/docs:Swagger UI 页面,数据源 /api/openapi.json - CSS/JS 静态资源构建期内置(include_str!/include_bytes!),离线可用, 符合本地优先原则,不引入 utoipa 依赖 - 新增端到端测试:页面 HTML、静态资源 content-type 与非空校验
当前 workspace/UI/Tauri 版本均为 1.5.2,但 docs/release 只有到 v1.5.0,lint job 的版本一致性检查因此必然失败(上游 collab 本身也缺)。补齐 RELEASE_NOTES_v1.5.2.md,覆盖本次工程硬化与 OCR 变更、已知边界与升级说明。 同时把 docs/README.md 的 Release 索引补上 v1.5.0 与 v1.5.2 两条(此前 v1.5.0 也未登记)。
审查者指南本 PR 汇总了一组可独立合并的工程加固改动:增强 ask 链路的 trace/request-id 审计关联,补齐服务器端 index_filter、/v1 URL 和冷启动探活行为,内置离线 Swagger UI,清理 Clippy 警告,并新增 126 题作答层 LLM-judge 基线及 1.5.2 发布文档。 ask tracing 和审计关联的时序图sequenceDiagram
participant Client
participant Middleware
participant AskHandler
participant Engine
participant Audit
Client->>Middleware: POST /api/ask
Middleware->>Middleware: request_id_trace_middleware
Middleware->>AskHandler: Request + RequestId
AskHandler->>Engine: ask
Engine-->>AskHandler: response and metrics
AskHandler->>Audit: append_audit_event(request_id)
AskHandler-->>Middleware: JSON response
Middleware-->>Client: Response with x-request-id
作答层 LLM judge 基线的时序图sequenceDiagram
participant Harness
participant Retrieval
participant AnswerModel
participant JudgeModel
participant Report
Harness->>Retrieval: Run regression case
Retrieval-->>Harness: Evidence and context
Harness->>AnswerModel: Generate answer
AnswerModel-->>Harness: Answer text
Harness->>JudgeModel: Judge against target_clues
JudgeModel-->>Harness: correct, partial, or incorrect
Harness->>Report: Write per-question reason and metrics
服务器索引筛选和模型端点修复流程图flowchart LR
Settings[AppSettings] --> Filter[index_filter]
Filter --> Engine[replace_engine]
Engine --> Indexer[Filtered indexing]
Endpoint[Configured endpoint] --> URL[build_openai_url]
URL --> V1[Single /v1 path]
Probe[Embedding health probe] --> Retry[Up to 3 attempts]
Retry --> Ready[Cold-start tolerant readiness]
文件级变更
提示和命令与 Sourcery 交互
自定义你的使用体验访问你的控制面板以:
获取帮助Original review guide in EnglishReviewer's Guide本 PR 汇总了一组可独立合并的工程加固改动:增强 ask 链路的 trace/request-id 审计关联,补齐服务器端 index_filter、/v1 URL 和冷启动探活行为,内置离线 Swagger UI,清理 Clippy 警告,并新增 126 题作答层 LLM-judge 基线及 1.5.2 发布文档。 Sequence diagram for ask tracing and audit correlationsequenceDiagram
participant Client
participant Middleware
participant AskHandler
participant Engine
participant Audit
Client->>Middleware: POST /api/ask
Middleware->>Middleware: request_id_trace_middleware
Middleware->>AskHandler: Request + RequestId
AskHandler->>Engine: ask
Engine-->>AskHandler: response and metrics
AskHandler->>Audit: append_audit_event(request_id)
AskHandler-->>Middleware: JSON response
Middleware-->>Client: Response with x-request-id
Sequence diagram for answer-layer LLM judge baselinesequenceDiagram
participant Harness
participant Retrieval
participant AnswerModel
participant JudgeModel
participant Report
Harness->>Retrieval: Run regression case
Retrieval-->>Harness: Evidence and context
Harness->>AnswerModel: Generate answer
AnswerModel-->>Harness: Answer text
Harness->>JudgeModel: Judge against target_clues
JudgeModel-->>Harness: correct, partial, or incorrect
Harness->>Report: Write per-question reason and metrics
Flow diagram for server index filtering and model endpoint fixesflowchart LR
Settings[AppSettings] --> Filter[index_filter]
Filter --> Engine[replace_engine]
Engine --> Indexer[Filtered indexing]
Endpoint[Configured endpoint] --> URL[build_openai_url]
URL --> V1[Single /v1 path]
Probe[Embedding health probe] --> Retry[Up to 3 attempts]
Retry --> Ready[Cold-start tolerant readiness]
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
嘿——我发现了 1 个问题
面向 AI 代理的提示
请处理本次代码审查中的评论:
## 个别评论
### 评论 1
<location path="memori-server/src/routes/ask.rs" line_range="84-94" />
<code_context>
.failed_requests
.fetch_add(1, Ordering::Relaxed);
state.metrics.ask_failed.fetch_add(1, Ordering::Relaxed);
+ warn!(
+ request_id = %request_id.0,
+ error = %err,
+ elapsed_ms = ask_started_at.elapsed().as_millis() as u64,
+ "ask failed"
+ );
map_engine_api_error(err)
})?;
</code_context>
<issue_to_address>
**issue (broader_impact):** 新增的失败跟踪仅在 `engine.ask_structured` 返回错误时发出。对于空查询、会话验证、设置加载、策略验证、引擎初始化缺失以及其他提前返回路径导致的 ask 失败,仍然不会产生默认级别的失败事件,因此这些请求缺少所承诺的 ask 失败跟踪。
**触发条件:** ask 请求在调用 `ask_structured` 之前失败时。
**建议修复:** 在完整的处理程序流程外围发出单个失败事件,或者为每个提前错误返回路径添加等效日志,同时保留请求 ID 和耗时。
</issue_to_address>Sourcery 评估
需要人工审查。 有 1 个发现需要优先处理;此外,服务器端索引过滤器和 URL 构建变更会改变运行时行为,而不正确的过滤器可能会在回滚后使索引中遗漏文档或包含非预期文档;重新建立索引可以修复该问题。请求 ID 也会持久化在审计记录中,但由此产生的影响是有限且可恢复的,不会造成不可逆的访问权限或策略变更。
阻塞性发现:memori-server/src/routes/ask.rs:94
Original comment in English
Hey - I've found 1 issue
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="memori-server/src/routes/ask.rs" line_range="84-94" />
<code_context>
.failed_requests
.fetch_add(1, Ordering::Relaxed);
state.metrics.ask_failed.fetch_add(1, Ordering::Relaxed);
+ warn!(
+ request_id = %request_id.0,
+ error = %err,
+ elapsed_ms = ask_started_at.elapsed().as_millis() as u64,
+ "ask failed"
+ );
map_engine_api_error(err)
})?;
</code_context>
<issue_to_address>
**issue (broader_impact):** The new failure trace is emitted only when `engine.ask_structured` returns an error. Ask failures from empty queries, session validation, settings loading, policy validation, missing engine initialization, and other early-return paths still produce no default-level failure event, so the promised ask failure trace is absent for those requests.
**Triggers:** When an ask request fails before `ask_structured` is called.
**Suggested fix:** Emit a single failure event around the complete handler flow, or add equivalent logging to every early-error return path while preserving the request id and elapsed time.
</issue_to_address>Sourcery assessment
Needs a human reviewer. 1 finding to address first, and the server-side index filter and URL-building changes alter runtime behavior, and an incorrect filter can leave omitted or unintended documents in the index after a revert; a reindex can repair that. Request IDs also persist in audit records, but the resulting impact is bounded and recoverable rather than an irreversible access or policy change.
Blocking findings: memori-server/src/routes/ask.rs:94
| .failed_requests | ||
| .fetch_add(1, Ordering::Relaxed); | ||
| state.metrics.ask_failed.fetch_add(1, Ordering::Relaxed); | ||
| warn!( | ||
| request_id = %request_id.0, | ||
| error = %err, | ||
| elapsed_ms = ask_started_at.elapsed().as_millis() as u64, | ||
| "ask failed" | ||
| ); | ||
| map_engine_api_error(err) | ||
| })?; |
There was a problem hiding this comment.
issue (broader_impact): 新增的失败跟踪仅在 engine.ask_structured 返回错误时发出。对于空查询、会话验证、设置加载、策略验证、引擎初始化缺失以及其他提前返回路径导致的 ask 失败,仍然不会产生默认级别的失败事件,因此这些请求缺少所承诺的 ask 失败跟踪。
触发条件: ask 请求在调用 ask_structured 之前失败时。
建议修复: 在完整的处理程序流程外围发出单个失败事件,或者为每个提前错误返回路径添加等效日志,同时保留请求 ID 和耗时。
Original comment in English
issue (broader_impact): The new failure trace is emitted only when engine.ask_structured returns an error. Ask failures from empty queries, session validation, settings loading, policy validation, missing engine initialization, and other early-return paths still produce no default-level failure event, so the promised ask failure trace is absent for those requests.
Triggers: When an ask request fails before ask_structured is called.
Suggested fix: Emit a single failure event around the complete handler flow, or add equivalent logging to every early-error return path while preserving the request id and elapsed time.
|
审过了,代码部分可以合。 上一轮(#1)我已经逐块核过这批改动,这次又复核了一遍:
合并前有两件事想请你处理: 1.
|
retrieval_regression_v2_judge_report.json 有 7223 行,每跑一次基准就整体重写:进仓库会带来巨大 diff 噪声与体积膨胀,且没人会在 review 里读它。按评审建议删除该文件,仓库只保留 RETRIEVAL_BASELINE_V2.md 里的汇总指标;需要可追溯快照时以 CI artifact / 附件形式提供。同步修正文档里对该文件路径的引用。
|
复审通过,可以合了。两点都按意见处理了:
保留下来的那段汇总质量很高,特别是这两处:
这种自己给自己设限、不拿有利数字当产品口径的写法,比多跑几个点有价值得多。 代码部分(Swagger UI、ask trace/request-id、index_filter、 |
合并 FPSZ#2/FPSZ#3/FPSZ#5 后的 collab,三处冲突均为双方各自新增内容,保留双方: - README.md「已实现但仍在优化」:50k 压测条目 + OCR 条目 - docs/qa/RETRIEVAL_BASELINE_V2.md:作答层 LLM-judge 基线 + OCR 接入与边界 - memori-server/src/dto.rs:AppSettings 的 index_filter 与 ocr_tesseract_path 两个字段 同时启用 pdf_with_indirect_resources_is_extracted(原 #[ignore]): 手工构造 lopdf::Stream 用结构体字面量会绕过 /Length 写入(lopdf object.rs:602 的 Stream::new 才会 dict.set("Length", ...)),存盘后流长度为 0、load 回来 content 为空,解码拿不到像素,测试因此假失败——与 get_pages() 无关(实测 get_pages()=1、get_page_resources 也正确返回 inherited)。改用 Stream::new 后 测试通过,可作为间接 /Resources + 间接 /XObject 的回归锁。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
背景
按评审建议把原 PR 拆开,这是"可以先合"的干净部分(评审原文:这几块独立且干净)。
包含内容(7 个提交)
feat(server): ask 链路补默认级别 trace 事件并关联审计 request-idfix: 修复 workspace clippy 警告fix(server): 服务器模式应用 index_filter 索引筛选fix(core): 修复 /v1 端点重复拼接与回归探活冷启动假失败docs(qa): 新增作答层 LLM-judge 首个基线(126 题实跑)feat(server): 新增 Swagger UI 交互式 API 文档页docs(release): 补齐 1.5.2 release notes 与文档索引为什么带上 release notes
Cargo.toml/ui/package.json/memori-desktop/tauri.conf.json三处版本均为1.5.2,但docs/release/只到v1.5.0,rust-ci.yml的版本一致性检查因此必然失败(上游collab本身也缺这个文件)。本 PR 一并补齐RELEASE_NOTES_v1.5.2.md,并把docs/README.md的 Release 索引补上v1.5.0/v1.5.2。不包含
验证
cargo test --workspace --all-targets全绿,0 失败collab最新050c690,compare 显示behind_by=0(不回退既有改动)Sourcery 总结
强化服务器可观测性和配置处理,同时新增离线 API 文档、答案质量评估以及 1.5.2 版本文档。
新功能:
错误修复:
增强功能:
文档:
测试:
Original summary in English
Sourcery 总结
改进服务器可观测性和配置处理,同时添加离线 API 文档、答案质量评估,并完善 1.5.2 版本文档。
新功能:
错误修复:
/v1URL 前缀,并使回归健康探针能够容忍本地嵌入模型冷启动。增强功能:
文档:
测试:
/v1URL 构造的测试覆盖。Original summary in English
Summary by Sourcery
Improve server observability and configuration handling while adding offline API documentation, answer-quality evaluation, and complete 1.5.2 release documentation.
New Features:
Bug Fixes:
/v1URL prefixes, and make regression health probes tolerate local embedding-model cold starts.Enhancements:
Documentation:
Tests:
/v1URL construction.