ProView AI 架构说明

基于真实面试流程流转的 LLM 工程架构设计

LLM Application Architecture

面试过程不卡顿，
评估结果有证据。

ProView 并不是把候选人塞进一个巨大的聊天窗口。系统巧妙地将一次面试拆分为两层：前端负责低延迟的自然连续对话；后端异步链路（Sidecars）则默默沉淀结构化数据、评估证据和长期记忆。

主链路保体验 RAG 做上下文选择 异步 Agent 增强质量 结构化证据生成报告
核心设计原则：克制的上下文

不是给模型喂入无限的上下文，而是给模型当前最有用、最可控、可恢复的结构化特征。RAG 在此不仅是 QA，更是控制 Token 预算的精细阀门。

系统交互边界：Output/Metadata 分离

候选人只看到自然语言问题；评分、Rubric、隐藏记忆和 Checkpoint 均通过严谨的 Schema 留在底层数据库，避免复杂 JSON 破坏前台对话体验。

贯穿案例

小林：3 年前端，简历写了 React 后台、权限模块和大表格性能优化。

这页后面的每个模块，都围绕同一场面试解释：系统不是泛泛聊天，而是一步步验证小林是否真的做过性能优化、能否说清定位过程、有没有量化指标，以及权限模块理解到什么深度。

简历线索“使用虚拟滚动优化大表格卡顿”，但没写优化前后指标。
JD 要求复杂表格性能优化、React 后台、权限系统或 RBAC 经验。
要验证什么瓶颈定位、优化动作、量化结果、方案权衡和个人贡献边界。
最终目标报告结论能追溯到具体轮次，而不是最后凭印象总结。

核心业务流转流水线

点击下方节点查看模块底层流转机制。体验优先的实线主链路与负责繁重计算的虚线旁路做异步隔离。

系统分层架构图

这部分按一次面试的处理链路拆层，回答“从配置输入到最终报告，中间每一层各负责什么”。它比基础设施分层更适合面试讲解，也能和上面的核心流水线直接对应。

贯穿案例里的小林只看到自然面试；系统内部则把“读 JD 和简历、选择上下文、生成追问、异步评分、压缩记忆、生成报告、观察健康状态”拆成七层。这样讲的时候可以顺着一场面试往下走，不容易陷入技术名词堆叠。
Step 1 配置层 把 JD、简历和面试目标整理成稳定输入。
解决什么

把岗位要求、候选人经历、难度、面试类型和目标转成面试官初始笔记。

核心产物

job_requirements、candidate_facts、risk_signals、next_followups、interview_config。

为什么这样选

先结构化输入，后续每轮不用重新读取完整 JD 和简历，减少 prompt 噪声。

当前 / 下一步

当前支持基础配置和候选人线索提取；下一步可补配置版本和解析质量指标。

Step 2 上下文构建层 Prompt Context Builder + RAG Context Selector。
解决什么

决定这一轮问题前模型该看哪些简历事实、JD 要求、题库 rubric 和历史状态。

核心产物

prompt messages、RAG evidence、question rubric、conversation state、context pack。

为什么这样选

RAG 在这里不是问答库，而是上下文选择器，用检索替代全量拼接。

当前 / 下一步

当前已有基础检索和 RAG monitoring；下一步做 query log、rerank、context packing 评估。

Step 3 对话生成层 Interview Agent + Candidate UI 的低延迟主链路。
解决什么

把上下文转成候选人可见的自然追问，并维持面试节奏和体验。

核心产物

visible_question、hidden question_metadata、interview_turns、SSE streamed response。

为什么这样选

可见输出和 hidden metadata 分离，避免复杂 JSON 泄露或拖慢候选人体验。

当前 / 下一步

当前主链路只负责下一问；下一步通过真实短面试 smoke 验证自然度和连续性。

Step 4 后台评估层 Evaluation Agent 异步评分和证据沉淀。
解决什么

候选人回答后异步判断表现，不阻塞下一问，同时给报告和追问提供证据。

核心产物

turn_evaluations、score、pass_level、evidence、suggestion、turn_evaluation_failed event。

为什么这样选

评分耗时且需要结构化输出，放到 sidecar 可以保护主对话低延迟。

当前 / 下一步

当前支持按 turn_id + dimension 幂等评分；下一步补评估延迟和覆盖率 smoke。

Step 5 记忆压缩层 Memory / Summary Agent 处理长面试上下文。
解决什么

长面试不能只靠最近几轮，也不能全量拼历史，需要保留早期关键线索。

核心产物

hidden memory card、context checkpoint、context_compacted event、open_threads、risk_signals。

为什么这样选

短期窗口保证自然衔接，长期记忆卡保证不忘关键事实，agent_events 支持重启恢复。

当前 / 下一步

当前 deterministic checkpoint 可用；下一步做长面试 smoke 和 Summary Agent staging。

Step 6 报告生成层 Report Agent 聚合过程证据生成最终反馈。
解决什么

面试结束后不能凭印象总结，要把全过程评分、证据和风险点组织成报告。

核心产物

final report、dimension_scores、evidence schema、next_training_plan、fallback report。

为什么这样选

报告从 turns、metadata、evaluations、memory checkpoint 聚合，结论更容易追溯。

当前 / 下一步

当前支持结构化 evidence 和模板 fallback；下一步验证真实报告覆盖率和可读性。

Cross-cutting 可观测层 横切全链路，只看健康信号，不看候选人隐私内容。
解决什么

发现 RAG miss、评估失败、上下文压缩异常、报告 fallback 等静默退化。

核心产物

health-summary、evaluation-coverage、context-compaction、rag-retrieval、report-generation、learning signal-summary。

为什么这样选

Monitoring / Learning 只返回聚合指标，不返回候选人回答、问题原文、报告正文或 hidden memory。

当前 / 下一步

当前后端聚合接口已成形；下一步做 endpoint smoke 和可选 operator-only UI。

核心组件选型与测评矩阵

这部分回答“为什么有这些组件、怎么评估它们是否有效、失败时如何兜底”。每张卡片都区分当前状态和下一步，不把未来生产化能力说成已经完成。

Current

Prompt Context Builder

每轮提问前负责组装角色、任务、RAG 证据、对话状态和输出约束。

为什么选择

避免把完整 JD、简历、题库和历史都塞进 prompt，让模型只看当前最有用上下文。

测评方式

token usage、prompt latency、metadata completeness、follow-up relevance、fallback usage。

兜底 / 下一步

RAG miss 时走关键词和上一轮继承；下一步补 context packing 日志和 prompt version 对比。

Current + Planned

RAG Context Selector

不是普通问答库，而是给面试官选择当前轮相关证据和评分口径。

为什么选择

降低 token 成本、减少召回噪声，让同类问题复用更稳定的 rubric。

测评方式

precision、recall、faithfulness、context relevance、latency、token cost、RAG hit/miss/failure。

兜底 / 下一步

关键词归类、弱追问继承、综合表现兜底；下一步建立评估集、query log、rerank 和 context packing。

Current

Interview Agent

唯一直接面对候选人的主链路，负责自然提问、追问和节奏控制。

为什么选择

把候选人可见输出和 hidden metadata 分离，避免复杂 JSON 影响对话体验。

测评方式

SSE latency、visible question quality、JSON leakage count、duplicate question rate、fallback question count。

兜底 / 下一步

metadata 失败时仍可输出纯文本问题；下一步用真实短面试 smoke 验证体验。

Current

Evaluation Agent

按 turn_id + dimension 异步评分，最多两个主维度，不阻塞候选人看到下一问。

为什么选择

评分耗时且需要结构化输出，放在主链路会增加等待和解析风险。

测评方式

evaluation.coverage_rate、failure_rate、latency、JSON parse failure、evidence completeness。

兜底 / 下一步

记录 turn_evaluation_failed，报告阶段使用已有 evidence 或模板 fallback；下一步补真实流程延迟监控。

Current + Staging

Memory / Summary Agent

把长面试历史压缩成 hidden memory card 和 context checkpoint。

为什么选择

不用完整历史拼接，也不只依赖进程内记忆，兼顾 token、延迟和重启恢复。

测评方式

context_compacted_event_count、latest_context_version、summary failure count、open_thread_count、estimated_tokens。

兜底 / 下一步

Summary Agent 默认关闭或短超时，失败回退确定性 memory card；下一步做长面试 compaction smoke。

Current

Report Agent

聚合 turns、metadata、evaluations、memory checkpoint 和 RAG evidence 生成最终报告。

为什么选择

报告不能只凭最后印象总结，需要能回到具体轮次和过程证据。

测评方式

report success rate、fallback success rate、evidence coverage、dimension completeness、format repair count。

兜底 / 下一步

主 LLM 失败时用 turn_evaluations 生成模板报告；下一步持续验证 evidence schema。

Current

Monitoring

只观察系统健康和聚合信号，发现异步 Agent 静默失败。

为什么选择

多 Agent 可能后台退化但前台仍可对话，必须用聚合指标发现问题。

测评方式

health summary、agent-events rollup、evaluation coverage、context compaction、RAG retrieval、report generation。

隐私边界

不返回候选人回答、问题原文、报告正文、evidence 原文、hidden memory、checkpoint payload、RAG query 或文档内容。

Default Off

Learning LLM

读取安全聚合投影，输出需要人工审核的改进建议。

为什么选择

学习闭环要先做建议和审核，不能让模型自动修改 Prompt、Rubric、RAG 或题库。

测评方式

signal-summary HTTP 200、suggestions fallback rate、requires_human_review、unsafe field leakage count。

兜底 / 下一步

默认关闭，异常不 500；下一步做 staging smoke 和审核队列设计。

Current

Database / SSOT

结构化事实源，保存 turn、metadata、evaluation、event、checkpoint 和 report snapshot。

为什么选择

多 Agent 协作必须围绕同一事实源，否则会轮次错乱、重复评分或恢复失败。

测评方式

断线恢复、幂等 upsert、checkpoint rehydrate、报告 evidence 追溯、structured route smoke。

兜底 / 下一步

派生结果失败时保留原始 turn 可重试；下一步设计 PostgreSQL / Supabase structured migration。

Future

Redis Future Layer

云端阶段的缓存、队列和协调层，不作为权威事实源。

为什么选择

本地优先阶段不引入 Redis，避免运维复杂度；多 worker 场景再用它削峰和协调。

测评方式

cache hit rate、queue latency、lock conflict count、worker retry rate、SSE session recovery。

兜底 / 下一步

Redis 丢失不影响数据库事实；未来用于 session cache、prompt cache、agent queue 和 distributed lock。

Output / Metadata 边界隔离

自然对话抛给前台候选人；Rubric 与隐藏状态机下沉至后端。消除长 JSON 引发的响应卡顿与泄露风险。

RAG 定位：Context Selector

避免全量资料灌装模式。RAG 在系统内负责精细裁剪，只把当前轮次迫切需要的评估口径塞入 Prompt。

柔性异步协同 (Fan-out)

Interview Agent 负责候选人可见主链路，评估与压缩放在异步旁路，保证对话体验不断线。

数据快照兜底

主报告 LLM 失败时，报告系统可以检索 turn_evaluations 里的过程证据，生成一份基础但可用的保底报告。

专题深度架构图解

探索模块间的流转契约与防线设计 (Architecture Deep Dive)

架构视图切换
Config (JD/Resume) RAG Index (Chunks) Retrieve / Rerank Context Pack (Top) Prompt Assembly 1. Role & Task 2. State (Memory) 3. RAG Evidence 4. Output Contract Interview Agent DeepSeek Assistant (Prompt Repair Only) question_metadata (稳定口径兜底与复用)
Config Snapshot提取关键 JD 摘要与简历事实，不再全量灌入。
RAG Index & Retrieve依据当前进度切分知识库，构造 Query 并重排。
Context Packing
Prompt Assembly将角色、任务、动态 RAG 证据严格组装，拒绝注意力迷失。
Repair Boundary
DeepSeek Fallback仅作为旁路 Prompt 修复器，绝不接管面试主干。
Metadata Registry未命中 RAG 时，靠规则补齐评价标准兜底。
真实场景

小林的大表格优化，Prompt 到底怎么组装？

当前阶段是项目深挖，小林刚说“我用了虚拟滚动，页面不卡了”，但没有提供指标。系统不会把完整简历和题库都塞给模型，而是只组装这轮需要的信息。

System Role: 专业面试官，问题要自然、具体，不泄露评分规则 Current Task: 验证大表格性能优化经历 Candidate Facts: React 后台系统，虚拟滚动优化大表格 RAG Evidence: 瓶颈定位、优化动作、量化结果、方案权衡 Conversation State: 上一轮缺少指标 Output Contract: 只输出候选人可见追问
生成问题：你刚才提到用了虚拟滚动。当时大概是多少数据量？优化前后的首屏渲染耗时或滚动流畅度有具体变化吗？

💡 Context Selector，而非 QA 库

这里的 Context Builder 可以理解成“每一轮提问前帮 AI 面试官翻笔记”。它不是直接回答问题，而是先判断这一轮该问什么，再从 JD、简历、题库和历史记录里挑出最相关的几条材料。比如聊到性能优化，就只给模型大表格优化经历、JD 的性能要求、题库里的评分标准，以及“上一轮没说指标”这个状态。

大白话：不要把所有资料一股脑塞给模型。Context Builder 先挑重点，Interview Agent 再开口问。

🛡️ DeepSeek 柔性防线

如果主模板总是问“可以再展开讲讲吗？”这种泛问题，DeepSeek 只作为 prompt assistant 生成候选修复稿，例如要求追问瓶颈、定位方法和量化指标。它不能接管主流程，生成结果必须经过字段校验、版本记录和 Output/Metadata 边界检查。

RAG Miss 例子

新岗位没命中题库时，面试也不能停

如果用户填“AI Agent 应用工程师”，知识库暂时没有匹配题库，系统记录 rag_retrieval_missed，但仍用 JD 关键词和通用工程能力继续问。

{ "event_type": "rag_retrieval_missed", "payload": { "stage": "opening", "job_title_matched": false, "questions_count": 0, "scripts_count": 1 } }
大白话：RAG miss 不是系统坏了，而是知识库覆盖不够。面试继续，监控后续提醒补题库。
Current: 五层 Prompt 编译 Current: Metadata 规则兜底 Planned: 精细化 Rerank
Candidate (User) Interview Agent 唯一毫秒级绿色主通道 Async Sidecar Fan-out (非阻塞扇出) Evaluation 评分判定 Memory 压缩提纯 Monitor 事件捕获 Report 终态组装 所有 Sidecar 崩溃，Interview Agent 仍靠底层 DB Rules 存活
主链路：Interview Agent直面用户的唯一合法通道，强制要求极低延迟响应。
Async Fan-out
Evaluation写回评分维度。
Memory压缩历史上下文。
Monitor守护事件安防。
Report滞后收敛汇聚。
多维评分例子

同一句回答，不只考一个能力

小林回答：“三万行数据直接渲染会卡，我用 Chrome Performance 看到 DOM 节点太多和滚动重排，后来用虚拟滚动和接口分页，首屏从 2.8s 降到 900ms。”

[ { "turn_no": 5, "dimension": "性能优化", "score": 8, "evidence": "三万行数据、虚拟滚动、接口分页、2.8s -> 900ms", "suggestion": "追问虚拟滚动边界情况和白屏处理" }, { "turn_no": 5, "dimension": "问题定位", "score": 7, "evidence": "使用 Chrome Performance 定位 DOM 节点过多和滚动重排", "suggestion": "追问如何确认主要瓶颈不是接口慢" } ]
大白话：这像真实面试官做笔记，同一句回答既能看技术方案，也能看他是不是会定位问题。

异步隔离与降级

复杂的大模型网络请求可能带来级联延迟。这里把打分、总结等计算较重的逻辑放到 Sidecar 异步执行。即使 Evaluation 链路异常，主链路也可以基于短期记忆和数据库里的结构化状态继续生成下一问，降低候选人等待风险。

🤝 基于 Schema 的静默契约

Agent 群并不通过自由长文本进行高风险通讯，而是通过数据库里的 turn_id、turn_evaluations 和 agent_events 等结构化键完成交接。

异步追问例子

后台评分悄悄变成下一句自然追问

如果小林第一版只说“我用了虚拟滚动，页面就不卡了”，Evaluation Agent 后台判断缺少瓶颈和指标。

{ "turn_no": 4, "dimension": "性能优化", "pass_level": "partial", "missing": ["没有说明卡顿瓶颈", "没有说明优化前后指标"], "suggestion": "追问数据量、渲染耗时、FPS 或 P95" }
下一问：你刚才提到用了虚拟滚动。当时大概是多少数据量？优化前后的首屏渲染耗时或滚动流畅度有具体变化吗？
⏳ 海量历史上下文 (Lost-in-the-middle 高危灾区) 近期原文 (Turn 16~20) 早期历史 (Turn 1~15) ✂️ 全局进度与考点库 Short Window 保留最近 5 轮高保真原文 Memory Card 压缩后的事实与风险线索 Interview State 面试进度与覆盖度游标 防爆 Token Next Prompt Context 按预算组装，尽量保留输出和重试余量 写入 agent_events.context_compacted (支持重启后恢复)
Short Window滑窗截取近5轮保证连贯。
Memory Card保留关键事实、风险信号和待追问线索。
State Machine游标指明推进方向。
Compact & Inject (防爆 Token)
Context Next将载荷维持在可控响应窗口。
Event Sourcing持久化写入 DB 支持重启恢复。
长面试遗忘例子

第 3 轮说过的权限模块，第 25 轮还能接回来

第 3 轮小林说：“我做过 React 后台系统，主要负责权限模块和表格性能优化。”如果只看最近几轮，第 25 轮可能已经忘记权限模块还没深挖。

{ "candidate_facts": ["负责过权限模块", "做过表格性能优化"], "risk_signals": ["权限模块个人贡献边界不清楚"], "open_threads": ["追问角色、资源、菜单权限和按钮权限模型"] }
第 25 轮追问：前面你提到权限模块还没展开，当时角色、资源、菜单权限和按钮权限之间是怎么建模的？

📉 拒绝“无限填鸭”神话

动辄几万 Token 的全量投喂会增加延迟和注意力噪声。这里通过 Memory Compaction 管线，把传递给模型的上下文尽量控制在留有输出余量的预算区间。

🤖 Summary Agent 的降级边界

如果配置允许，Summary Agent 才会参与梳理，生成语义更自然的卡片。但如果该 Agent 超时或输出异常，系统不等待，直接回退到底层的确定性 memory card，降低主链路中断风险。

重启恢复例子

checkpoint 不能只放内存

面试进行到第 18 轮，系统把压缩后的上下文写入 agent_events。后端重启后，内存没了，但可以从最新的 context_compacted event 恢复。

{ "event_type": "context_compacted", "payload": { "context_version": 3, "last_turn_no": 18, "candidate_facts": ["负责过权限模块", "优化过三万行表格渲染"], "open_threads": ["追问权限模型", "追问虚拟滚动边界问题"] } }
大白话：面试官的临时草稿不能只放脑子里，要存到系统日志里，服务重启后还能捡回来继续问。
Raw Facts turns / configs Derived metadata / evals Events Log fallback / fails Privacy Boundary (阻断内容泄露) Monitoring API Rates / Counts / Fallback Stat
Raw & Derived沉淀对话原始轨迹与机器客观判定。
Events Log详细追溯 RAG Miss、Fallback 介入等降级事件。
隐私边界：Privacy Masking
Monitoring 沙箱不暴露原句，仅通过计数器展示系统健康信号。
静默失败例子

候选人还在正常面试，但后台评分已经坏了

AI 面试官还能继续问问题，小林也没有感觉异常。但 Evaluation Agent 因为 JSON 解析失败，连续多轮没有写入 turn_evaluations。

{ "evaluation": { "coverage_rate": 0.35, "failure_rate": 0.42, "evaluation_failure_event_count": 8 }, "alerts": ["evaluation_failure_rate_high", "evaluation_coverage_rate_low"] }
大白话：候选人看到“面试还能继续”，但系统知道“后台评分链路已经退化”。

👁️‍🗨️ 看健康，不看隐私

监控层只向上游 API 暴露 rag_missed_count 或 fallback_success_rate，帮助工程师发现“静默失败”，但不返回候选人简历文本、聊天内容、报告正文或 hidden memory。

🗄️ 为什么不用 Redis？

在核心架构选型上，如果把 checkpoint 只存在易失性 Redis 中，实例重启或缓存丢失后就可能无法恢复关键上下文。所以 ProView 当前将关键变迁写入 agent_events 作为 Single Source of Truth，保证关键状态可追溯。未来 Redis 会作为缓存、队列和协调层接入，但不替代数据库。

RAG 监控例子

没命中题库，不等于系统失败

用户填写“AI Agent 应用工程师”，知识库暂时没有匹配题库。系统记录 missed，但仍用 JD 关键词和通用工程能力继续问。

{ "event_type": "rag_retrieval_missed", "payload": { "stage": "opening", "job_title_matched": false, "questions_count": 0, "scripts_count": 1, "duration_ms": 42 } }
大白话：RAG miss 说明知识库覆盖不够，不是面试链路坏了。事件积累多了，就知道哪些岗位需要补题库。
Turns Metadata Evals DB Memory Report Agent 云端大模型汇聚推导 Final Report Rule Fallback 如果 LLM 异常，基于 Evals 生成基础报告
碎片化证据抓取散落在底层的几十次 Turn 评分。
Aggregation (拒绝盲猜)
Report Agent基于实锤证据按维度拼装。
Fallback 保底大模型接口崩溃，提取客观分生成图表。
报告证据例子

报告不是总结聊天，而是整理全过程证据

面试结束后，Report Agent 聚合每轮沉淀下来的事实和评分，而不是把完整聊天记录交给模型凭印象写。

第 4 轮：小林提到虚拟滚动，但没有指标 第 5 轮：补充三万行数据，首屏 2.8s -> 900ms 第 8 轮：说明 Chrome Performance 定位 DOM 节点过多 第 12 轮：权限模块只说明页面实现，对资源模型解释不充分 报告片段： 性能优化：8/10 证据：能说明三万行场景、虚拟滚动、接口分页和量化结果 风险：动态高度、滚动白屏、缓存一致性说明不足
大白话：报告像整理全过程面试官笔记，不是最后让模型凭感觉写评价。

报告基于证据聚合

报告不走“把完整聊天记录发给大模型自由总结”的路径。关键结论会尽量关联到中途记录的 turn_evaluations。证据不足时，系统标记“信息不足”，避免给出过度判断。

🛬 主报告失败时的保底路径

假设最终写报告时大模型 API 异常，系统不会只返回报错。依赖前期的 Evaluations 数据结构，Fallback 机制可以利用预设模板，通过查表生成一份基础但可用的数据指标报告。

Fallback 报告例子

主报告 LLM 失败，也能拿到基础报告

如果最终报告生成时云端 LLM 失败，系统基于 turn_evaluations 生成模板化报告。

{ "report_source": "structured_fallback", "summary": "主报告生成失败，系统基于过程评分生成基础报告。", "dimensions": [ { "dimension": "性能优化", "avg_score": 8, "evidence_count": 3 }, { "dimension": "问题定位", "avg_score": 7, "evidence_count": 2 } ] }
大白话：这份报告不一定华丽，但它仍然来自真实过程评分，用户不会只看到一个报错。

高并发、高可用、高稳定性演进计划

这部分明确区分当前本地优先架构、Backend V1 Freeze 后增强，以及未来 Cloud / SaaS 生产化目标。当前版本不宣称已经完成高并发云端部署。

当前本地优先架构

  • Electron + Flask + SQLite，适合本地桌面端和单用户场景。
  • Direct SQLite structured source 保存 turns、metadata、evaluations、agent_events。
  • 进程内上下文缓存只做加速，agent_events 是 checkpoint 恢复事实源。
  • Evaluation、Memory、Report、Monitoring 作为 sidecar 增强链路，失败不阻塞下一问。

Backend V1 Freeze 后增强

  • 真实短面试 smoke：确认 structured turns、metadata、evaluations、final report evidence。
  • 长面试 compaction smoke：验证 context_compacted event、latest mirror、rehydrate 和去重写入。
  • Monitoring / Learning endpoints smoke：只返回聚合指标和人工审核候选建议。
  • Learning LLM staging smoke：默认关闭，异常 fallback，不影响面试。

Cloud / SaaS 生产化目标

  • Flask API 无状态化，PostgreSQL 作为云端权威事实源。
  • Redis 承担 session cache、prompt cache、agent queue、distributed lock。
  • Agent Worker Pool 处理 Evaluation、Summary、Report，配合 retry 和 dead letter queue。
  • 模型 provider fallback、限流、熔断、超时、健康检查、备份和恢复演练。

高并发规划

  • API 无状态化，SSE 连接治理。
  • Redis 缓存 session context、prompt context 和 RAG top chunks。
  • Agent 任务队列削峰，worker pool 水平扩展。
  • LLM 调用并发限制，同一 session_id 使用分布式锁避免重复生成下一问或报告。

高可用规划

  • PostgreSQL 是权威事实源，Redis 只做缓存和协调层。
  • 数据库备份、恢复演练和 API health check。
  • 多模型 provider fallback，报告生成 fallback。
  • Summary Agent 默认关闭或短超时，Monitoring 失败不影响主流程。

高稳定性规划

  • timeout、retry、idempotent upsert、fallback report。
  • context checkpoint rehydrate，避免后端重启后丢关键上下文。
  • evaluation coverage、RAG hit/miss/failure、report success/fallback 监控。
  • 全量 unittest、真实流程 smoke、长面试故障演练。

隐私与安全边界

  • Candidate UI 不展示 hidden metadata、score、evidence 或 checkpoint。
  • Monitoring 只返回 counts、rates、categories、status、alerts。
  • Learning suggestions 必须 human review，不自动改 Prompt / Rubric / RAG / 题库 / HR script。
Monitoring / Learning 明确不返回的内容

不返回候选人回答、问题原文、报告正文、evidence 原文、suggestion 原文、hidden memory、checkpoint payload、RAG query 或 RAG document content。它们只读安全聚合投影，用来诊断系统健康和生成可审核的改进建议。

按架构层拆分的下一步 Roadmap

这里不照搬升级计划的 Phase，而是映射到架构层，方便面试时说明“当前已完成什么、下一步为什么做这些”。

Data Facts Layer

数据事实层

  • Backend V1 freeze，完成真实短面试 smoke。
  • 验收 structured turns / metadata / evaluations 和 final report evidence schema。
  • 设计 Supabase / PostgreSQL structured migration。
  • 远程表主键、唯一约束、索引、隐私字段隔离和 Direct SQLite 返回 shape 对齐。
RAG Layer

RAG 层

  • 建立 100 到 300 条评估 query，覆盖面试出题和报告场景。
  • 记录 RAG query log、retrieved items 和 context packing 结果。
  • 建立多策略实验框架：规则 rerank -> cross-encoder rerank -> offline LLM rerank。
  • 控制 token、去重、保留 source id，低质 chunk 标记 suspicious / quarantine。
Memory Layer

Memory 层

  • 长面试 context compaction smoke，验证 context_compacted event 和 latest.json 镜像。
  • 验证后端重启后 rehydrate，同一 latest answered turn 不重复写 checkpoint。
  • Summary Agent staging，评估独立 client/config 的生产化必要性。
  • 未来引入 memory chunk embedding，并按当前回答召回相关 memory chunks。
Monitoring / Learning

Monitoring / Learning 层

  • Monitoring endpoints smoke，Learning signal-summary smoke。
  • Learning suggestions staging，Operator UI 可选。
  • 只展示 aggregate monitoring / learning，建议进入审核队列。
  • 维护 approved / rejected / archived 状态和 prompt / rubric / RAG change proposal tracking。
Production Layer

生产化层

  • PostgreSQL 云端权威事实源，Redis session cache / prompt cache / queue / lock。
  • Agent worker pool、retry queue、dead letter queue。
  • 模型 provider fallback、限流、熔断、SSE 连接治理。
  • 压测、告警、灰度发布、数据库备份和恢复演练。