从零搭建AI生物科技情报简报系统：以EGFR耐药性为例

AI生物科技情报简报（biotech intelligence briefs）这类工具，正在把生物医药研发里最耗时的资料综述工作自动化。Lumaris 的示例场景选择得很典型：把 EGFR 耐药性相关的突变位点、耐药机制、药物逃逸和下一代治疗线索，从大量论文和数据库中整理成一份可读、可追溯的简报。它解决的核心问题是，研发人员不需要再手动翻几十篇文献，而是由 AI 系统完成采集、检索、抽取和生成，最后产出一份带引用、可复核、能支撑判断的简报。

这篇文章会围绕“如何从零搭建一个类似 Lumaris 的 AI 生物科技情报简报系统”展开。虽然原项目公开的工程细节有限，但这类系统的通用链路是稳定的：数据源接入、文档解析、切片索引、大模型抽取、简报生成、证据校验、输出分发。下面会以 EGFR 耐药性为示例场景，给出一个可运行的最小骨架，并说明每一步为什么这样做、跑起来后怎么验证、遇到典型问题怎么排查。

1. 先拆解 Lumaris 这类 AI 生物科技情报简报的技术链路

1.1 情报简报和普通摘要有什么区别

普通摘要只是把一篇文章压缩成几百字，信息源单一，也不要求可追溯。生物科技情报简报面向的是研发决策场景，它有几个普通摘要不具备的特点：

第一，信息源是多篇文献、数据库和结构化记录的组合，不是单篇文档的“浓缩”。一条 EGFR 耐药性简报，可能需要同时从突变数据库、药物临床试验、耐药机制综述、新靶点论文中提取信息，然后合并成一个统一视角。

第二，内容必须可追溯。简报里出现“T790M 突变导致对一代 EGFR-TKI 耐药”，就必须能够指向具体文献或数据库记录。读者需要能一键回到原始出处，判断这句话是否可信。

第三，时效性和不确定性都很高。同一靶点可能在不同研究中得到相反结论，需要明确标注证据级别、发表时间和冲突状态，而不是把模型生成的结果当成确定事实。

所以，Lumaris 这类项目不是简单的“摘要工具”，而是“情报管道”。它的输出不是一篇文章，而是一份带元数据、带引用、带证据状态的结构化情报产物。

1.2 生成一条简报需要哪些技术模块

从工程实现看，一条 AI 生物科技情报简报的生成链路可以拆成下面几个模块：

在最小实现里，这些模块可以全部串在一个 Python 脚本里，核心目标是先跑通。在正式产品里，每个模块都可以独立成服务，异步执行并记录日志。

1.3 为什么 EGFR 耐药性适合作为示例场景

EGFR 耐药性是一个非常适合做“AI 生物科技情报简报”示例的领域，原因有四点。

第一，资料丰富。关于 EGFR 突变的文献、评审、临床研究记录数量充足，可以方便验证检索召回和实体抽取效果。

第二，术语标准。EGFR、T790M、C797S、奥希替尼、一代 EGFR-TKI 这些词都有明确的医学定义，正好可以测试大模型是否稳定识别标准实体，而不是自己编造变体。

第三，问题边界清晰。EGFR 耐药的核心问题可以拆成：哪些突变导致耐药、哪些药物对哪些突变有效、下一代治疗路径是什么。这样的问题结构适合生成结构化简报。

第四，信息更新快。这个领域仍在不断产出新论文，适合做增量更新、时效监控和冲突检测。这也让“内容过时”变成真实可测的问题，而不仅仅是理论。

需要说明的是，EGFR 耐药性在示例中只是用来演示系统能力，不属于医学建议。生产环境如果要输出给临床或研发人员，还要额外增加医学审校和合规流程。

2. 环境准备和项目结构：先搭一个可运行的最小 Lumaris 骨架

2.1 运行环境和依赖

下面示例采用 Python 3.10+ 作为主语言，使用 FastAPI 做接口层，LangChain 的检索抽象做向量召回。原项目不一定使用同样的技术栈，这里只是为了说明通用管道。实际落地时，要按自己的依赖版本和模型服务调整。

需要准备的环境项如下：

如果本地没有可用的大模型服务，可以先用任意 OpenAI 兼容的 API 做验证。学习阶段可以把模型换成小一点的模型，但效果会明显下降，因为实体抽取和证据生成对模型指令跟随能力要求较高。

2.2 项目目录结构

推荐采用下面的目录结构。它的好处是采集、解析、检索、生成、校验分层清楚，后续替换任何模块不会影响其他部分。

lumaris/ ├── app/ │ ├── main.py # FastAPI 入口 │ ├── config.py # 配置读取 │ ├── models/ │ │ ├── brief.py # 简报输出模型 │ │ └── entity.py # 实体抽取模型 │ ├── pipeline/ │ │ ├── collect.py # 数据采集 │ │ ├── parse.py # 文档解析 │ │ ├── index.py # 切片索引 │ │ ├── retrieve.py # 检索召回 │ │ ├── extract.py # 实体抽取 │ │ ├── generate.py # 简报生成 │ │ └── validate.py # 质量校验 │ └── utils/ │ ├── logger.py # 日志封装 │ └── llm.py # 模型调用封装 ├── data/ │ ├── raw/ # 原始文献 │ ├── chunks/ # 切片结果 │ └── db/ # 向量库文件 ├── output/ │ ├── briefs/ # 生成的简报 │ └── logs/ # 运行日志 ├── requirements.txt └── README.md

这个目录是一个“最小可运行骨架”。生产环境还需要加入测试目录、CI/CD 配置、监控面板和版本迁移脚本，但学习阶段不需要一开始就铺开。

2.3 配置文件说明

配置文件用环境变量或.env文件管理，避免把模型密钥写死在代码里。下面是config.py的简版实现：

import os from pydantic_settings import BaseSettings class Settings(BaseSettings): project_name: str = "lumaris" llm_api_base: str = os.getenv("LLM_API_BASE", "http://localhost:8000/v1") llm_api_key: str = os.getenv("LLM_API_KEY", "") llm_model: str = os.getenv("LLM_MODEL", "qwen2.5:14b") llm_temperature: float = float(os.getenv("LLM_TEMPERATURE", "0.2")) max_context_chars: int = int(os.getenv("MAX_CONTEXT_CHARS", "12000")) chunk_size: int = int(os.getenv("CHUNK_SIZE", "800")) chunk_overlap: int = int(os.getenv("CHUNK_OVERLAP", "100")) top_k: int = int(os.getenv("TOP_K", "8")) vector_store: str = os.getenv("VECTOR_STORE", "chroma") db_path: str = os.getenv("DB_PATH", "./data/db") class Config: env_file = ".env" settings = Settings()

关键参数说明如下：

2.4 用最小命令把项目拉起来

先安装依赖，假设项目根目录已经有requirements.txt：

cd lumaris python -m venv .venv source .venv/bin/activate pip install -r requirements.txt

requirements.txt里至少包含以下包。版本号先不写死，实际安装时以当前兼容版本为准：

fastapi uvicorn pydantic pydantic-settings langchain langchain-community chromadb pypdf beautifulsoup4 requests python-dotenv

启动入口先用一个最简 FastAPI 应用：

from fastapi import FastAPI from app.pipeline.generate import run_brief_pipeline app = FastAPI(title="Lumaris API") @app.post("/brief") async def create_brief(topic: str): result = run_brief_pipeline(topic=topic) return result

学习阶段可以先不启动 API，直接写一个main.py里的函数调用，跑通整个管道再封装接口。

注意：不要只验证程序能启动，还要验证输入、输出、异常分支和日志是否符合预期。第一步先跑通管线脚本，再上 API。

3. 以 EGFR 耐药性示例走通简报生成主流程

3.1 数据源接入：从公开数据库收集原始材料

EGFR 耐药性相关材料主要来自公开学术数据库。示例中可以接入 PubMed 的 E-utilities API 和 ClinicalTrials.gov API。这里只用它们做合规检索实验，不抓取未授权的全文内容。

一个简化版采集函数如下：

import requests import time def search_pubmed(query: str, retmax: int = 20) -> list[dict]: """检索 PubMed 并返回文献标题、摘要、PMID。""" base = "https://eutils.ncbi.nlm.nih.gov/entrez/eutils/" params = { "db": "pubmed", "term": query, "retmode": "json", "retmax": retmax, "sort": "relevance", } resp = requests.get(base + "esearch.fcgi", params=params, timeout=30) id_list = resp.json()["esearchresult"]["idlist"] results = [] for pmid in id_list: summary_params = { "db": "pubmed", "id": pmid, "retmode": "json", } s = requests.get(base + "esummary.fcgi", params=summary_params, timeout=30) doc = s.json()["result"][pmid] results.append({ "pmid": pmid, "title": doc.get("title", ""), "pubdate": doc.get("pubdate", ""), "abstract": fetch_abstract(pmid), }) time.sleep(0.34) # 遵守 API 频率限制 return results def fetch_abstract(pmid: str) -> str: """通过 efetch 获取摘要，这里只返回前 2000 字符。""" url = "https://eutils.ncbi.nlm.nih.gov/entrez/eutils/efetch.fcgi" params = {"db": "pubmed", "id": pmid, "rettype": "abstract", "retmode": "text"} resp = requests.get(url, params=params, timeout=30) return resp.text[:2000]

EGFR 耐药性示例查询词可以这样设计：

("EGFR" OR "epidermal growth factor receptor") AND ("resistance" OR "T790M" OR "C797S" OR "osimertinib resistance")

这里不建议一次只查一个词。情报检索的召回率依赖查询词的组合设计，否则容易漏掉关键信息。生产环境还应该维护一个“关键词词典”，覆盖靶点别名、药物别名和突变描述变体。

3.2 解析文档并切片入库

采集到的文献摘要和公开文本需要切成固定大小的块，才能做向量召回。切片时要保留来源信息。

from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter = RecursiveCharacterTextSplitter( chunk_size=800, chunk_overlap=100, separators=["\n\n", "\n", ". ", " "], ) def build_chunks(documents: list[dict]) -> list[dict]: chunks = [] for doc in documents: source = doc["abstract"] if len(source) < 50: continue pieces = text_splitter.split_text(source) for idx, piece in enumerate(pieces): chunks.append({ "text": piece, "metadata": { "pmid": doc["pmid"], "title": doc["title"], "pubdate": doc["pubdate"], "chunk_index": idx, "evidence_id": f"PMID-{doc['pmid']}-CHUNK-{idx}", }, }) return chunks

这里的evidence_id是后面证据映射的关键。它把一段文本唯一对应到一篇文献的某个切片，简报里所有引用都通过它指回原始资料。这一步如果省略，简报生成后无法准确追溯引用。

3.3 使用大模型抽取结构化实体

在生成简报前，先让大模型从召回片段中抽取结构化实体。EGFR 耐药性示例需要的实体类型包括：靶点、突变、药物、耐药机制、治疗线索、证据来源。

下面是实体定义：

from pydantic import BaseModel from typing import List, Optional class Entity(BaseModel): entity_type: str name: str aliases: List[str] = [] mentions: List[str] = [] class EvidencePoint(BaseModel): statement: str entity_names: List[str] evidence_ids: List[str] confidence: str = "medium" # high / medium / low class ExtractedKnowledge(BaseModel): entities: List[Entity] evidence_points: List[EvidencePoint]

对应的抽取提示词可以放在prompts/extract.txt中。关键是让模型输出 JSON，再用 Pydantic 校验，而不是直接生成简报文本。

你是一名药物研发情报分析助手。请从给定的文本片段中，抽取与 EGFR 耐药相关的实体和结论。 只允许提取文本中明确出现的实体，不要根据背景知识补充。 实体类型包括：target、mutation、drug、resistance_mechanism、therapy_direction。 对每个关键结论，列出支持它的 evidence_id。 如果文本没有提到某类信息，字段返回空数组，不要编造。 输出格式必须为 JSON，且遵循如下结构： { "entities": [ {"entity_type": "mutation", "name": "T790M", "aliases": ["EGFR T790M"], "mentions": []} ], "evidence_points": [ {"statement": "T790M 是常见的一代 EGFR-TKI 获得性耐药机制", "entity_names": ["T790M"], "evidence_ids": ["PMID-...-CHUNK-..."], "confidence": "medium"} ] }

这里要注意：抽取阶段就要求“文本中明确出现”，是后面控制幻觉的第一道防线。如果抽取阶段允许模型自由发挥，生成阶段基本不可能纠正回来。

3.4 生成结构化简报

实体抽取完成后，把实体的证据片段拼装成简报警告上下文。生成阶段用第二个提示词，按模板输出简报。

简报输出模型：

from pydantic import BaseModel from typing import List class Citation(BaseModel): evidence_id: str source_title: str source_id: str published_date: str url: str = "" class BriefSection(BaseModel): heading: str content: str citations: List[str] = [] class BiotechBrief(BaseModel): topic: str summary: str sections: List[BriefSection] key_findings: List[str] = [] open_questions: List[str] = [] citations: List[Citation] = [] generated_at: str

生成完成后，将 Markdown 渲染版和 JSON 结构化版同时保存到output/briefs/目录。

3.5 双格式输出示例

JSON 输出大致如下：

{ "topic": "EGFR resistance", "summary": "EGFR 耐药主要由 T790M、C797S 等突变驱动，不同代际 TKI 的耐药机制存在差异。", "sections": [ { "heading": "耐药机制", "content": "T790M 是常见的一代 EGFR-TKI 获得性耐药机制，C797S 与三代 TKI 耐药相关。", "citations": ["PMID-30000000-CHUNK-1", "PMID-31000000-CHUNK-2"] } ], "key_findings": [ "T790M 突变可导致一代 TKI 失效", "C797S 突变可能与奥希替尼耐药相关" ], "open_questions": [ "不同突变组合对药物疗效的确切影响仍需要更多临床数据" ], "citations": [ { "evidence_id": "PMID-30000000-CHUNK-1", "source_title": "EGFR T790M resistance mechanism", "source_id": "30000000", "published_date": "2023-05-01" } ] }

Markdown 输出则是同一份数据的可读版本。生成阶段建议先输出 JSON，再用一个渲染函数转 Markdown，而不是直接让模型生成 Markdown。这样结构错误更容易被 Pydantic 拦截。

4. 关键工程点：检索增强、提示词约束和证据关联

4.1 检索增强生成（RAG）在生物医药情报里的作用

如果直接把“EGFR 耐药”问题发给大模型，它看到的是一个开放的、没有边界的查询。模型会基于训练语料回答问题，可能输出过时或不准确的信息。RAG 的思路是：先从小型知识库中召回相关片段，再把片段和问题一起交给模型，让模型只能基于这些片段回答。

在生物医药情报场景，RAG 不只是“提升答案质量”的可选项，而是“数据可追溯”的基础。没有 RAG 的检索结果，简报里的每一句话都无法对应到原始出处，也就无法通过医学审校。

一个简化的检索函数：

def retrieve_evidence(question: str, top_k: int = 8) -> list[dict]: query_embedding = embedding_model.embed_query(question) results = vector_store.similarity_search_by_vector( query_embedding, k=top_k, filter={"topic": {"$eq": "EGFR-resistance"}} ) return [{"content": r.page_content, "metadata": r.metadata} for r in results]

检索后要按证据质量排序，而不是完全依赖向量相似度。可以给匹配片段增加一个统计分数，比如关键词重叠度，并过滤掉发布时间太老的文献。

4.2 提示词模板和字段约束

生成阶段的提示词要尽可能限定模型的行为范围。下面是一个可复用的模板骨架：

你是生物医药情报整理助手。请根据提供的证据片段生成简报。 规则： 1. 只能使用证据片段中出现的信息。 2. 如果证据之间冲突，在 open_questions 中说明冲突，不要自行选择一方。 3. 每段内容必须标注对应 evidence_id。 4. 不输出证据片段之外的新实体、新药物或新结论。 5. 输出必须是可以被 Pydantic 解析的 JSON，不要输出 Markdown。 证据片段： {evidence_text} 简报主题： {topic}

这里的关键不是“写得好”，而是“边界明确”。“只能使用证据片段中出现的信息”和“冲突时放在 open_questions”这两条，能显著降低模型编造和过度泛化的概率。

4.3 证据 ID 与引用映射机制

证据关联是整条管道最容易出问题的环节。很多初版系统生成的简报看起来完整，但点开引用发现对应不上原文，原因是证据 ID 在管道中丢失了。

解决方法是把证据 ID 当成一等公民，在切片、检索、抽取、生成、渲染每个环节都保留。

引用映射表可以用下面结构保存：

生成时，模型输出中的citations数组必须回查这个映射表。如果某个evidence_id不存在，校验阶段要重试或丢弃该结论，而不是直接写进简报。

4.4 用“证据级别”管理不确定性

生物医药知识本身有很强的时效性和不确定性，简报不能把所有信息都写成事实。可以在简报中增加以下字段：

• evidence_level：high / medium / low，来自文献类型、发表时间和是否经过临床验证。
• conflict_status：unknown / supported / conflicted。
• last_updated：生成或复核时间。
• review_status：draft / reviewed / approved。

生产环境里，没有经过人工复核的简报应该标记为draft。学习阶段哪怕只是单人使用，也要保留这个字段，否则后续很难判断一条结论是否经过审校。

注意：AI 生成的生物医药简报只能作为资料整理辅助，不能替代专业医学判断。所有结论在用于实际研发或临床决策前，必须经过领域专家复核。

5. 运行验证和结果评估：怎么判断简报能不能用

5.1 单条简报的验收指标

管线跑通后，不能只看输出有没有字数。以下指标在单条简报阶段就要检查：

单条简报最好抽出一句关键结论，人工回原文确认一次。比如摘要里有“C797S 与奥希替尼耐药相关”，就去原始文献中找这句话是否被支持。这一步能快速发现系统性的幻觉问题。

5.2 检查事实冲突

EGFR 耐药领域的文献经常出现结论不一致。例如同一突变在不同研究中可能被描述为“对某药物敏感”和“对某药物耐药”。这种冲突不能直接由模型裁决，而是要在简报中并列展示。

冲突检测常用做法：

1. 先抽取同一实体对的结论，比如(EGFR T790M, osimertinib)。
2. 判断结论的方向，是“敏感”还是“耐药”，或“无影响”。
3. 统计不同文献的支持方向。
4. 如果方向不一致，写入open_questions并标记conflict_status=conflicted。

可以用一个小的规则表对比结论方向，避免让模型频繁参与判断。

5.3 批量运行时的质量抽样

批量生成多条简报时，不可能每条都人工细读。建议用抽样策略：每 20 条简报抽 3 条，分别检查引用覆盖率、字段完整度和虚构实体率。记录抽样结果，便于评估模型提示词是否被意外修改。

一个轻量评估表格可以这样设计：

如果实体虚构率超过 5%，就要先解决抽取问题，再继续扩展数据源。

5.4 记录生成日志以便复现

生成日志至少保留以下信息：检索词、模型名称、模型温度、召回片段 ID 列表、每个证据片段的得分、模型输出原始文本、Pydantic 校验结果、最终简报文件路径。

log_entry = { "topic": "EGFR resistance", "model": settings.llm_model, "temperature": settings.llm_temperature, "retrieved_evidence_ids": evidence_ids, "raw_output": raw_text, "validation": "ok", "brief_path": output_file, }

有了这些日志，当某条简报后面被发现有事实错误时，可以完整复盘是检索问题、模型问题还是提示词问题，而不是靠猜。

6. 常见问题排查：模型乱编、引用对不上、内容过时

在这个系统里，最常出现的问题集中在模型幻觉、证据映射和时间性上。下面按现象到原因的顺序整理排查路径。

6.1 模型生成了不存在的突变或药物名

现象：简报中出现类似“EGFR T800D”“AZD9291 耐药复发率”等信息，但在召回片段中找不到对应文本。

可能原因：

• 模型温度设置偏高，进入了自由生成模式。
• 抽取阶段没有强制要求“只使用文本中出现过的实体”。
• 上下文窗口过大，模型注意力分散，混入了训练语料知识。

检查方式：

1. 搜索生成的实体名是否出现在原始证据片段中。
2. 查看生成日志里的retrieved_evidence_ids，确认这些证据片段是否确实被传入模型。
3. 用 grep 在data/chunks/目录中搜索可疑实体名：

grep -r "T800D" data/chunks/

解决方式：

• 把llm_temperature调到 0.1。
• 在抽取提示词中增加“只输出文本中出现的实体，禁止补充背景知识”。
• 增加后处理校验：所有实体名必须出现在至少一个证据片段里，否则从输出中删除。

6.2 引用 ID 和正文对不上

现象：简报正文引用了PMID-30000000-CHUNK-1，但点击后对应的句子和正文描述完全无关。

可能原因：

• 证据映射表在切片阶段丢失了evidence_id。
• 生成阶段模型自己编造了“看起来合理”的 evidence_id。
• 校验阶段只检查了 ID 格式，没有检查 ID 到句子内容的语义对应。

检查方式：

1. 用脚本批量校验每个 citation 对应的 chunk 文本。
2. 计算正文句子和 chunk 文本的关键词重叠度，低于阈值则标记为不匹配。

def check_citation(brief, citation_map): for section in brief.sections: for cid in section.citations: chunk_text = citation_map.get(cid, "") if not chunk_text: return False return True

解决方式：

• 生成提示词中明确写“evidence_id 只能从输入证据片段列表中选择，禁止自行组合”。
• 增加 ID 存在性校验，不存在则重新生成。
• 将引用相似度作为一个质量分数写入日志，低于阈值时标记needs_review。

6.3 简报内容停留在旧治疗指南

现象：简报中仍在说“奥希替尼耐药后只能选择化疗”，但检索年份较新的文献已经写了新的治疗方向。

可能原因：

• 数据源更新不及时，知识库里根本没有新文献。
• 检索时按相关度排序，放弃了最新论文。
• 没有在提示词中限定信息截止日期。

检查方式：

1. 直接查询知识库中最近的文献日期：

sqlite3 data/db/lumaris.db "select max(pubdate) from documents;"

2. 单独检索最新年份单词，确认新文献是否入库。

解决方式：

• 增加增量更新任务，每日或每周拉取新文献。
• 检索策略调整为“相关度 + 时间衰减”混合排序。
• 在简报中标注information_cutoff_date，让读者知道信息覆盖到什么时候。

6.4 生成的 Markdown 结构和预期不一致

现象：JSON 解析正常，但渲染出的 Markdown 标题层级混乱，或者列表和表格缺失。

可能原因：

• 生成阶段直接让模型输出 Markdown，格式不可控。
• 没有使用统一渲染层，而是依赖模型排版。

解决方式：

• 改成“先生成 JSON，再用模板渲染 Markdown”。
• 渲染函数中固定标题层级和表格样式，不让模型自由发挥。
• 增加结构校验，检查每个 section 的 heading 是否存在，内容是否为空。

7. 生产落地建议和扩展方向

7.1 学习环境和生产环境的差异

学习阶段可以一人一机跑通脚本，但生产环境必须补齐下面这组能力：

如果要把系统交给团队使用，至少先做到三件事：敏感操作有审计日志、模型输出有版本记录、每条简报可以追溯数据来源和生成参数。

7.2 增量更新与定时触发

生物科技情报的时效性要求系统能持续跟踪新资料。增量更新可以这样设计：

• 每天定时执行一次 PubMed 新增检索，按pubdate过滤当天新增文献。
• 对新文献执行切片、抽取、入库。
• 对已有简报主题重新计算冲突状态。
• 如果发现新的关键证据，生成提醒事件，而不是自动替换原有的简报。

增量更新的核心原则是“不覆盖旧结论，只增加新证据版本”。这样历史版本可以被比较，也方便回溯不同时间点的判断变化。

7.3 生物医药领域的合规与版权注意事项

在生产环境使用外部文献时，要重点关注版权和许可协议。

• PubMed 的 E-utilities 接口使用要遵守其服务条款，控制请求频率，不要抓取超过必要范围的数据。
• 全文 PDF 是否可入库，要看期刊的开放获取协议。很多全文并不允许直接存储和二次分发。
• 从数据库摘录结构化数据时，要保留原始许可声明和引用出处。
• 生成简报本身不构成医学建议，输出页面应明确标注“AI 生成内容，仅供研究参考，未经专业审校不得用于临床决策”。

这些注意事项不是法律意见，但工程团队至少应该在系统设计阶段就规划好：哪些数据允许采集、哪些内容允许存储、哪些输出需要人工审核。

7.4 从单条简报扩展到情报追踪产品

Lumaris 这类的示例只是一个起点。把它扩展成完整的情报追踪产品，可以考虑几个方向：

第一，构建领域知识图谱。EGFR 耐药性里的靶点、突变、药物、临床试验之间关系复杂，图结构能比文本片段更准确地表达“T790M 导致某药物失效”这类关系。

第二，加入用户订阅和定期推送。研究人员可以订阅某个靶点，系统每周生成简报并推送到邮箱或内部工作群。

第三，建立人工反馈闭环。让领域专家对简报打标“准确”“过时”“与事实冲突”，这些反馈可以用于调整检索排序和提示词。

第四，增加多文档一致性分析。同一句话引用多篇文献时，可以自动对比不同文献的结论差异，生成冲突矩阵。

对于新手，建议不要一开始就做知识图谱和订阅系统。先用 EGFR 这类公开资料丰富的场景，把单条简报跑通，再把召回片段、实体抽取、引用校验这些基础组件的质量做好。基础组件稳定后，产品扩展只是接上新数据源和新任务的问题。

最后，生产环境最值得优先做的一件事，是把“证据 ID 与文本片段”的强映射固化下来。只要这条链路不断，简报的任何一句话都能被追溯到原始出处，后续的质量评估、错误排查和专家复核都会顺畅很多。