药物研发里的问题很少是“找一段文字”这么简单。研究人员更常问：某个靶点和疾病有什么证据链？候选化合物影响哪些通路？这篇来源文章讨论的核心变化是：把图数据库、生成式 AI 和 BYOKG（Bring Your Own Knowledge Graph，自带知识图谱）结合起来，用 GraphRAG 加速科学发现，同时尽量不牺牲科学完整性。
为什么普通 RAG 在科研场景里容易吃力
传统 RAG 通常把论文、实验报告、专利或数据库记录切成文本块，再用向量检索找相似内容。这对“召回相关段落”很有效，但药物研发更依赖关系：
- 基因、蛋白、疾病、药物、通路之间有多跳关联。
- 证据来源有等级差异，例如体外实验、动物实验、临床研究不能混为一谈。
- 同一个实体有别名、同义词和数据库 ID，需要规范化。
- 科学结论需要可追溯，不能只给一个流畅回答。
GraphRAG 的价值在这里变得明显：图数据库负责保存实体和关系，生成式 AI 负责把检索到的证据组织成可读解释。它不是让大模型“凭感觉推理”，而是让模型在结构化证据上生成回答。
BYOKG 的重点：把企业自己的知识接进来
BYOKG 的意思不是再造一个通用搜索引擎，而是允许团队把自己的知识图谱带入检索和生成流程。对制药研究来说，这很关键，因为真正有价值的信息往往分布在内部实验、授权数据库、公开文献和专家标注里。
可以把一个药研知识图谱简化成几类节点和边：
Gene：基因或蛋白靶点。Disease：疾病或表型。Drug：上市药物或候选化合物。Pathway：信号通路或生物过程。Evidence：论文、实验记录、数据库条目。
边则表达“关联疾病”“抑制靶点”“参与通路”“由证据支持”等关系。GraphRAG 查询时，不只找相似文本，还可以沿着这些关系扩展上下文，例如从疾病找到靶点，再找到候选药物和证据。
可以这样实践：一个最小 GraphRAG 原型
下面示例是一个可运行的最小原型，用 networkx 模拟知识图谱，并把检索到的子图转换成给 LLM 的上下文。它不是来源文章中的产品 API，而是一个便于团队理解 GraphRAG 工作方式的实践骨架。
运行前安装依赖：
python -m venv .venv
source .venv/bin/activate
pip install networkx
创建 mini_graphrag.py：
import networkx as nx
def build_kg():
g = nx.MultiDiGraph()
g.add_node("EGFR", type="Gene", name="Epidermal growth factor receptor")
g.add_node("NSCLC", type="Disease", name="Non-small cell lung cancer")
g.add_node("Erlotinib", type="Drug", name="Erlotinib")
g.add_node("MAPK", type="Pathway", name="MAPK signaling pathway")
g.add_node("PMID:123", type="Evidence", name="Clinical study record")
g.add_edge("EGFR", "NSCLC", relation="associated_with", evidence="PMID:123")
g.add_edge("Erlotinib", "EGFR", relation="inhibits", evidence="PMID:123")
g.add_edge("EGFR", "MAPK", relation="participates_in", evidence="PMID:123")
g.add_edge("PMID:123", "EGFR", relation="supports")
g.add_edge("PMID:123", "NSCLC", relation="supports")
return g
def retrieve_subgraph(g, seed, hops=2):
nodes = {seed}
frontier = {seed}
for _ in range(hops):
next_frontier = set()
for node in frontier:
next_frontier.update(g.successors(node))
next_frontier.update(g.predecessors(node))
next_frontier -= nodes
nodes.update(next_frontier)
frontier = next_frontier
return g.subgraph(nodes).copy()
def graph_context(subgraph):
lines = []
for src, dst, data in subgraph.edges(data=True):
src_type = subgraph.nodes[src].get("type", "Entity")
dst_type = subgraph.nodes[dst].get("type", "Entity")
relation = data.get("relation", "related_to")
evidence = data.get("evidence", "not specified")
lines.append(f"{src} ({src_type}) --{relation}--> {dst} ({dst_type}); evidence={evidence}")
return "\n".join(lines)
def build_prompt(question, context):
return f"""You are assisting pharmaceutical researchers.
Answer only from the graph context. If evidence is missing, say so.
Question:
{question}
Graph context:
{context}
Answer format:
- Short answer
- Evidence chain
- Caveats
"""
if __name__ == "__main__":
kg = build_kg()
question = "What is the evidence chain connecting Erlotinib to NSCLC?"
subgraph = retrieve_subgraph(kg, "Erlotinib", hops=2)
prompt = build_prompt(question, graph_context(subgraph))
print(prompt)
执行：
python mini_graphrag.py
你会得到一段可以送入大模型的 prompt，其中包含从 Erlotinib 出发检索到的关系链。实际系统里，可以把 networkx 换成 Neo4j、Amazon Neptune、TigerGraph 或其他图数据库，把最后的 print(prompt) 换成对模型 API 的调用。
生产系统要补上的几块硬骨头
原型能说明思路，但药物研发系统不能停在“能问答”。至少要处理这些工程问题：
- 实体标准化：
EGFR、全名、数据库 ID、别名要映射到同一个节点，否则图会碎裂。 - 证据分层：不同证据类型需要权重，临床证据和预测结果不能同等展示。
- 权限控制：内部实验数据、授权数据库和公开文献可能有不同访问边界。
- 可追溯回答：输出不仅要有自然语言结论，还要带实体、关系、证据 ID。
- 更新机制：科研知识快速变化，图谱需要增量更新和版本管理。
一个较稳妥的架构是：文档和结构化数据进入抽取管道，实体解析后写入知识图谱；查询时先做意图识别和实体链接，再执行图遍历、向量检索或二者混合检索；最后让大模型基于证据生成摘要，并返回证据链。
落地建议：把 GraphRAG 当成证据组织层
GraphRAG 在药物研发中的价值，不是把模型包装成“科学家替身”，而是把散落的知识组织成可查询、可解释、可追溯的证据网络。BYOKG 让团队可以把自己的内部知识纳入这个网络，这是它区别于通用问答系统的地方。
采用时可以按这个清单推进：
- 先选一个窄问题，例如“疾病到靶点证据链”或“候选药物到通路影响”。
- 明确定义节点、边、证据类型和可信度字段。
- 要求每个回答返回证据链，而不是只返回结论。
- 对高风险结论保留人工审阅，尤其是涉及临床、毒性和适应症扩展的场景。
- 用专家标注的问题集评估召回率、证据准确性和幻觉率。
GraphRAG 的边界也要说清楚：图谱质量决定回答上限，大模型不能修复错误的实体链接或缺失证据。真正可靠的系统，是图谱、检索、生成和审阅流程一起工作。