GraphRAG+BYOKG加速药物研发：AWS Neptune与Bedrock构建科研知识图谱

一句话看懂

AWS推出BYOKG+GraphRAG方案，用知识图谱和生成式AI连接碎片化科研数据，让药物研发人员用自然语言提问并得到带证据链的答案。

详细发生了什么

在药物研发早期阶段，研究人员面临一个核心痛点：科学知识分散在PubMed、内部实验记录、基因组数据库等不同系统中，难以形成全局关联。传统方法下，早期筛选成功率仅5%，单次耗时超过6个月。

AWS提出的解决方案结合了Bring Your Own Knowledge Graph (BYOKG) 和Graph-based Retrieval Augmented Generation (GraphRAG)。核心架构使用Amazon Neptune Analytics构建统一知识图谱，将植物、化合物、基因、蛋白质、疾病等实体及其关系结构化存储。通过Amazon Bedrock（调用Claude 4.5等模型）实现自然语言查询，系统在遍历图谱后返回带引用路径和可视化证据的答案。

数据来源包括PMC Open Access Subset的医学期刊（CC BY/CC0许可）、NCBI的Bio.Entrez元数据、Disease Ontology层次结构以及Amazon Comprehend Medical提取的ICD-10代码。节点类型涵盖disease、author、journal、journalChunk和icd10，边关系通过自动管道构建。

该方案的关键创新在于BYOKG-RAG工具包，允许用户使用自己的图数据模型，而非依赖预定义的通用图谱。这使得制药公司可以整合内部私有数据与公共数据，同时保留完整的证据追溯能力。

中文圈视角

对中文科研圈而言，这个方案有几点值得关注：

平替与国产替代：国内类似场景可参考ModelScope的知识图谱工具或百度文心大模型的图检索能力，但AWS方案的核心优势在于Neptune Analytics的图算法与Bedrock的模型集成深度。如果企业已有知识图谱基础设施（如Neo4j），可考虑自建GraphRAG管道，但需要自行处理模型调用和证据链生成。
中文数据适配：方案使用的PubMed和ICD-10以英文为主。中文科研数据（如CNKI、中文临床指南）需要额外处理分词、实体对齐（如中药成分与基因的映射）。国内团队可参考该架构，但需替换底层数据源和NLP模型。
合规与数据安全：制药研发涉及大量敏感数据。AWS方案强调BYOKG（自带图谱），数据可保留在VPC内，但若使用Bedrock的海外模型，需注意数据出境合规。国内用户可考虑阿里云PAI或华为云ModelArts的图推理服务。
未被讨论的盲点：原文未提及图谱更新的实时性——药物研发中新论文每日发布，如何增量更新图谱而不破坏已有关系？另外，证据链的“可重复性”在中文语境下缺乏标准验证工具。

几条值得记住的细节

早期药物筛选成功率仅5%，单次耗时超6个月，GraphRAG旨在缩短这一周期。
方案使用Amazon Neptune Analytics作为图引擎，Amazon Bedrock调用Claude 4.5进行自然语言理解。
数据节点类型包括disease、author、journal、journalChunk、icd10，边关系通过Comprehend Medical自动提取。
BYOKG-RAG工具包允许用户自定义图数据模型，不依赖预设图谱。
所有答案附带图遍历路径和源引用，确保可追溯性。

一句话总结

GraphRAG+BYOKG让科研人员用自然语言查询知识图谱，并拿到带证据链的答案——中文圈需关注数据适配与合规问题。