做技术调研最焦躁的时候我同时开着二十多个浏览器标签页一边读一边往文档里贴链接贴到最后自己都分不清这条信息是哪篇文章里的。后来我写了OpenResearch一个专门对付这种“资料收集混乱症”的开源小工具。它做的事情不复杂把我临时起意的研究问题拆成子问题去网页上抓相关材料清洗成干净文本再做向量化检索和要点汇总最后输出一份带来源链接的研究报告。它不是要取代搜索引擎而是把“查资料-整理-输出”这条链路固化下来让我每次调研不至于从零开始。如果你也经常写行业分析、技术选型、竞品拆解这个项目会很有参考价值。1. 项目背景为什么我要再造一个“研究工具”的轮子1.1 传统调研流程的低效点过去我做一份竞品分析流程基本上是先打开搜索引擎输入几个关键词然后一个个点进网页看遇到有价值的段落就复制到一个临时文档里再顺手把链接粘在下面。这个流程看起来没毛病但实际操作中问题非常明显。首先是上下文断层。当你连续打开十几个页面的时候大脑很难记住“这个数据是在哪个页面看到的”只能反复切页确认时间和注意力都耗在切换上。其次是信息重复同一个观点可能在五六篇文章里出现复制时不会自动去重最后整理出来的文档越来越臃肿真正有用的东西反而被淹没。最后是流程不可复用同样的调研动作下次换个题目又得重新来一遍。我一直觉得调研这件事完全可以标准化先定义清楚问题再按问题去采集素材接着对素材做清洗和结构化最后生成一份带引用来源的报告。OpenResearch就是想把这四步固化成一个可持续运行的系统。1.2 OpenResearch的定位与适用场景我把OpenResearch定位成“本地优先的研究辅助流水线”。它不是一个搜索框也不是一个笔记软件而是一个可以从“研究问题”一路跑到“研究报告”的半自动化工具。你给它一个具体的问题它会自己去拆解、检索、采集、分析、汇总最后给你一份有参考来源的结构化文档。这个工具最适合三类人一是像我一样需要经常写技术选型报告和行业分析的人二是做产品调研的运营和产品经理三是有大量文献整理需求的学生和研究人员。它不要求你懂特别深的编程只要你愿意改改配置文件就能把它跑起来。我在设计的时候刻意不把它做成一个依赖云端服务的“黑盒”而是把每个环节都拆开让用户能介入和修改。这也符合“OpenResearch”这个名字里的“Open”流程开放、代码开放、数据也留在本地。2. 整体设计思路先拆解问题再组织信息2.1 把研究任务拆成可执行的研究大纲OpenResearch的第一步不是抓取网页而是拆解问题。我在项目里设计了一个“Research Task”的数据结构它包含研究主题、研究问题列表、来源限定、时间范围和输出要求。举个例子如果研究主题是“2025年开源RAG工具的选型”那么系统会把这个问题拆成几个子问题主流开源RAG工具有哪些它们的架构差异是什么在中文场景下效果如何社区活跃度怎么评估每个子问题都是一个独立的检索单元。这样做的好处非常明显抓取目标更集中生成的报告结构也更清晰不会出现东讲一句西讲一句的混乱。我在代码里把子问题列表维护成一个Markdown大纲文件用户可以手动编辑它系统会根据大纲逐个去收集资料。这个设计思路借鉴了我做项目管理时的习惯不要直接啃一个巨大的目标而是先拆成可验证的小任务。研究问题拆得越细后面的检索和生成就越轻松。2.2 采集、清洗、存储三段式架构OpenResearch的整体架构可以分成三段采集层、处理层和生成层。采集层负责从搜索引擎结果页或指定URL列表里抓取网页内容处理层负责把HTML转成干净正文去掉导航、底部声明、广告这些干扰信息生成层负责把处理后的内容片段做向量化、检索最后汇总成报告。每一层之间通过文件或数据库解耦。采集层产出的原始HTML和元数据会缓存到本地处理层产出的干净文本会写入SQLite和向量库生成层只读取处理后的数据不关心原始网页长什么样。这样设计的好处是任何一个环节出问题都可以单独重跑不必从头再来。2.3 为什么坚持“本地优先模型可选”做这类工具最省事的方案是全部调云端API但我刻意留了一个口子所有环节都支持本地运行。网页抓取用Playwright本地跑内容提取用trafilatura本地跑向量化用sentence-transformers全家桶唯一可选的外部依赖是大模型生成报告。这样设计有现实考量。一是成本调研类任务经常需要反复调整问题每次调整都调API不划算二是隐私很多调研内容可能涉及内部数据不适合上传到第三方模型三是可控性如果生成结果不理想我可以随时换模型不需要改动整个系统。3. 技术选型解析为什么是Playwright、Trafilatura和Chroma3.1 抓取层选型Playwright比requests更适合现代网页最早的版本我用的还是requests加BeautifulSoup后来发现很多网站的内容是JavaScript动态渲染的直接请求HTML只能拿到空壳。换成Selenium又觉得太重浏览器驱动版本匹配经常让人抓狂。最后选了Playwright一是因为它对动态渲染支持好二是因为它自带浏览器上下文管理模拟真实用户操作很方便。我在抓取层还做了一些封装比如按照Robots协议限制请求频率、给每个页面设置随机延迟、失败自动重试三次。这些细节看起来不起眼但对稳定性影响很大。我实测过用requests硬爬大概运行半小时就会被部分站点封禁而用Playwright模拟浏览器访问加上低于1Hz的请求频率基本能稳定跑完整个调研流程。3.2 内容提取选型Trafilatura比正则表达式靠谱得多清洗HTML这一步一开始我用的是自写的正则表达式试图把所有标签剥掉但很快发现网页里到处是脚本、样式、注释和数据JSON正则根本写不完。后来换成了Trafilatura这个库就是专门做自然语言文本提取的它对新闻、博客、文档站点的正文识别效果都相当好。Trafilatura的优点在于它不只会提取文本还会输出标题、段落、列表等结构化信息。我可以直接拿到带段落边界的内容再做后续分块。它对正文长度的判断也比较智能能自动过滤掉过短的片段比如版权声明和“”这类链接文本。这里要注意一个细节Trafilatura对某些高度定制化的单页应用支持一般比如完全依赖JavaScript渲染的文档站。我的处理方法是抓取前先用Playwright等页面完全加载拿到渲染后的HTML再交给Trafilatura这样兼容性会好很多。3.3 向量存储选型Chroma够轻量也够用向量数据库我选了Chroma没有用Weaviate或Milvus这类更重的服务。原因很简单OpenResearch是本地优先的工具我不希望用户为了跑一个调研工具还得部署一个分布式数据库。Chroma支持嵌入式运行直接把数据存在本地目录里而且提供了非常直观的Python API。和Chroma配套的是sentence-transformers里的BAAI/bge-small-zh-v1.5模型。这个模型在中文语义相关性上的表现不错模型体积也只有100MB左右普通CPU可以流畅运行。向量维度和分块大小我在项目里都做成了配置项方便用户根据自己的数据量调整。也有朋友建议我直接用更高精度的Embedding模型比如OpenAI的text-embedding-3-small。我在设计上留了接口但默认不依赖外部API因为很多调研场景不允许把文本传出本地。对于英文内容用户也可以切换成all-MiniLM-L6-v2准确性会更高一些。4. 核心实现过程从零搭一条研究流水线4.1 数据模型先行ResearchTask和SourceItem代码还没写之前我先把数据模型定义清楚了。一个ResearchTask包括dataclass class ResearchTask: title: str questions: List[str] # 子问题列表 source_allowlist: List[str] # 允许采集的域名白名单 crawl_depth: int # 每个子问题的最大采集页数 time_range_days: int # 只保留指定天数内的文章一次处理的每一个网页都会生成一个SourceItem保存原始URL、标题、抓取时间、正文内容和后续的向量表示。数据模型的清晰程度直接决定了代码好不好维护所以这个阶段不要急着写抓取逻辑先把数据库表结构设计好。4.2 搭建抓取模块Playwright封装与页面解析抓取模块的核心是一个Crawler类它负责启动浏览器上下文、打开页面、等待渲染、拿到最终HTML。我封装了一个方法输入URL输出干净的Markdown正文async def fetch_page(url: str) - str: async with async_playwright() as p: browser await p.chromium.launch() context await browser.new_context( user_agentMozilla/5.0 ... Chrome/120.0, localezh-CN, ) page await context.new_page() await page.goto(url, timeout30000, wait_untilnetworkidle) html await page.content() await browser.close() return trafilatura.extract(html, output_formatmarkdown)使用wait_untilnetworkidle是为了等所有动态资源加载完避免拿到半渲染的页面。这个参数会让抓取速度略慢但提取效果明显更好。如果是抓取列表页还要额外滚动两三次页面否则懒加载内容不会出现。4.3 文本拆分与向量化入库清洗后的文本可能是几千字的文章不能整篇丢进向量库检索效果会很差。我把文本按Markdown标题结构和段落边界做了分块每块控制在500到800字之间块与块之间保留50字重叠避免把关键信息切散。from langchain.text_splitter import MarkdownTextSplitter splitter MarkdownTextSplitter(chunk_size700, chunk_overlap50) chunks splitter.split_text(markdown_text)分块之后用Embedding模型对每一块做向量化然后把向量连同原文、来源URL、标题一起存入Chroma集合。这里的文档ID我用的是URL加块序号这样后续调整分块策略时可以按来源URL整体删除旧数据。4.4 检索与报告生成让答案长在引用上报告生成是整个系统里最需要“克制”的部分。我没有让模型自由发挥而是先根据子问题从向量库检索排名靠前的文本片段再把这些片段按相关性排序后拼接成上下文最后生成一个要点式回答。我在提示词里明确要求模型必须引用片段编号并且不能编造片段中不存在的结论。输出格式也做了约束要求每个论点都附带来源链接。这样做之后报告虽然不像纯人工写那么流畅但胜在每条信息都有出处后续人工复核的成本大大降低。4.5 用配置文件串起整个流程为了让系统能被非程序员使用我把所有可调参数都集中在一个YAML文件里research: title: 主流RAG工具在中文场景下的对比 questions: - 有哪些主流开源RAG工具 - 这些工具的核心架构区别是什么 - 它们在中文语义检索上的表现如何 source_allowlist: - github.com - zhuanlan.zhihu.com crawl_depth: 5 time_range_days: 180 model: embedding: BAAI/bge-small-zh-v1.5 generator: local # local 或 openai vectorstore: persist_dir: ./data/chroma_db执行时只需要一行命令python main.py --config example.yaml。系统会按研究问题逐个采集、处理、检索和生成最终把报告写到output/目录下。5. 实操中的高频问题与排查技巧5.1 反爬限制和请求频率控制搭建过程中最头疼的就是抓取频繁触发网站的反爬机制。一开始我的爬虫跑大概二三十个页面就会被拒绝访问错误信息五花八门。我后来总结了几条经验设置随机延迟、使用真实浏览器的User-Agent和Header、限制并发数为1到2、对单个域名的请求时间间隔至少控制在3秒以上。如果网站仍然返回403或验证码页面我会直接把它加入黑名单不让它拖慢整个流程。调研类任务通常有大量候选网址没必要跟某个网站死磕。这个思路很重要抓取覆盖率超过八成就够了没必要追求100%。5.2 正文提取结果为空或乱码Trafilatura偶尔会返回空内容原因多半是页面在未完全渲染时就被抓取或者正文是图片型内容。我加了两个兜底逻辑一方面在Playwright抓取后主动等待页面中的主内容节点出现另一方面如果Trafilatura提取结果为空就回退到BeautifulSoup按article或main标签提取。乱码问题一般出在字符编码判断上。我在请求头里显式声明Accept-Charset并且在读取HTML时指定charsetutf-8遇到非UTF-8页面再做额外判断。现在主流网站基本都统一到UTF-8但老旧站点仍有GBK编码这里尽量用chardet自动检测。5.3 向量检索召回的内容不相关刚开始接入向量检索时我发现有些子问题召回的前几名片段跟问题关系不大。排查后发现是分块粒度的问题文本块太小语义信息不足文本块太大噪声又太多。我调了chunk_size从300试到1000最后发现中文学术和科技类文本在700字左右表现最稳。还有一个提升召回率的小技巧检索时把原始子问题做一次同义词扩展。比如“部署难度”同时检索“安装配置”和“上手成本”效果比单纯用原文查询好很多。这个扩展规则我暂时用词表维护后续打算接入模型生成。5.4 大模型生成内容出现幻觉报告生成阶段幻觉问题必须重视。我的处理方案是三层防线第一层提示词里明确限定“只能基于提供的片段回答”第二层生成后做引用校验把报告中出现的来源链接与检索结果对比保证链接确实在候选片段里第三层对关键结论增加“置信度标记”如果片段里没有明确数据支撑就标记为“待验证”。实际跑下来第三层防线最有价值。因为调研报告的价值在于可信度与其让模型自信地编一个数字不如坦诚地告诉读者“这个信息我没有找到直接证据”。6. 效果验证一次竞品调研的全过程记录6.1 输入的研究问题与参数配置我用一个真实任务来测试OpenResearch调研“主流开源RAG工具在中文场景下的选型”。配置了五个子问题来源限制在GitHub、知乎专栏、CSDN和几个技术社区时间范围设为最近半年每个子问题最多采集十五个页面。整个运行耗时大概四十分钟其中抓取占了一大半向量化和生成只用了几分钟。生成的报告有四个章节每个章节都附带了相关工具的名称、特点、社区活跃度和典型使用案例末尾还有一张对比表格。6.2 输出报告的质量评估从结果来看报告在信息广度上达到了我预期的八十分覆盖了主流工具和社区讨论中频繁出现的关键词。当然报告里有些细节还不够准确比如一些版本的发布时间和最新特性需要人工核对。这让我明确了项目的定位它不是最终交付物而是“初稿制造机”真正的人工价值在于判断和修正。6.3 让我意外的一个发现这次测试里OpenResearch把很多原本散落在不同文章里的实践问题归拢到了一起比如中文分词对检索效果的影响、不同向量库在百万级数据下的性能差异。这些内容之前我虽然零散看过但没有形成完整认知。工具的价值不只是省时间它还能帮你发现单个页面里看不到的“模式”。7. 后续演进方向OpenResearch的下一步7.1 把单线程流水线升级为多智能体协作目前OpenResearch还是单线程执行先跑完所有采集再统一处理。下一版我打算把流程拆成“检索员Agent”和“分析员Agent”两个角色。检索员负责并行处理不同子问题分析员负责交叉验证信息矛盾。这样既能加快速度也能发现不同来源之间的观点冲突。7.2 支持更多信息源与交互方式现在主要支持网页抓取但我已经在规划加入PDF导入、视频字幕文件和本地Markdown笔记作为输入源。交互上准备做一个简单的Web界面用户可以直接在页面上看到采集进度中间结果不用每次改完配置再跑命令行。7.3 让报告生成更“可溯源”我准备在报告生成阶段增加一个双向索引从结论反向追溯到具体的原文片段。这样用户点一下报告里的结论就能看到它依据的原文列表。虽然技术上只是多存一层关联关系但对使用体验的提升会非常明显。8. 写在最后的一点体会OpenResearch这个项目做下来我最深的感受是研究工具的核心不在于“自动生成”而在于“结构化”。真正耗人精力的从来不是读那几篇文章而是搞不清楚哪些问题需要回答、哪些信息才是关键。现在我把这个流程写成了工具每次新选题只需要改一下配置文件剩下的工作交给流水线跑我再基于初稿做判断和修正效率和深度都提升了不止一个档次。如果你也想搭一个类似的研究辅助系统我建议从最小闭环开始先实现网页抓取和Markdown输出再用脚本做关键词检索最后再引入模型生成。不要一上来就追求多智能体和大模型先把“能复现的流程”跑通这个过程中积累的细节比任何炫酷的功能都值钱。