Z2wen1tao_31/S1W2-Enterprise-Research-Report-Agent

Fork 0

【S1W2 交叉评测】Enterprise Research Report Agent 项目反馈 #1

New issue

Open

opened 2026-05-15 14:58:49 +08:00 by smartresearch2026 · 0 comments

smartresearch2026 commented

2026-05-15 14:58:49 +08:00

企业研报智能体 — 交叉评测报告

1. 项目理解

本项目是一个面向企业研究报告分析场景的 RAG + Agent 智能体系统。核心功能链路为：PDF 上传 → 解析切分 → Embedding 入库 → 向量检索 / 联网调研 → LLM 生成问答 / 报告 / 企业评分。

技术栈：FastAPI（后端）+ React + Vite + Ant Design（前端）+ SQLite（元数据与历史）+ Milvus / Memory（向量库）+ LangChain + LangGraph（工作流编排）+ PyMuPDF（PDF 解析）+ DeepSeek API / mock（LLM）。支持多知识库管理、文件生命周期、多轮对话、自动报告生成（Markdown / PDF 导出）、表格抽取与财务指标识别、六维度企业能力评分、DuckDuckGo 联网调研，以及完整的 mock 降级路径保证离线可演示性。

项目定位为学习、研究、投研辅助和文档分析演示工具，架构清晰、功能闭环完整，代码组织规范。

2. 项目亮点

2.1 全链路降级设计，环境适应性极强

系统在多个关键路径上实现了优雅降级：

Embedding：sentence-transformers → hash embedding（BLAKE2b 哈希分桶），网络不可达时自动切换，且 hash 结果经过 L2 归一化，与向量检索兼容。
LLM：DeepSeek API → mock 模式，mock 模式下各功能（问答、报告、评分）均能返回有意义的结构化结果，用于离线演示。
向量库：Milvus → MemoryVectorStore，Milvus 不可用时测试和演示不受影响。
联网搜索：DDGS 库 → 自建 HTML Parser 直接爬取 DuckDuckGo HTML 页面 → 空结果静默降级，不阻塞主流程。
LangGraph：真实 LangGraph → 手写 StateGraph fallback，保证无 langgraph 依赖时也能线性执行节点链。

这套降级体系在同类项目中非常少见，体现了工程成熟度。尤其是自建的 DuckDuckGo HTML Parser（DuckDuckGoHtmlParser），在 ddgs 库安装失败时仍能通过 httpx + html.parser 完成任务，且额外实现了 unwrap_duckduckgo_url 解析重定向 URL，细节到位。

2.2 企业能力评分的六维度体系设计

ScoreService / ScoreGraphRunner 构建了一个从 财务健康与盈利质量、成长性与业务韧性、行业地位与竞争壁垒、创新能力与研发投入、治理合规与风险控制、外部舆情与可持续发展 六个维度的评分框架：

每个维度有独立的检索 query、对应的财务指标集合和权重。
每个维度独立从向量库检索证据、从联网获取公开资料、从结构化指标中抽取相关项。
最终加权汇总、输出评级（A-E）、置信度、关键事实和数据缺口说明。
维度配置以常量 DIMENSIONS 形式集中管理，易于扩展和调整。

这一设计将"主观评分"问题转化为可追溯、可解释的多维度证据聚合问题，体现了投研方法论在产品中的落地思考。

2.3 自建 Markdown → PDF 渲染链

report_exporter.py 没有依赖 markdown2、weasyprint 等第三方库，而是手写了完整的 Markdown → HTML → PDF 转换链：

用正则逐行解析 Markdown（标题、段落、无序/有序列表、引用、代码块、表格、粗体/斜体/行内代码），构建 HTML。
用 fitz.Story（PyMuPDF 内置的 HTML→PDF 渲染引擎）将 HTML 渲染为 A4 尺寸 PDF。
附带精心设计的 PDF_CSS（自定义字体大小、颜色、表格样式、代码块背景、引用块左边框等），产出视觉效果专业的投研报告 PDF。

这种自建方案避免了引入重量级依赖（如 wkhtmltopdf），且对输出格式有完全控制权，是一个值得称道的工程决策。

2.4 LangGraph 工作流编排与多会话上下文支持

三条核心工作流均通过 LangGraph 拆分为清晰节点：

问答：validate_scope → load_memory → retrieve_evidence → web_research → generate → persist_result
报告：同链但 mode=report，检索 top_k 自动扩至 12，无证据时返回 400。
评分：validate_scope → collect_internal_metrics → retrieve_dimension_evidence → web_search_tool → score_dimensions → aggregate → persist

其中 load_memory 节点加载最近 8 轮对话历史并注入 LLM 上下文，实现了真正的多轮追问能力。persist_result 节点将答案/报告/评分分别写入 SQLite 并关联证据引用，保证了历史可追溯。

2.5 表格抽取与财务指标自动识别

TableExtractor 不仅用 PyMuPDF find_tables() 抽取 PDF 内嵌表格并转为 Markdown，还实现了：

10 种核心财务指标的模式匹配（营业收入、净利润、归母净利润、毛利率、净利率、经营现金流、资产负债率、ROE、研发费用、研发费用率），中英文关键词均覆盖。
数值解析支持括号负数、千分位逗号、单位识别（亿元/万元/千元/%）。
抽取的指标自动入库，供评分 Agent 按维度分发使用。

这使得上传一份年报 PDF 后，系统不仅能做语义检索，还能自动提取结构化财务数据参与评分，打通了非结构化→结构化的关键桥梁。

3. 当前不足

3.1 企业评分实际为规则引擎，非 LLM 驱动的智能评分

这是最核心的问题。尽管项目标榜"企业能力评分 Agent"，ScoreGraphRunner._score_dimensions() 的实际评分逻辑是：

score = 50 + min(len(evidences), 3) * 8 + min(len(metric_subset), 4) * 5 + min(len(web_references), 2) * 4

本质是一个基于证据数量、指标数量、网络资料数量的简单线性公式（50 分起评，上限 92 分），并未调用 LLM 对证据内容做语义级别的优劣判断。rationale、key_facts、data_gaps 的生成也是模板拼接而非 LLM 分析。

这与 README 中"综合知识库证据、结构化财务指标和联网搜索资料，输出总分、维度分、说明和证据"的描述存在差距——当前实现可以输出这些字段，但"说明"不是基于内容的深度分析，而是计数的模板话术。评分结果虽然可追溯，但缺乏真正的智能分析深度。

3.2 无流式输出，用户体验受限

所有 API 均为一次性返回完整结果的同步/异步模式。对于报告生成这类 LLM 调用场景（可能需要 15-60 秒），用户在前端只能看到 loading 状态等待完整结果。缺少 SSE（Server-Sent Events）或 WebSocket 流式输出机制，前端无法展示逐字生成的过程，这在 2024-2025 年的 AI 应用中是明显的体验短板。

llm_client.py 中使用了 ChatOpenAI，LangChain 本身支持 streaming=True 回调，但并未启用。LangGraph 也支持 stream 模式（逐个节点 yield 状态更新），同样未使用。

3.3 检索仅支持单一向量检索，缺少 Hybrid Search 和 Reranker

当前检索链路是 Embedding → Milvus / Memory COSINE Top-K，纯粹依赖语义向量相似度。对于企业研报场景：

财报中精确的数字、百分比、日期等关键信息，BM25 关键词匹配往往比向量检索更准确。
没有 Reranker（如 BGE-Reranker、Cohere Rerank）对召回结果进行精排，Top-K 质量受 embedding 模型精度影响大。
没有查询改写（Query Rewriting），用户口语化问题直接用作检索 query，与文档语言风格可能存在 gap。
报告的 build_report_query 函数只是在 topic 后面拼接固定关键词串，缺乏动态扩展能力。

README 中已将此列入"后续计划"，但这是影响检索质量的核心瓶颈，在当前版本即应优先考虑。

3.4 前端组件化不足，单文件 1711 行

App.jsx 单文件 1711 行，包含了知识库管理、文档管理、问答面板、报告面板、评分面板、历史记录、会话管理等所有 UI 逻辑和状态。虽然使用了 Ant Design 组件，但缺少：

功能模块拆分（如 KnowledgeBasePanel、ChatPanel、ReportPanel 各自独立组件）
状态管理方案（useState 散落在顶层组件，跨组件通信依赖 props drilling）
自定义 Hook 抽取（如 useKnowledgeBases、useChat、useReports）

随着功能增加，维护成本和 bug 风险将线性上升。

3.5 缺少用户认证与多用户隔离

系统没有引入任何认证机制（JWT、OAuth、Session 等）。所有知识库、文档、对话、报告、评分对任何能访问 API 的人都是全局可见和可操作的。对于文档管理场景，用户通常希望自己的工作空间是私密的。虽然项目文档声明定位为"学习、研究、投研辅助"工具，但若用于团队协作或多用户场景，缺少访问控制是明显的功能缺口。

3.6 SQLite 并发瓶颈

SQLiteStore 使用单一 threading.Lock 保护所有读写操作，包括耗时的 executescript（建表迁移）。虽然对于原型和小规模使用可以接受，但在多用户并发上传 + 问答 + 报告生成的场景下，SQLite 写锁竞争会导致请求串行化。考虑到后端使用 async FastAPI，SQLite 的同步阻塞模型也会限制异步并发的收益。

4. 建议

4.1 评分维度分析接入 LLM，保留规则引擎作为 fallback

优先级：高

当前规则评分提供了可复现的基线，建议在此基础上增加 LLM 评分路径：

mock 模式下保留当前规则评分。
LLM 可用时，将每个维度的 evidences、metrics、web_references 组装为 prompt，让 LLM 输出结构化 JSON（score、rationale、key_facts、data_gaps）。
对 LLM 输出做合法性校验（score 在 0-100 范围），校验失败时 fallback 到规则评分。
这样既保留了"智能体"的内核，又不破坏现有的降级路径。

4.2 实现问答和报告生成的流式输出

优先级：高

后端：利用 LangChain ChatOpenAI 的 streaming=True 回调，将 token 通过 SSE text/event-stream 推送到前端。
前端：使用 EventSource 或 fetch + ReadableStream 接收流式数据，在 Markdown 渲染区域实时追加内容。
报告生成可复用相同机制，前端在报告预览区实时看到章节逐步展开。
对于 LangGraph 工作流，也可以用 graph.stream() 暴露中间节点状态（如"正在检索证据..."→"正在联网调研..."→"正在生成报告..."），让用户感知进度。

4.3 引入 BM25 + Reranker 的混合检索

优先级：中

使用 rank_bm25（纯 Python，无外部依赖）实现 BM25 关键词检索。
向量检索和 BM25 检索各取 Top-K 结果，合并去重后送 Reranker 精排。
可选用 BAAI/bge-reranker-v2-m3（与现有 bge-small-zh 同系列），或轻量级的 ms-marco-MiniLM cross-encoder。
Reranker 可作为可选组件（配置开关），不可用时退化为简单融合排序。

4.4 前端重构：组件拆分 + 状态管理

优先级：中

建议按功能域拆分：

frontend/src/
  components/
    KnowledgeBasePanel/
    DocumentPanel/
    ChatPanel/
    ReportPanel/
    ScorePanel/
    HistoryPanel/
  hooks/
    useKnowledgeBases.js
    useChat.js
    useReports.js
    useScores.js
  contexts/
    AppContext.jsx

引入 zustand（轻量、无 boilerplate）或 React Context + useReducer 管理全局状态（当前知识库、当前文档、侧边栏折叠等），避免深层 props drilling。

4.5 增加报告大纲自定义

优先级：低-中

报告生成前，前端展示默认大纲（基于 system prompt 中的固定结构），允许用户新增/删除/重排章节。
用户确认后，将自定义大纲作为 prompt 的一部分发送给 LLM。
生成后的报告支持多轮修订（"扩展第三章"、"补充风险分析"），复用对话机制或独立的报告修订会话。

4.6 增加文档元数据编辑功能

优先级：低

当前上传时可设置企业名称、年份、报告类型，但上传后不可修改。建议增加：

PATCH /api/documents/{id} 支持修改 company_name、report_year、report_type。
前端在文档列表中增加编辑按钮，弹出表单。

4.7 考虑 SQLite 升级为 aiosqlite 或 PostgreSQL

优先级：低-中

短期方案：将 SQLiteStore 的同步 sqlite3 替换为 aiosqlite，避免阻塞 async 事件循环。
长期方案：若有多用户需求，迁移至 PostgreSQL + asyncpg，利用连接池和行级安全策略。

5. 综合评价

这是一个架构完整、工程实现扎实的企业研报智能体原型项目。以下从多个维度评价：

评价维度	评分	说明
功能完整性	⭐⭐⭐⭐⭐	从 PDF 上传到问答/报告/评分/导出的全链路闭环，知识库管理、历史记录、多会话、联网调研一应俱全
工程鲁棒性	⭐⭐⭐⭐⭐	多层降级设计（Embedding/LLM/向量库/联网搜索）极为出色，mock 模式可离线演示所有功能
代码质量	⭐⭐⭐⭐	目录结构清晰，类型注解覆盖率高，错误处理规范，SQLite schema 迁移机制完善；前端单文件过大是唯一明显短板
技术创新	⭐⭐⭐⭐	自建 MD→PDF 渲染链、六维度评分框架、LangGraph fallback 实现均体现自主工程能力；评分实际为规则引擎扣一星
测试覆盖	⭐⭐⭐⭐	11 个测试文件覆盖核心流程（API、PDF 解析、向量库、Embedding、评分、报告、联网），conftest 用临时目录隔离环境
文档质量	⭐⭐⭐⭐⭐	README + 项目说明文档共 490 行，覆盖项目概述、目标用户、使用场景、技术路线、API 概览、配置说明、常见问题、验证方式
前端体验	⭐⭐⭐⭐	Ant Design 专业控制台风格，三栏布局合理，操作带确认弹窗；缺少流式输出和组件化是主要短板

总体评价：该项目在有限时间内交付了一个远超原型水准的完整系统。降级设计的"防御性编程"思维贯穿始终，使得系统在各种环境限制下都能正常工作，这在 AI 应用开发中是非常宝贵的工程素养。企业能力评分的六维度框架和自建 PDF 渲染链展现了超出 CRUD 层面的技术深度。

主要改进方向集中在：将评分的"智能"从规则驱动升级为 LLM 驱动、实现流式输出提升交互体验、引入混合检索提升检索质量、前端架构重构。这些改进不会改变系统架构，但能显著提升产品的"智能感"和实用价值。

一句话总结：一个"防御性设计拉满、功能闭环完整、降级路径完善"的企业研报 RAG Agent 原型——在工程成熟度上相当出色，若补齐 LLM 驱动评分和流式输出，将具备较强的生产环境可用性。

# 企业研报智能体 — 交叉评测报告 ## 1. 项目理解本项目是一个面向企业研究报告分析场景的 RAG + Agent 智能体系统。核心功能链路为：**PDF 上传 → 解析切分 → Embedding 入库 → 向量检索 / 联网调研 → LLM 生成问答 / 报告 / 企业评分**。技术栈：FastAPI（后端）+ React + Vite + Ant Design（前端）+ SQLite（元数据与历史）+ Milvus / Memory（向量库）+ LangChain + LangGraph（工作流编排）+ PyMuPDF（PDF 解析）+ DeepSeek API / mock（LLM）。支持多知识库管理、文件生命周期、多轮对话、自动报告生成（Markdown / PDF 导出）、表格抽取与财务指标识别、六维度企业能力评分、DuckDuckGo 联网调研，以及完整的 mock 降级路径保证离线可演示性。项目定位为学习、研究、投研辅助和文档分析演示工具，架构清晰、功能闭环完整，代码组织规范。 --- ## 2. 项目亮点 ### 2.1 全链路降级设计，环境适应性极强系统在多个关键路径上实现了优雅降级： - **Embedding**：`sentence-transformers` → hash embedding（BLAKE2b 哈希分桶），网络不可达时自动切换，且 hash 结果经过 L2 归一化，与向量检索兼容。 - **LLM**：DeepSeek API → mock 模式，mock 模式下各功能（问答、报告、评分）均能返回有意义的结构化结果，用于离线演示。 - **向量库**：Milvus → MemoryVectorStore，Milvus 不可用时测试和演示不受影响。 - **联网搜索**：DDGS 库 → 自建 HTML Parser 直接爬取 DuckDuckGo HTML 页面 → 空结果静默降级，不阻塞主流程。 - **LangGraph**：真实 LangGraph → 手写 StateGraph fallback，保证无 langgraph 依赖时也能线性执行节点链。这套降级体系在同类项目中非常少见，体现了工程成熟度。尤其是自建的 DuckDuckGo HTML Parser（`DuckDuckGoHtmlParser`），在 `ddgs` 库安装失败时仍能通过 httpx + html.parser 完成任务，且额外实现了 `unwrap_duckduckgo_url` 解析重定向 URL，细节到位。 ### 2.2 企业能力评分的六维度体系设计 `ScoreService` / `ScoreGraphRunner` 构建了一个从 **财务健康与盈利质量**、**成长性与业务韧性**、**行业地位与竞争壁垒**、**创新能力与研发投入**、**治理合规与风险控制**、**外部舆情与可持续发展** 六个维度的评分框架： - 每个维度有独立的检索 query、对应的财务指标集合和权重。 - 每个维度独立从向量库检索证据、从联网获取公开资料、从结构化指标中抽取相关项。 - 最终加权汇总、输出评级（A-E）、置信度、关键事实和数据缺口说明。 - 维度配置以常量 `DIMENSIONS` 形式集中管理，易于扩展和调整。这一设计将"主观评分"问题转化为可追溯、可解释的多维度证据聚合问题，体现了投研方法论在产品中的落地思考。 ### 2.3 自建 Markdown → PDF 渲染链 `report_exporter.py` 没有依赖 `markdown2`、`weasyprint` 等第三方库，而是手写了完整的 **Markdown → HTML → PDF** 转换链： - 用正则逐行解析 Markdown（标题、段落、无序/有序列表、引用、代码块、表格、粗体/斜体/行内代码），构建 HTML。 - 用 `fitz.Story`（PyMuPDF 内置的 HTML→PDF 渲染引擎）将 HTML 渲染为 A4 尺寸 PDF。 - 附带精心设计的 `PDF_CSS`（自定义字体大小、颜色、表格样式、代码块背景、引用块左边框等），产出视觉效果专业的投研报告 PDF。这种自建方案避免了引入重量级依赖（如 wkhtmltopdf），且对输出格式有完全控制权，是一个值得称道的工程决策。 ### 2.4 LangGraph 工作流编排与多会话上下文支持三条核心工作流均通过 LangGraph 拆分为清晰节点： - **问答**：`validate_scope → load_memory → retrieve_evidence → web_research → generate → persist_result` - **报告**：同链但 mode=report，检索 top_k 自动扩至 12，无证据时返回 400。 - **评分**：`validate_scope → collect_internal_metrics → retrieve_dimension_evidence → web_search_tool → score_dimensions → aggregate → persist` 其中 `load_memory` 节点加载最近 8 轮对话历史并注入 LLM 上下文，实现了真正的多轮追问能力。`persist_result` 节点将答案/报告/评分分别写入 SQLite 并关联证据引用，保证了历史可追溯。 ### 2.5 表格抽取与财务指标自动识别 `TableExtractor` 不仅用 PyMuPDF `find_tables()` 抽取 PDF 内嵌表格并转为 Markdown，还实现了： - 10 种核心财务指标的模式匹配（营业收入、净利润、归母净利润、毛利率、净利率、经营现金流、资产负债率、ROE、研发费用、研发费用率），中英文关键词均覆盖。 - 数值解析支持括号负数、千分位逗号、单位识别（亿元/万元/千元/%）。 - 抽取的指标自动入库，供评分 Agent 按维度分发使用。这使得上传一份年报 PDF 后，系统不仅能做语义检索，还能自动提取结构化财务数据参与评分，打通了非结构化→结构化的关键桥梁。 --- ## 3. 当前不足 ### 3.1 企业评分实际为规则引擎，非 LLM 驱动的智能评分这是最核心的问题。尽管项目标榜"企业能力评分 Agent"，`ScoreGraphRunner._score_dimensions()` 的实际评分逻辑是： ```python score = 50 + min(len(evidences), 3) * 8 + min(len(metric_subset), 4) * 5 + min(len(web_references), 2) * 4 ``` 本质是一个基于证据数量、指标数量、网络资料数量的简单线性公式（50 分起评，上限 92 分），并未调用 LLM 对证据内容做语义级别的优劣判断。`rationale`、`key_facts`、`data_gaps` 的生成也是模板拼接而非 LLM 分析。这与 README 中"综合知识库证据、结构化财务指标和联网搜索资料，输出总分、维度分、说明和证据"的描述存在差距——当前实现可以输出这些字段，但"说明"不是基于内容的深度分析，而是计数的模板话术。评分结果虽然可追溯，但**缺乏真正的智能分析深度**。 ### 3.2 无流式输出，用户体验受限所有 API 均为一次性返回完整结果的同步/异步模式。对于报告生成这类 LLM 调用场景（可能需要 15-60 秒），用户在前端只能看到 loading 状态等待完整结果。缺少 SSE（Server-Sent Events）或 WebSocket 流式输出机制，前端无法展示逐字生成的过程，这在 2024-2025 年的 AI 应用中是明显的体验短板。 `llm_client.py` 中使用了 `ChatOpenAI`，LangChain 本身支持 `streaming=True` 回调，但并未启用。LangGraph 也支持 `stream` 模式（逐个节点 yield 状态更新），同样未使用。 ### 3.3 检索仅支持单一向量检索，缺少 Hybrid Search 和 Reranker 当前检索链路是 `Embedding → Milvus / Memory COSINE Top-K`，纯粹依赖语义向量相似度。对于企业研报场景： - 财报中精确的数字、百分比、日期等关键信息，BM25 关键词匹配往往比向量检索更准确。 - 没有 Reranker（如 BGE-Reranker、Cohere Rerank）对召回结果进行精排，Top-K 质量受 embedding 模型精度影响大。 - 没有查询改写（Query Rewriting），用户口语化问题直接用作检索 query，与文档语言风格可能存在 gap。 - 报告的 `build_report_query` 函数只是在 topic 后面拼接固定关键词串，缺乏动态扩展能力。 README 中已将此列入"后续计划"，但这是影响检索质量的核心瓶颈，在当前版本即应优先考虑。 ### 3.4 前端组件化不足，单文件 1711 行 `App.jsx` 单文件 1711 行，包含了知识库管理、文档管理、问答面板、报告面板、评分面板、历史记录、会话管理等所有 UI 逻辑和状态。虽然使用了 Ant Design 组件，但缺少： - 功能模块拆分（如 `KnowledgeBasePanel`、`ChatPanel`、`ReportPanel` 各自独立组件） - 状态管理方案（useState 散落在顶层组件，跨组件通信依赖 props drilling） - 自定义 Hook 抽取（如 `useKnowledgeBases`、`useChat`、`useReports`）随着功能增加，维护成本和 bug 风险将线性上升。 ### 3.5 缺少用户认证与多用户隔离系统没有引入任何认证机制（JWT、OAuth、Session 等）。所有知识库、文档、对话、报告、评分对任何能访问 API 的人都是全局可见和可操作的。对于文档管理场景，用户通常希望自己的工作空间是私密的。虽然项目文档声明定位为"学习、研究、投研辅助"工具，但若用于团队协作或多用户场景，缺少访问控制是明显的功能缺口。 ### 3.6 SQLite 并发瓶颈 `SQLiteStore` 使用单一 `threading.Lock` 保护所有读写操作，包括耗时的 `executescript`（建表迁移）。虽然对于原型和小规模使用可以接受，但在多用户并发上传 + 问答 + 报告生成的场景下，SQLite 写锁竞争会导致请求串行化。考虑到后端使用 async FastAPI，SQLite 的同步阻塞模型也会限制异步并发的收益。 --- ## 4. 建议 ### 4.1 评分维度分析接入 LLM，保留规则引擎作为 fallback **优先级：高** 当前规则评分提供了可复现的基线，建议在此基础上增加 LLM 评分路径： - mock 模式下保留当前规则评分。 - LLM 可用时，将每个维度的 `evidences`、`metrics`、`web_references` 组装为 prompt，让 LLM 输出结构化 JSON（score、rationale、key_facts、data_gaps）。 - 对 LLM 输出做合法性校验（score 在 0-100 范围），校验失败时 fallback 到规则评分。 - 这样既保留了"智能体"的内核，又不破坏现有的降级路径。 ### 4.2 实现问答和报告生成的流式输出 **优先级：高** - 后端：利用 LangChain ChatOpenAI 的 `streaming=True` 回调，将 token 通过 SSE `text/event-stream` 推送到前端。 - 前端：使用 `EventSource` 或 `fetch` + `ReadableStream` 接收流式数据，在 Markdown 渲染区域实时追加内容。 - 报告生成可复用相同机制，前端在报告预览区实时看到章节逐步展开。 - 对于 LangGraph 工作流，也可以用 `graph.stream()` 暴露中间节点状态（如"正在检索证据..."→"正在联网调研..."→"正在生成报告..."），让用户感知进度。 ### 4.3 引入 BM25 + Reranker 的混合检索 **优先级：中** - 使用 `rank_bm25`（纯 Python，无外部依赖）实现 BM25 关键词检索。 - 向量检索和 BM25 检索各取 Top-K 结果，合并去重后送 Reranker 精排。 - 可选用 `BAAI/bge-reranker-v2-m3`（与现有 bge-small-zh 同系列），或轻量级的 `ms-marco-MiniLM` cross-encoder。 - Reranker 可作为可选组件（配置开关），不可用时退化为简单融合排序。 ### 4.4 前端重构：组件拆分 + 状态管理 **优先级：中** 建议按功能域拆分： ``` frontend/src/ components/ KnowledgeBasePanel/ DocumentPanel/ ChatPanel/ ReportPanel/ ScorePanel/ HistoryPanel/ hooks/ useKnowledgeBases.js useChat.js useReports.js useScores.js contexts/ AppContext.jsx ``` 引入 `zustand`（轻量、无 boilerplate）或 React Context + useReducer 管理全局状态（当前知识库、当前文档、侧边栏折叠等），避免深层 props drilling。 ### 4.5 增加报告大纲自定义 **优先级：低-中** - 报告生成前，前端展示默认大纲（基于 system prompt 中的固定结构），允许用户新增/删除/重排章节。 - 用户确认后，将自定义大纲作为 prompt 的一部分发送给 LLM。 - 生成后的报告支持多轮修订（"扩展第三章"、"补充风险分析"），复用对话机制或独立的报告修订会话。 ### 4.6 增加文档元数据编辑功能 **优先级：低** 当前上传时可设置企业名称、年份、报告类型，但上传后不可修改。建议增加： - `PATCH /api/documents/{id}` 支持修改 `company_name`、`report_year`、`report_type`。 - 前端在文档列表中增加编辑按钮，弹出表单。 ### 4.7 考虑 SQLite 升级为 aiosqlite 或 PostgreSQL **优先级：低-中** - 短期方案：将 `SQLiteStore` 的同步 `sqlite3` 替换为 `aiosqlite`，避免阻塞 async 事件循环。 - 长期方案：若有多用户需求，迁移至 PostgreSQL + asyncpg，利用连接池和行级安全策略。 --- ## 5. 综合评价这是一个架构完整、工程实现扎实的企业研报智能体原型项目。以下从多个维度评价： | 评价维度 | 评分 | 说明 | |---------|------|------| | 功能完整性 | ⭐⭐⭐⭐⭐ | 从 PDF 上传到问答/报告/评分/导出的全链路闭环，知识库管理、历史记录、多会话、联网调研一应俱全 | | 工程鲁棒性 | ⭐⭐⭐⭐⭐ | 多层降级设计（Embedding/LLM/向量库/联网搜索）极为出色，mock 模式可离线演示所有功能 | | 代码质量 | ⭐⭐⭐⭐ | 目录结构清晰，类型注解覆盖率高，错误处理规范，SQLite schema 迁移机制完善；前端单文件过大是唯一明显短板 | | 技术创新 | ⭐⭐⭐⭐ | 自建 MD→PDF 渲染链、六维度评分框架、LangGraph fallback 实现均体现自主工程能力；评分实际为规则引擎扣一星 | | 测试覆盖 | ⭐⭐⭐⭐ | 11 个测试文件覆盖核心流程（API、PDF 解析、向量库、Embedding、评分、报告、联网），conftest 用临时目录隔离环境 | | 文档质量 | ⭐⭐⭐⭐⭐ | README + 项目说明文档共 490 行，覆盖项目概述、目标用户、使用场景、技术路线、API 概览、配置说明、常见问题、验证方式 | | 前端体验 | ⭐⭐⭐⭐ | Ant Design 专业控制台风格，三栏布局合理，操作带确认弹窗；缺少流式输出和组件化是主要短板 | **总体评价**：该项目在有限时间内交付了一个远超原型水准的完整系统。降级设计的"防御性编程"思维贯穿始终，使得系统在各种环境限制下都能正常工作，这在 AI 应用开发中是非常宝贵的工程素养。企业能力评分的六维度框架和自建 PDF 渲染链展现了超出 CRUD 层面的技术深度。主要改进方向集中在：**将评分的"智能"从规则驱动升级为 LLM 驱动**、**实现流式输出提升交互体验**、**引入混合检索提升检索质量**、**前端架构重构**。这些改进不会改变系统架构，但能显著提升产品的"智能感"和实用价值。 **一句话总结**：一个"防御性设计拉满、功能闭环完整、降级路径完善"的企业研报 RAG Agent 原型——在工程成熟度上相当出色，若补齐 LLM 驱动评分和流式输出，将具备较强的生产环境可用性。

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Z2wen1tao_31/S1W2-Enterprise-Research-Report-Agent#1

No description provided.

Rows
Columns