为什么值得关注

它通过将相关性评分拆分为两个独立维度（特异性和角度强度）并让模型先写角度再评分，解决了 LLM 评分无意义的问题，实现了单一 1–5 评分无法获得的有效的区分能力。

适合谁使用

追踪多个垂直领域的独立研究者或分析师
构建自托管 RAG 或研究管道的开发者
希望避免按文档支付 API 成本并注重隐私的用户
对可重复、可单元测试的工作流生成感兴趣的 n8n 用户

典型使用场景

跨行业每日监控融资轮次，自动提取公司、行业、投资者信息
针对存储的语料库回答临时问题，综合多个已分类的文档
运行完全本地的研究信息流，使用小型模型（9B）在 12GB GPU 上过滤不相关的文章

项目优势

单元测试的工作流生成防止了静默数据丢失（例如 n8n 的子工作流默认行为曾导致 38% 的语料丢失）
双轴评分（特异性和角度强度）提供了有用的排序，而单一相关性评分中 71% 的项目得分为 5
完全在自托管硬件上运行，使用 9B 模型，避免了按文档的 API 成本并保护数据隐私
管道设计可审计：失败保持可见，时效性通过算术处理而非有损的模型调用

使用前须知

RSS 条目没有结构化提取（缺少国家/工具字段），因此无法归入某些视图
大多数条目（261 个中的 204 个）早于双轴评分系统，仅携带旧的无效相关性评分
有 10 个条目标记为 TRIAGE_FAILED 并保持可见而不删除，可能会使数据显得杂乱

README 快速开始

Research Overseer

A research discovery pipeline that runs on my own hardware. It searches (Exa, Tavily, Brave), watches RSS, scrapes what it finds, scores every document against a defined beat using a local 9B model, stores the results in Postgres, and answers questions about them over Telegram.

Built on self-hosted n8n, with LM Studio serving the triage model and Supabase for storage. One Telegram chat is the entire interface.

The repo is the source of truth. Build scripts generate the workflow JSON, so editing a workflow in the n8n UI gets overwritten on the next build. The pure logic they inline is unit-tested.

What it looks like

Asking for a recap of the week. The company names, round sizes and investors are fields the triage step extracted into a structured column when each article was first read, so building the recap is a query over that column rather than a second pass over the articles.

Asking a question the stored feed can answer. The figures come from several separately triaged documents, pulled together at query time.

Why I built this

I read across six verticals and most of what arrives is unusable. The obvious fix is an LLM that reads everything and flags what matters. That fix failed in a specific way: ask a model "is this relevant, 1 to 5" and it answers 5. On one live query, ten of ten articles scored exactly 5. The filter discriminated nothing.

Getting useful judgment out of a small local model took three changes. I split the single score into two independent axes. I made the model write its angle before rating that angle. And I reordered the response schema, because grammar-constrained decoding emits properties in schema order, so each field conditions the next.

Then there was n8n itself, which fails silently in ways you only catch by auditing the data. One sub-workflow default wrote every result against the first document and dropped 38% of a corpus. It ran that way for days.

So nothing here is hand-edited in a UI. Scripts generate the workflows, and the logic they inline is unit-tested. It runs on a 12 GB card with a 9B model, because per-document API costs would have killed the habit of running it at all.

Where the model actually is

Two of the ten pipeline stages call a model. Everything else is code, which is why the test suite covers the parts that matter an

项目描述

Self-hosted research discovery pipeline on n8n. Searches, scrapes and scores documents against a defined beat with a local 9B model, then answers questions over Telegram.

research-overseer