OpenViking 如何用真实问答逐轮验证 VikingBot 反馈指标链路真的在变【免费下载链接】OpenVikingSelf-evolving Context Database for AI Agents. Unify Agent Memory, Knowledge RAG and Skills.项目地址: https://gitcode.com/GitHub_Trending/op/OpenVikingOpenViking 把 VikingBot 的反馈指标接到 Prometheus 和 Grafana 后一个自然的疑问是链路只是“搭起来了”还是真实问答发生时指标真的在变这篇文档面向已经跑通OpenViking - /metrics - Prometheus - Grafana链路的环境用一轮轮真实问答普通提问、点赞、点踩、追问、长间隔 follow-up、channel 请求逐轮触发openviking_feedback_*指标并在 Prometheus / Grafana 中核对变化是否符合预期。完整操作路径参考 docs/zh/guides/12-vikingbot-metrics-validation.md。适用前提OpenViking Server 已启动并且启用了server.observability.metrics.enabledtrueVikingbot 已通过openviking-server --with-bot启动未启用 Bot 时/bot/v1/*端点返回503curl http://127.0.0.1:30300/bot/v1/health返回200curl http://127.0.0.1:30300/metrics能返回 Prometheus exposition 文本Prometheus 已经能抓到 OpenVikingGrafana 已经连上 Prometheus。如果使用仓库自带的 Linux localhost compose 方案默认地址是Prometheushttp://127.0.0.1:30909、Grafanahttp://127.0.0.1:13000、OpenVikinghttp://127.0.0.1:30300。链路本身的搭建方法见 docs/zh/guides/11-grafana-prometheus.md本文只讲链路搭好之后的逐轮验收。先确认指标口径为什么不能当普通 counter 看当前仓库里Vikingbot 反馈相关指标不是在线单调累加 counter而是scrape-time snapshot gaugePrometheus 每次抓取/metrics时FeedbackCollector会扫描bot/sessions/*.jsonl从持久化 session 的metadata.feedback_events和metadata.response_outcomes里重新聚合一份最新快照。这决定了验证方法适合看“当前总量 / 占比 / 按 channel 分布”适合直接看当前值或短时间内的阶梯变化不建议优先看rate()查询时优先过滤valid1。如果看到的是valid0说明当前样本是 fallback/stale 快照collector 本次刷新失败暴露的是上一次成功快照不应作为主验证结果。可以先在 Prometheus 或 Grafana Explore 里执行{__name__~openviking_feedback.*}建议每组用例都使用全新的session_id这样更容易看出单次操作带来的阶梯变化。第 0 步记录基线指标发问答之前先确认基础链路指标是活的并记下反馈指标的基线值后面每轮都拿它们做对比。基础链路查询openviking_service_readiness{valid1}预期返回1。openviking_component_health{valid1}预期至少能看到queue、vikingdb等 component正常情况下大多数值为1。openviking_queue_pending预期通常为0或较小值如果此时已经长期大于0后面做问答验证时要区分“新流量触发”还是“原本就有积压”。openviking_vikingdb_collection_vectors{valid1}预期至少存在一部分 collection 样本。数值不一定在本次验证中变化但它能证明这类状态指标已经被 Prometheus 抓到。openviking_model_usage_available{valid1}可能看到model_typevlm、embedding、rerank值为1表示对应统计当前可用。反馈快照基线逐项记录openviking_feedback_sessions_scanned_total{valid1}openviking_feedback_responses_total{valid1}openviking_feedback_events_total{valid1}已有历史 bot session 的环境这些值通常大于0全新环境也可能是0。建议同时记下responses_with_feedback_total、thumb_up_total、thumb_down_total、positive_outcomes_total、negative_outcomes_total、reasked_outcomes_total、resolved_outcomes_total、follow_up_without_feedback_outcomes_total都加valid1过滤的当前值。第 1 步发一条正常问题验证会话落盘与响应计数这一轮不验证反馈只确认/bot/v1/chat链路和会话持久化正常。curl -sS -X POST http://127.0.0.1:30300/bot/v1/chat \ -H Content-Type: application/json \ -d { session_id: realcase-01-chat, user_id: metrics-validation-user, message: 请用一句话介绍 OpenViking控制在 20 个字以内。 }返回体形态文档示例{ session_id: metrics-validation-session-a, response_id: response_id, message: ... }返回应包含session_id、response_id且message非空。然后观察openviking_feedback_responses_total{valid1}预期相比第 0 步基线增加1如果 scrape 还没刷新等 15-30 秒再看一次。全新 session 文件也可能让openviking_feedback_sessions_scanned_total{valid1}增加1。这一轮中events_total、thumb_up_total、thumb_down_total、responses_with_feedback_total以及各类 outcome total 通常不应直接增加——只发生了一次普通问答没有显式 feedback也没有 follow-up。第 2 步一次 thumb_up验证正向反馈链路这是最推荐先做的主路径因为现象最稳定。发起聊天curl -sS -X POST http://127.0.0.1:30300/bot/v1/chat \ -H Content-Type: application/json \ -d { session_id: realcase-02-thumb-up, user_id: metrics-validation-user, message: 帮我总结一下 OpenViking 的主要作用。 }记录返回里的response_id后续反馈命令中的response_id占位符都替换成这个真实值。提交点赞curl -sS -X POST http://127.0.0.1:30300/bot/v1/feedback \ -H Content-Type: application/json \ -d { session_id: realcase-02-thumb-up, response_id: response_id, feedback_type: thumb_up, feedback_text: helpful }反馈返回文档示例应包含accepted: true和对应的response_id、feedback_type{ accepted: true, response_id: response_id, session_id: metrics-validation-positive, feedback_type: thumb_up, feedback_delay_sec: 1.234, timestamp: ... }重点查询openviking_feedback_events_total{valid1}openviking_feedback_thumb_up_total{valid1}openviking_feedback_responses_with_feedback_total{valid1}openviking_feedback_positive_outcomes_total{valid1}openviking_feedback_one_turn_resolution_rate{valid1}预期变化feedback_events_total、thumb_up_total、responses_with_feedback_total、positive_outcomes_total通常各增加1coverage、thumbs_up_rate、one_turn_resolution_rate可能上升也可能不变取决于历史样本量其中one_turn_resolution_rate会受当前实现把positive_feedback也计入 one-turn resolution 的影响。而thumb_down_total、negative_outcomes_total在这个场景不应增加。查看“这次操作是否已刷新进 Prometheus”最稳妥的做法把查询切到表格视图连续刷新 1-2 次而不是一开始就看时间序列折线。第 3 步一次 thumb_down验证负向反馈链路curl -sS -X POST http://127.0.0.1:30300/bot/v1/chat \ -H Content-Type: application/json \ -d { session_id: realcase-03-thumb-down, user_id: metrics-validation-user, message: 请告诉我 OpenViking 的部署步骤越短越好。 }记录response_id后提交点踩curl -sS -X POST http://127.0.0.1:30300/bot/v1/feedback \ -H Content-Type: application/json \ -d { session_id: realcase-03-thumb-down, response_id: response_id, feedback_type: thumb_down, feedback_text: not helpful }重点查询openviking_feedback_thumb_down_total{valid1}openviking_feedback_negative_outcomes_total{valid1}openviking_feedback_negative_feedback_rate{valid1}预期events_total再增加1thumb_down_total、negative_outcomes_total通常各增加1thumbs_down_rate、negative_feedback_rate可能上升历史样本多时变化可能很小所以仍然优先看 total 是否按预期跳变。thumb_up_total、positive_outcomes_total在这个场景不应增加。这一步完成后你已经验证了三件事/bot/v1/feedback能关联到历史response_id、feedback event 已落入 session metadata、scrape-time 聚合已反映到/metrics。第 4 步10 分钟内追问验证 reasked验证“没有显式反馈、但用户很快追问上一条回答被判定为reasked”。第一轮curl -sS -X POST http://127.0.0.1:30300/bot/v1/chat \ -H Content-Type: application/json \ -d { session_id: realcase-04-reask, user_id: metrics-validation-user, message: 请解释 OpenViking 的 metrics 是做什么的。 }第二轮不调用/bot/v1/feedback在 10 分钟内用同一个session_id发第二问curl -sS -X POST http://127.0.0.1:30300/bot/v1/chat \ -H Content-Type: application/json \ -d { session_id: realcase-04-reask, user_id: metrics-validation-user, message: 我还是没明白请再具体一点。 }重点查询openviking_feedback_reasked_outcomes_total{valid1}openviking_feedback_reask_rate{valid1}预期reasked_outcomes_total通常增加1responses_total还会因为第二次/chat再增加1但核心判断是“第一条 assistant response 的 outcome 被评估成了reasked”。events_total、thumb_up_total、thumb_down_total、responses_with_feedback_total通常不变因为没有显式 feedback。两个容易踩的边界如果第二次 follow-up 已经超过 10 分钟窗口且没有显式 feedback它会落入follow_up_without_feedback而不是reasked如果这一步看到follow_up_without_feedback_outcomes_total增加先检查是否超时或混入了别的 session 样本reask_rate是基于当前持久化 session 快照重新聚合的占比适合看“是否不下降、是否出现阶梯变化”。第 5 步超过 10 分钟再追问验证 follow_up_without_feedbackcurl -sS -X POST http://127.0.0.1:30300/bot/v1/chat \ -H Content-Type: application/json \ -d { session_id: realcase-05-followup-no-feedback, user_id: metrics-validation-user, message: OpenViking 和普通向量数据库有什么关系 }等待 assistant 回复后至少 10 分钟再用同一个session_id发 follow-up不调用/bot/v1/feedbackcurl -sS -X POST http://127.0.0.1:30300/bot/v1/chat \ -H Content-Type: application/json \ -d { session_id: realcase-05-followup-no-feedback, user_id: metrics-validation-user, message: 那你能再举一个更具体的例子吗 }重点查询openviking_feedback_follow_up_without_feedback_outcomes_total{valid1}预期增加1。注意口径区别reasked强调“回答后 10 分钟内被追问”follow_up_without_feedback强调“有 follow-up、没有显式反馈、且 follow-up 超出 10 分钟窗口”两者都依赖后续 user turn。如果增长落在reasked_outcomes_total优先检查第二次提问是否仍在 10 分钟窗口内。第 6 步问完即止把 resolved 作为补充验证curl -sS -X POST http://127.0.0.1:30300/bot/v1/chat \ -H Content-Type: application/json \ -d { session_id: realcase-06-resolved, user_id: metrics-validation-user, message: 请用一句话解释什么是 OpenViking 的 readiness 指标。 }不发 feedback、不追问等待系统完成持久化与后续 outcome 评估再看openviking_feedback_resolved_outcomes_total{valid1}resolved的判定条件是无显式反馈、没有新的 user follow-up、该 response 被 outcome evaluator 评估为已解决。它依赖后续 outcome 评估时机出现时间和幅度都不如显式反馈稳定所以短时间没有跳变不一定表示链路异常这一步失败时不要优先判定系统有问题仍以第 2、3、4 步的结果作为主验收依据。第 7 步可选按 channel 验证 openviking_feedback_channel_*前提bot 配置中已启用channel_iddemo对应的bot_apichannel。不确定有哪些可用channel_id时先查看 bot 配置文件里已启用的bot_apichannel 定义配置不存在时对应请求会返回404 Channel channel_id not found。注意必须使用POST /bot/v1/chat/channel普通POST /bot/v1/chat不会根据channel_id自动切到bot_api路由。curl -sS -X POST http://127.0.0.1:30300/bot/v1/chat/channel \ -H Content-Type: application/json \ -d { session_id: realcase-07-channel-demo, user_id: metrics-validation-user, channel_id: demo, message: 请简单介绍一下 OpenViking。 }记录返回的response_id再带同一个channel_id提交反馈curl -sS -X POST http://127.0.0.1:30300/bot/v1/feedback \ -H Content-Type: application/json \ -d { session_id: realcase-07-channel-demo, response_id: response_id, channel_id: demo, feedback_type: thumb_down, feedback_text: not helpful }对照 channel 维度指标openviking_feedback_channel_events_total{channelbot_api__demo,valid1}openviking_feedback_channel_thumbs_down_rate{channelbot_api__demo,valid1}openviking_feedback_channel_negative_outcomes_total{channelbot_api__demo,valid1}openviking_feedback_channel_events_total{valid1}预期能看到channelbot_api__demo这一组样本该 channel 下的events_total、negative_outcomes_total随这次问答和负向反馈跳变其他无关 channel 的样本不应因此跳变。channel 下的 rate 类指标在历史样本较多时变化可能不明显验收优先看 total 是否跳变再看 rate 方向是否合理。最小验收标准与常见误判如果只做一次最小人工验收文档给出的“通过”标准是这四项openviking_service_readiness{valid1}为1一次thumb_up后openviking_feedback_events_total{valid1}和openviking_feedback_thumb_up_total{valid1}增加一次thumb_down后openviking_feedback_thumb_down_total{valid1}和openviking_feedback_negative_outcomes_total{valid1}增加一次 10 分钟内 follow-up 后openviking_feedback_reasked_outcomes_total{valid1}增加。四项通过基本就能说明bot 会话已持久化、feedback/outcome 已写入 metadata、/metrics已成功聚合反馈快照、Prometheus / Grafana 已能正确看到这批指标。验收过程中几个容易误判的现象刚发完/chat某些反馈指标没变反馈类指标来自metadata.feedback_events和metadata.response_outcomes只有普通聊天、还没有显式 feedback 或 follow-up 时不是所有反馈指标都会立刻动。total 变了但 rate 不明显它们是 snapshot gauge 而非面向rate()设计的 counter优先看当前值、表格视图或短时间范围里的阶梯变化。只看到valid0collector 本次刷新失败暴露的是上一次成功快照主验证优先使用valid1valid0持续出现说明该探针不可完全信任。channel 维度没有出现bot_api__demo依次检查是否误用了POST /bot/v1/chat而不是POST /bot/v1/chat/channel、请求里是否带了channel_id、bot 配置里是否真的启用了该bot_apichannel。指标定义与valid标签的完整说明见 docs/zh/concepts/12-metrics.md/bot/v1/chat、/bot/v1/feedback的请求字段和响应结构见 docs/zh/api/24-vikingbot.mdVikingBot 与 OpenViking 的一体启动配置见 docs/zh/guides/17-vikingbot.md。【免费下载链接】OpenVikingSelf-evolving Context Database for AI Agents. Unify Agent Memory, Knowledge RAG and Skills.项目地址: https://gitcode.com/GitHub_Trending/op/OpenViking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考