Local Deep Research 指标仪表盘完全指南Token 用量分析、增强数据收集与十项能力演进路线【免费下载链接】local-deep-research~95% on SimpleQA (e.g. Qwen3.6-27B on a 3090). Supports all local and cloud LLMs (llama.cpp, Ollama, Google, ...). 10 search engines - arXiv, PubMed, your private documents. Everything Local Encrypted.项目地址: https://gitcode.com/GitHub_Trending/lo/local-deep-research本文围绕 dashboard-improvements.md 这份活规格文档展开系统梳理 Local Deep Research 指标仪表盘已落地的核心分析能力、增强数据收集机制以及时间序列分析、成本分析、实时监控等十项待办增强提案并深入到src/local_deep_research/metrics/与src/local_deep_research/database/models/metrics.py的源码层验证文档所述功能与真实实现的对应关系。读完本文你将掌握仪表盘的完整功能矩阵、各筛选器与 Token 追踪的底层数据链路并了解该模块后续演进的优先级与成功度量方式。一、功能全景仪表盘当前已实现的四大能力块依据 dashboard-improvements.md 的Current State章节指标仪表盘入口为/metrics主模板见 metrics.html目前已经落地了四类能力覆盖看得见的 UI 呈现与看不见的数据采集两条链路。1.1 核心分析Core Analytics仪表盘首页通过一组摘要卡片给出研究活动的全局视图Total tokens所选时间范围内所有 LLM 调用消耗的输入 输出 Token 总量Total researches在时间范围内产生过 LLM Token 消耗的研究会话数量Avg response timeLLM 调用的平均响应时间源码层以毫秒记录response_time_ms字段在 UI 上转换为秒显示可读性更好Success rateLLM 调用成功的百分比用于识别慢或异常故障的模型配置。其中Total Tokens Used 卡片是可展开的ldr-expandable-card点击或回车均可触发展开后呈现Average每次研究平均输入/输出/总 Token与Total Usage全部会话累计输入/输出/总 Token两组细分数据两组数据均以 Input / Output / Total 三列展示。1.2 双过滤系统时间范围 × 研究模式仪表盘头部提供了两套互不干扰的过滤器切换后前端实时刷新无需整页重载过滤器可选值Time Range30D默认、7D、3M、1Y、AllResearch ModeQuick Summary、Detailed、All值得指出的是模板中 metrics.html 的默认高亮为30d与文档中7D, 30D, 3M, 1Y, All的枚举顺序略有出入文档按 7D 起排模板以 30D 为默认两者覆盖的时段集合是一致的。时间范围在服务端的语义由 query_utils.py 中的PERIOD_DAYS_MAP统一定义它同时兼容主仪表盘3m/1y与独立链接分析页90d/365d两套 UI 词汇所有 metrics 端点共享同一套口径PERIOD_DAYS_MAP { 7d: 7, 30d: 30, 3m: 90, 90d: 90, 1y: 365, 365d: 365, all: None, # all 表示不设时间上限 }get_period_cutoff()基于当前 UTC 时间减去对应天数得到截止时间get_time_filter_condition()将其转换为 SQLAlchemy 的时间列过滤条件未知的 period 字符串默认回退到 30 天。1.3 高级 Token 分析Advanced Token AnalyticsPer-research averages单次研究会话的平均输入、输出与总 Token 消耗Total usage breakdown跨所有会话的完整 Token 消耗构成Model usage analysis按模型拆分的详细用量包含 Token 数与调用次数Time-series visualization基于时间戳的 Token 消耗趋势以交互式图表呈现文档明确标注该部分为Partially Implemented即基础时间序列可视化已完成。1.4 用户体验改进UX ImprovementsInteractive tooltips关键指标旁均带data-tooltip提示如 Total input output tokens consumed by all LLM calls in the selected time period并提供Understanding Metrics帮助面板含 4 步引导与隐私说明Responsive filtering切换过滤器时仪表盘数据实时刷新Clean visual design可展开卡片配平滑动画toggleTokenDetails() chevron 图标翻转Empty state handling无数据时优雅降级而非白屏或报错。二、增强数据收集仪表盘背后的数据链路文档强调的Enhanced Data Collection并非 UI 功能而是 Token 追踪的底层数据丰富化。这一点在源码中得到充分印证。2.1 调用栈跟踪Call Stack Trackingtoken_counter.py 中的TokenCountingCallback继承 LangChain 的BaseCallbackHandler是 Token 采集的核心实现。它在每次 LLM 调用时捕获calling_file、calling_function与简化调用栈帧数上限由_CALL_STACK_FRAME_LIMIT 5控制——这个深度足以暴露 LDR 调用点及其上方的 LangChain/LangGraph 帧又不会让持久化列被淹没。源码中一个值得注意的工程细节回调实例在整个研究会话中被共享见llm_config.py的wrap_llm而单次会话可能驱动多条重叠链如 agent judge 子策略因此调用元数据不再存实例属性而是按 LangChain 的run_id存入self._call_meta字典并在on_llm_end/on_llm_error时移除避免重叠运行互相污染调用栈。这正是函数级 LLM 用量跟踪得以准确落地的关键实现。2.2 研究模式与阶段跟踪Research Mode Phase Tracking文档提到的Separate analytics for quick vs detailed research types与Token usage by research phase and search iteration对应TokenUsage表中的research_mode、research_phase、search_iteration字段。数据库模型见 metrics.pyresearch_modestandard/deep/expert等模式标记UI 过滤的 quick/detailed 即映射到该列research_phase研究阶段init、setup、iteration、question_generation、parallel_search、report_generation、complete、error 等search_iteration对应的搜索迭代轮次search_engines_plannedJSON 数组与search_engine_selected规划与最终选用的搜索引擎。查询侧则由 query_utils.py 的get_context_overflow_truncation_summary()统一聚合截断率与 Token 摘要字段——它被/metrics/api/metrics与/metrics/api/context-overflow两个端点共用保证同一时间窗口内两处数字不会打架。2.3 响应时间与成功状态TokenCountingCallback在on_llm_start记录self.start_time time.time()在on_llm_end计算response_time_ms并记录success_statussuccess/error/timeout与error_type。这些值落库到response_time_ms、success_status、error_type列成为仪表盘Avg Response Time与Success Rate卡片的直接数据来源。2.4 超出文档的额外能力上下文溢出检测与 Ollama 原始指标从源码看当前实现已超出原文档Enhanced Data Collection的列举范围这属于文档未提及、但源码可确认的事实上下文溢出检测TokenUsage表包含context_limit、context_truncated、tokens_truncated、truncation_ratio四列用于识别因上下文窗口上限num_ctx / max tokens导致的截断并估算损失的 Token 比例模板头部也提供了独立的/metrics/context-overflow入口Ollama 原始指标ollama_prompt_eval_count、ollama_eval_count、ollama_total_duration纳秒、ollama_load_duration、ollama_prompt_eval_duration、ollama_eval_duration等列保留了 Ollama API 的原始返回便于本地模型场景下做精确的耗时/评估数调试。此外TokenUsage表定义了 4 个复合索引idx_token_research_timestamp、idx_token_model_timestamp、idx_token_operation_timestamp、idx_token_research_phase对应文档Technical Considerations中Create indexes for performance queries的要求且模型层已内置prompt_cost/completion_cost/total_costUSD三列——成本分析的基础设施其实已在数据层就绪详见下文第五节。三、成本分析基础设施pricing 子模块的现状文档将Cost Analysis列为第一优先级的待办提案但仓库中已存在 metrics/pricing/ 子模块包含三个文件cost_calculator.py成本计算工具pricing_fetcher.py定价数据获取pricing_cache.py定价缓存。结合 metrics.py 中的成本列与仪表盘顶部的 Cost Analytics导航入口/metrics/costs可以判断Token 转化为美元成本的核心计算与展示链路在仓库中已具备基础实现对应 metrics-dashboard.md 中GET /metrics/api/pricing与GET /metrics/api/pricing/model_name端点。文档中Add pricing configuration for different models / Create cost calculation utilities两项实施步骤从目录结构与导航入口看已完成或接近完成真正待补的是Budget management interface预算管理界面与Cost-based alerts成本告警两大部分。如果你要在本地查看成本功能可在仪表盘顶部点击 Cost Analytics 进入。关于成本的口径metrics.html 的帮助面板给出了重要前提本地模型Ollama显示 $0.00因为它们在自有硬件上运行——成本分析的适用前提是云端付费模型OpenAI、Anthropic、Google 等。四、十项待办增强提案从状态标记到实施路径文档的核心章节是Pending Enhancement Proposals共 10 项提案每项都带明确的完成度标记✅ Completed / Remaining与实施步骤。以下是完整继承并补充说明的清单。4.1 时间序列分析Partially Implemented已完成基础 Token 消耗时间序列可视化、日期范围选择器7D/30D/3M/1Y/All、Token 计数器中的时间戳查询。待补研究频率模式识别高峰时段、性能趋势监测效率改进/劣化、季节性分析、按小时/天的热力图用量强度可视化。4.2 成本分析见第三节核心目标是把 Token 数转化为可执行的财务洞察Token costs per model按模型定价计算实际花费Cost breakdown by research展示每次查询的真实美元消耗Budget tracking设置支出上限并监控、触发告警Cost efficiency metrics研究投入的 ROI 分析Projected costs基于用量趋势估算未来支出。实施步骤文档原文供开发参考添加不同模型的定价配置 → 创建成本计算工具 → 构建预算管理界面 → 添加基于成本的告警与通知。4.3 质量与性能指标Partially Implemented已完成研究成功率完成 vs 失败、平均响应时间秒、错误率跟踪。待补平均研究时长整个研究会话的完成时间分析、Token 效率每 Token 的结果质量、查询复杂度分析简单 vs 复杂查询的资源占用、质量评分机制自动化研究质量评估。4.4 单次研究深度剖析Partially Implemented已完成最近研究列表可点击含 Token 数与时间戳、按阶段的 Token 跟踪搜索/分析/综合阶段、模型利用率跟踪。待补Per-Research 页面/metrics/research/{id}包含Token 用量时间线研究过程中的 Token 消耗流可视化搜索引擎性能不同引擎对本次查询的有效性成本分析完整的财务拆解效率评分与同类研究的性能评级对比。4.5 比较分析Not Started目标用数据驱动优化决策。包括模型性能对比跨模型的效率指标、研究类型分析学术 vs 一般查询模式、A/B 测试框架对比不同研究策略、基准对照与历史平均值对比、最佳实践识别标出最高效的路径。实施步骤构建对比可视化工具 → 添加研究分类系统 → 创建 A/B 测试基础设施 → 设计基准算法。4.6 资源优化洞察Not Started自动化成本优化建议浪费检测识别失败的高成本查询、模型推荐为相似任务推荐更便宜的替代模型、用量异常检测发现需要关注的异常模式、优化建议可执行的成本削减洞察、效率告警性能劣化时通知。实施步骤创建异常检测算法 → 构建推荐引擎 → 添加自动化告警系统 → 设计优化建议框架。4.7 高级可视化Not Started增强型可视化分析热力图按天/周时段的用量模式、流程图Token 在研究阶段间的流转、对比图并排效率对比、交互式仪表盘下钻能力、自定义可视化构建器用户可配置图表。实施步骤集成高级图表库 → 创建交互式可视化组件 → 构建自定义图表配置工具 → 添加仪表盘个性化功能。4.8 导出与报告Not Started数据可移植性与外部集成CSV/PDF 导出、定时报告每周/每月自动摘要、自定义日期范围分析、API 端点对接外部分析工具、邮件通知自动报告投递。实施步骤为现有端点添加导出功能 → 创建报告生成系统 → 构建调度基础设施 → 设计外部 API 接口。4.9 实时监控Not Started实时系统监控实时 Token 用量、系统健康指标API 响应时间、错误率、资源告警基于阈值的通知、进行中研究监控跟踪研究进度、性能仪表盘实时系统状态。实施步骤添加基于 WebSocket 的实时更新 → 创建系统健康监控 → 构建告警管理系统 → 设计实时仪表盘组件。4.10 增强模型分析Not StartedPer-Model 页面/metrics/model/{model_name}历史用量趋势模型采纳随时间变化、成本效率分析价格/性能对比、任务特定性能不同研究类型的有效性、用量建议何时使用该模型、对比基准与其他模型的性能对比。实施步骤创建模型专属分析页 → 添加任务分类系统 → 构建性能对比工具 → 设计推荐算法。五、技术考量四条横切设计原则文档在提案之后单独列出四组技术考量它们是所有增强提案落地时都必须遵守的约束数据库增强向指标表添加成本跟踪列实现面向时间序列优化的存储为性能查询创建索引这一条在TokenUsage的 4 个复合索引上已落实。前端架构模块化组件设计以保证复用性响应式设计保证移动端可访问大数据集采用渐进式加载。API 设计所有指标数据使用 RESTful 端点大结果集分页高频访问数据加缓存。完整的端点清单可查阅 metrics-dashboard.md包括/metrics/api/metrics/enhanced、/metrics/api/pricing/model、/metrics/api/ratings/id等 20 余个端点。性能优化数据库查询优化客户端缓存策略复杂可视化懒加载。六、2024 年 12 月主要版本一次综合大改文档末尾的Recent Achievements Summary记录了 2024 年 12 月对指标仪表盘的一次全面翻新四个要点与第一、二节的内容一一呼应双过滤系统时间范围7D/30D/3M/1Y/All 研究模式Quick/Detailed/All过滤切换实时更新——与 metrics.html 的模板实现完全一致可展开 Token 分析点击展开的 Token 明细卡片、输入/输出拆分、每次研究平均值 vs 总用量对比、平滑动画增强数据收集带文件/函数上下文的调用栈跟踪、研究阶段与迭代跟踪、以人可读秒数呈现的响应时间、成功率计算与展示——对应TokenCountingCallback与TokenUsage表的全部增强列用户体验提升全仪表盘交互式 tooltip、干净响应式设计、空状态优雅处理、上下文帮助说明。同一时期enhanced-token-tracking.md 还记录了一次关键数据库修复移除了TokenUsage与ModelUsage表上指向不存在的research_history表的外键约束此前导致静默失败改为简单整数字段Token 追踪自此不再因约束错误丢数据。这条修复路径也可作为后续成本列、会话列扩展的参考——当前表结构已采用无外键 复合索引的设计扩展成本跟踪列时无需担心外键迁移问题。七、下一优先级与成功度量文档明确给出基于当前差距的最高价值待办排序Cost Analysis把 Token 用量转化为财务洞察注意第三节说明——定价与计算基础设施已存在重点在预算管理与告警Real-time Monitoring实时系统监控与告警Individual Research Pages单次研究的精细化分析Export and Reporting数据可移植性与自动化报告。最后文档给出四项成功指标可用于评估每一次增强的真实价值User Engagement用户在指标页面的停留时间Decision Impact模型用量模式是否因数据而改变Cost Savings不必要 Token 支出的减少量Efficiency Gains每次成功研究的 Token 消耗比tokens-per-successful-research的改善。八、延伸阅读dashboard-improvements.md本文依据的活规格文档含全部 10 项提案原文enhanced-token-tracking.mdToken 追踪数据采集的详细方案字段清单、SQL Schema、成本计算示例、分阶段实施优先级metrics-dashboard.md仪表盘完整功能说明与全部 REST API 端点参考token_counter.pyTokenCountingCallback核心实现调用栈捕获、响应计时、上下文溢出检测、Ollama 指标metrics.pyTokenUsage/ModelUsage数据模型与索引定义query_utils.py时间范围与模式过滤的唯一事实来源metrics.html仪表盘前端模板双过滤器、可展开卡片、tooltips、帮助面板。补充说明本文对已实现功能的陈述以仓库源码与文档为准对待办提案的表述均继承自原文档规划其完成度以仓库当前实际状态为准开发落地前仍需按文档末尾所述对每项提案评估可行性、用户价值与实现复杂度。【免费下载链接】local-deep-research~95% on SimpleQA (e.g. Qwen3.6-27B on a 3090). Supports all local and cloud LLMs (llama.cpp, Ollama, Google, ...). 10 search engines - arXiv, PubMed, your private documents. Everything Local Encrypted.项目地址: https://gitcode.com/GitHub_Trending/lo/local-deep-research创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考