AiReview:加速系统综述的开放平台

系统综述是循证医学的基础。 系统综述的创建过程耗时且需要大量人力投入,主要在于需要筛选或评估大量研究以确定是否纳入。 目前已有多种工具旨在简化此过程,但大多依赖传统机器学习方法。 大型语言模型 (LLM) 在进一步加速筛选流程方面展现出巨大潜力。 然而,目前尚无工具能让最终用户直接利用 LLM 进行筛选,也未能促进 LLM 辅助筛选方法的系统化、透明化应用。 本文介绍了:(i) 一个可扩展框架,用于将 LLM 应用于系统综述任务,尤其是标题与摘要筛选;以及 (ii) 一个基于 Web 的 LLM 辅助筛选界面。 以上要素共同构成了 AiReview——一个用于 LLM 辅助系统综述创建的创新平台。 AiReview 是首款弥合前沿 LLM 辅助筛选方法与医学系统综述创建实践之间鸿沟的同类平台。 该工具可在 https://aireview.ielab.io 获取。 源代码亦已在 https://github.com/ielab/ai-review 开源。

1. 研究目标、实际问题、科学假设及相关研究

1.1 研究目标与实际问题

  • 研究目标: 这篇论文的主要目标是介绍 AiReview,一个开源的 (Open Platform)、基于Web的平台,旨在利用大型语言模型 (Large Language Models, LLMs) 来加速系统综述 (Systematic Reviews, SRs) 的创建过程,特别是其中最耗时、劳动密集型的标题和摘要筛选 (title and abstract screening) 环节。

  • 实际问题: 系统综述是循证医学 (evidence-based medicine) 的基石,需要全面检索、评估相关研究来回答特定的研究问题。然而,这个过程极其耗时,研究人员(通常是医学研究者和图书馆员)需要手动筛选成千上万篇文献的标题和摘要,以判断其是否符合预定义的纳入/排除标准 (inclusion/exclusion criteria),通常基于 PICO 框架(Population, Intervention, Comparison, Outcome)。这个筛选瓶颈大大延长了SR的周期,限制了最新证据的及时应用。

    论文提到:“Creating one is time-consuming and labour-intensive, mainly due to the need to screen, or assess, many studies for inclusion in the review.” 以及 “The most labour-intensive part of conducting a SR is title and abstract screening, where tens of thousands of studies (...) need to be screened, or in other words, assessed by humans [14].”

  • 是否新问题: SR耗时的问题由来已久。利用技术加速SR(称为 Technology-Assisted Review, TAR)也不是新概念,已有一些工具出现。但论文指出的  问题是:现有工具大多依赖传统机器学习方法,而未能有效、系统化、透明地集成最新的、潜力巨大的LLMs 来辅助筛选,特别是缺乏让最终用户 (end users) 直接、灵活地利用LLM能力的工具。

    论文指出:“Several tools have been developed to streamline this process, mostly relying on traditional machine learning methods. Large language models (LLMs) have shown potential in further accelerating the screening process. However, no tool currently allows end users to directly leverage LLMs for screening or facilitates systematic and transparent usage of LLM-assisted screening methods.”

1.2 科学假设

虽然论文没有明确表述一个单一的、可量化验证的科学假设(因为它主要是一篇系统介绍/框架提出的论文),但其隐含的假设是:

  1. LLMs能够有效辅助甚至部分自动化SR中的标题摘要筛选任务,其表现可能优于或补充传统方法。

  2. 提供一个灵活、透明、用户可控的平台 (AiReview),允许研究人员根据需求配置LLM的角色和交互程度,可以提高筛选效率,同时让用户能够管理和意识到潜在的AI偏见 (bias)

  3. 论文提出的LLM角色(Pre-, Co-, Post-reviewer)和交互级别(Low, High)框架(见下文详述)是一种有效组织和理解LLM在SR筛选中不同应用模式的方式,并且不同的模式对应不同的效率提升引入偏见的风险

1.3 相关研究与归类

  • 相关研究:

    • 传统TAR工具: 论文提到了基于传统机器学习(如主动学习)的开源工具,例如 ASReview [16] 和作者团队之前的 DenseReviewer [11](基于密集检索)。这些工具通常通过学习用户的标注模式来对文献进行排序或分类。

    • LLMs在SR中的应用探索: 论文引用了一些初步研究 [3, 5, 7, 8, 13, 15],这些研究探索了使用LLMs(如GPT系列)进行筛选、数据提取等任务的可能性,通常是在脚本或特定实验设置中,而非集成到用户友好的平台。

    • 商业工具: 提到了如 Elicit 和 EPPI Reviewer 等商业工具。Elicit 利用LLM做信息提取而非筛选,EPPI Reviewer 支持GPT-4做数据提取和判断,但仅限于筛选后的评估阶段,且LLM的实现细节通常不透明(如Prompt不可编辑)。

  • 归类: 这项研究属于 信息检索 (Information Retrieval, IR)自然语言处理 (Natural Language Processing, NLP) 和 医疗信息化 (Health Informatics) 的交叉领域,具体可以归类为 AI辅助的系统综述自动化 (AI-assisted Systematic Review Automation) 或 人机协作信息处理 (Human-Computer Interaction for Information Processing)

  • 值得关注的研究员:

    • Guido Zuccon (通讯作者): 来自昆士兰大学,在信息检索、健康搜索和系统综述自动化领域有深入研究,其领导的 IELab 产出了包括 DenseReviewer 和 AiReview 在内的多个相关工具。

    • Harrisen Scells, Xinyu Mao: 同属 IELab,参与了 DenseReviewer 和 AiReview 的研发,专注于 IR 和 ML 在 SR 中的应用。

    • Martin Potthast: 来自卡塞尔大学,在 NLP、IR 和计算论证领域有广泛研究。

    • Rens van de Schoot: ASReview 的主要开发者之一,在利用机器学习加速 SR 方面有重要贡献。

    • 其他引用文献 [3, 5, 7, 8, 13, 15] 的作者也在探索 LLM 在 SR 中的应用。

2. 新思路、方法或模型

2.1 新思路与关键解决方案

  • 核心思路: 从“提供单一算法/黑箱工具”转向“提供一个灵活、透明、可配置的LLM集成平台”。让非技术背景的最终用户(医生、研究员)也能直接利用和控制LLM来辅助SR筛选。

  • 关键解决方案 (AiReview 平台):

    1. Web平台化: 提供易于使用的图形用户界面 (GUI),降低使用门槛 (Figure 1, Figure 2a)。用户可以上传文献集 (nbib格式) 和纳入标准。

    2. 模块化架构: 采用现代Web技术栈 (Vue.js, Django, Nginx, PostgreSQL, RabbitMQ, Celery, Docker) 实现前后端分离、异步任务处理,便于扩展和部署 (Figure 1)。

      • 通俗解释: 前端是用户看到的界面,后端处理数据和逻辑,消息队列(RabbitMQ/Celery)处理耗时的LLM请求,数据库存数据,Docker让部署更简单。

    3. 外部LLM API集成: 通过API连接多种LLMs(商业如OpenAI GPT系列,开源如LLaMa, Mistral, Deepseek),用户可以选择模型 (Figure 2b)。

    4. 透明的LLM控制:

      • 模型配置 (Model Config): 用户可选LLM模型、调整温度 (Temperature)(控制输出随机性,0为确定性,1为更有创意)、设置最大输出长度等 (Figure 2b)。

      • Prompt编辑 (Prompts): 用户可以查看和修改用于指导LLM行为的提示 (Prompts),包括系统指令、任务模板、响应格式和纳入标准 (Figure 2c)。这大大提高了透明度和可定制性。

        • 通俗解释: Prompt就像你给AI下达的指令。AiReview让你能看到并修改这些指令,比如告诉AI它的角色、任务是什么、如何回答、以及本次筛选的具体标准。

    5. LLM集成框架 (Framework for Categorising LLM Use Cases): 这是论文提出的一个核心概念创新。它将LLM在筛选中的应用系统化地分为:

      • 角色 (Role):

        • Pre-reviewer: LLM在人类筛选前预先处理文献,提供建议(如Figure 2a中的 "AI suggests: Include" ➁)。

        • Co-reviewer: LLM在人类筛选时实时提供辅助,像一个“副驾驶”(可通过 "Ask AI" 按钮 ③ 触发,或实时显示)。

        • Post-reviewer: LLM在人类筛选后检查决策,进行质量控制或识别不一致性。

      • 交互级别 (Interaction Level):

        • Low support: LLM的输出默认不显示,需要用户主动触发(如点击按钮)才能看到。

        • High support: LLM的建议或信息自动、显著地展示给用户(如Figure 2a的设置)。

      • 组合与流程 (Table 1): 论文展示了不同角色和交互级别的组合方式及其工作流。

    ![alt text](placeholder_image_table1_summary.png)

    图注:基于Table 1的LLM角色与交互级别框架总结。

2.2 特点与优势 (相比之前方法)

  • 直接利用LLM: 与ASReview等传统ML工具不同,AiReview直接利用LLM强大的自然语言理解和推理能力进行筛选判断,可能捕捉更复杂的语义关系。

  • 透明度与可控性: 相比不透明的商业工具或简单的脚本,AiReview允许用户查看、配置LLM模型、参数和Prompts,理解AI的决策依据,并根据需要进行调整。这是其核心优势。

    论文强调:“Our platform allows transparent control of LLMs, aligning with the guidelines for AI usage in SRs [2].”

  • 灵活性: 通过角色和交互级别的框架,用户可以根据自身需求(如新手学习、团队协作、质量控制)、偏好(希望AI多大程度介入)以及对AI偏见的担忧来配置LLM的辅助方式。

  • 开源: 开放源代码 (GitHub链接提供) 促进了社区贡献、可复现性和可定制化,降低了机构的使用成本。

  • 系统化框架: 提出的角色/交互级别框架为系统地研究和比较不同LLM集成策略提供了理论基础,超越了以往零散的应用探索。

3. 实验验证与结果

3.1 实验设计

严格来说,这篇论文并未包含一个完整的、旨在验证方法有效性的对比实验。它更侧重于介绍 AiReview 这个平台本身及其设计理念(LLM集成框架)
论文中展示的内容可以看作是一个演示性案例 (Illustrative Example) 或 概念验证 (Proof of Concept)

  • 场景设置: 使用了一个真实的SR数据集(关于PTSD轨迹分析,来自 van de Schoot et al. [17])和 GPT-4o 模型。

  • 界面展示: Figure 2a 展示了用户在AiReview界面中进行筛选的过程,并配置了LLM作为 Pre-reviewer 和 Co-reviewer,且设置为 High interaction level。界面显示了文献信息、用户操作按钮 (Include/Exclude ①)、LLM的预筛选建议 ➁、交互式“Ask AI”按钮 ③ 和右侧的SR Assistant面板 ④。

  • 交互演示: 展示了用户可以与SR Assistant进行交互(通过Chat ⑦),查看LLM基于纳入标准给出的详细推理 ⑧,甚至进行PICO提取或请求更详细的解释 ⑨。同时展示了模型配置 ⑤ (Figure 2b) 和Prompt编辑 ⑩ (Figure 2c) 功能。

3.2 实验数据与结果

由于缺乏对比实验,论文没有提供定量的实验结果来衡量 AiReview 相对于手动筛选或其他工具在效率(时间节省)、准确性(筛选错误率)、用户满意度等方面的表现。

  • 关键“数据”/结果:

    • 平台本身: AiReview 平台成功构建并可用 (提供了网址和源码)。

    • 框架提出: 提出了LLM角色/交互级别框架 (Table 1) 和基于此的组合流程 (Pipelines) 及其概念上的努力节省 (Effort Saved) 估算 (Table 2)。

      Table 2 使用 💧 符号概念性地表示不同Pipeline(如仅Pre-reviewer, Pre+Co, Full Pipeline等)相比纯手动筛选可能节省的工作量。例如,"Full Pipeline" (P+C+Q) 被赋予最多的 💧 (7个),表示理论上效率最高。论文还假设“the more human effort saved, the more bias is introduced.”

    • 应用场景示例 (Table 3): 展示了框架如何应用于实际场景,如新手培训(Co-Only)、资源有限团队(Full Pipeline作为第二审阅者)、筛选后质控(Co-Post)。

3.3 结果对假设的支持

  • 论文的演示性案例平台功能初步支持了假设2:AiReview 确实提供了一个灵活、透明、可控的平台。用户能够配置LLM角色、交互级别、模型和提示。

  • 对于假设1(LLM能有效辅助筛选)和假设3(框架有效性及效率/偏见权衡),这篇论文并未提供直接的实验证据。它提出了框架和工具,为未来的研究来验证这些假设奠定了基础。论文明确提到计划进行用户研究来评估这些方面。

    论文在 Future Work 中提到:“We plan to conduct a user study using this platform to investigate how different roles and interaction levels of LLMs affect human's screening decision and perceived utility...”

4. 论文贡献与影响

4.1 论文贡献

  1. 推出 AiReview 平台: 提供了一个首创的 (first of its kind) 开源、用户友好的Web平台,专门用于透明、灵活地将 LLM 集成到 SR 标题摘要筛选流程中。填补了现有工具在易用性、透明度和LLM集成方面的空白。

  2. 提出 LLM 集成框架: 系统化地定义了 LLM 在 SR 筛选中的角色(Pre-, Co-, Post-reviewer),为设计、评估和讨论人-AI协作模式提供了概念基础。

  3. 促进透明度和用户控制: 强调并实现了用户对 LLM 选择、参数调整和 Prompt 编辑的控制能力,响应了 AI 在科研应用中对透明度和可解释性的要求。

  4. 概念化效率与偏见权衡: 通过 Pipeline 分类 (Table 2) 和 Effort Saved 估算,初步探讨了不同 LLM 集成策略在效率提升和潜在偏见引入之间的权衡关系。

4.2 业界影响

  • 对医学研究/循证医学: 可能显著加速 SR 流程,使得医学证据能够更快地被合成和应用。降低 SR 的门槛,可能让更多研究者能进行高质量的综述。

  • 对 AI 研究社区: 提供了一个真实世界的应用场景和测试平台,用于研究人-LLM 协作的最佳实践、Prompt Engineering 技术、LLM 在专门领域的可靠性、以及如何管理 AI 偏见。

  • 对 SR 工具开发者: 树立了一个新的标杆,强调了 LLM 集成、透明度和用户控制的重要性。可能推动其他现有工具(开源和商业)集成类似的功能。

4.3 潜在应用场景和商业机会

  • 应用场景:

    • 医学研究机构/医院: 加速内部的 SR 项目,支持临床决策和指南制定。

    • 大学/图书馆: 作为研究支持工具,培训学生和研究员进行 SR。

    • 制药公司/CRO: 在药物研发、市场准入等环节进行快速文献回顾。

    • 政策制定机构: 快速合成证据以支持政策决策。

    • 其他学科: 任何需要大量文献回顾的领域(如社会科学、工程学)。

  • 商业机会:

    • 部署与定制服务: 为机构提供 AiReview 的部署、集成和定制化服务。

    • 高级功能/模型: 开发基于 AiReview 的增值服务,如提供针对特定医学领域的预训练/微调 LLM,或更高级的分析功能。

    • 咨询与培训: 提供如何有效、负责任地使用 LLM 进行 SR 的咨询和培训服务。

    • 集成平台: 将 AiReview 作为模块集成到更大的科研管理或数据分析平台中。

    • Prompt 库/市场: 创建和销售针对不同 SR 任务和领域的优化 Prompt 模板。

4.4 工程师应关注的方面

  • 技术栈: 了解 AiReview 使用的技术(Python/Django, Vue.js, Docker, Celery/RabbitMQ, PostgreSQL),这些是构建现代 Web 应用和处理异步任务的常用技术。

  • LLM API 集成: 如何通过 API 调用不同的 LLM 服务(OpenAI, Hugging Face Hub, etc.),处理认证、请求、响应和错误。

  • Prompt Engineering: 设计有效的 Prompt 来指导 LLM 完成特定任务(如判断相关性、提取信息),理解 Prompt 对结果的影响。这是使用 LLM 的核心技能。

  • 人机交互 (HCI): 如何设计界面,让用户能够有效地与 AI 协作,并理解和控制 AI 的行为(如 AiReview 的角色/交互级别设置)。

  • 异步任务处理: 对于耗时的 LLM 调用,如何使用消息队列(如 Celery/RabbitMQ)进行异步处理,以避免阻塞用户界面。

  • 开源贡献: 可以研究 AiReview 的源码,为其贡献代码、修复 Bug 或开发新功能。

5. 未来研究方向与挑战

5.1 值得探索的问题与挑战

  • 实证评估: 最迫切的是进行严格的用户研究,量化评估 AiReview 在不同配置下对筛选效率、准确性、用户工作量、认知负荷和满意度的影响,并与手动筛选及其他工具进行比较。

  • 偏见评估与缓解: 深入研究不同 LLM 集成策略(角色、交互级别)如何引入或放大偏见(如自动化偏见 [4]),并探索如何通过界面设计、透明度机制或算法调整来缓解这些偏见。

  • LLM 的可靠性与幻觉: LLM 可能会“幻觉 (hallucinate)”或提供不准确的信息。如何检测和处理 LLM 在 SR 筛选中的错误输出是一个关键挑战。

  • Prompt 鲁棒性: 研究 Prompt 设计对 LLM 性能的影响,如何使 Prompt 对用户输入的细微变化(如纳入标准的表述方式)更鲁棒。

  • 扩展到 SR 其他任务: 将 LLM 应用扩展到 SR 的其他环节,如布尔查询构建 (Boolean query formulation) [18]数据提取 (data extraction)质量评估 (quality assessment)、甚至证据综合 (evidence synthesis),探索构建端到端的 SR 解决方案。

  • 协作筛选: 支持多个审阅者同时使用 AiReview 进行筛选,并利用 LLM 辅助解决意见分歧 (resolving disagreements)

  • 与非 LLM 方法结合: 探索如何将 LLM 与传统 ML 方法(如 ASReview)或基于检索的方法(如 DenseReviewer [11])结合,取长补短。

  • 成本与可访问性: 大型 LLM API 调用可能成本高昂。探索使用更小、更高效的开源模型,或优化 API 调用策略以降低成本。确保平台对资源有限的研究者也具有可及性。

5.2 可能催生的新技术和投资机会

  • 领域专用 LLMs: 针对医学或其他特定领域微调的 LLM,能更准确地理解专业术语和研究设计,提高 SR 任务性能。

  • 混合智能系统: 结合 LLM 的语义理解能力和符号逻辑/规则引擎的精确性,创建更可靠的 SR 辅助工具。

  • 可解释 AI (XAI) for SR: 开发技术和界面,更好地向用户解释 LLM 的决策过程,增强信任和可控性。

  • 自动化 SR 平台: 投资开发更全面的、覆盖 SR 全流程(从问题定义到报告撰写)的自动化平台,AiReview 可作为其中关键一环。

  • Responsible AI 框架: 针对 LLM 在科研(特别是医疗)领域的应用,开发相应的伦理指南、审计工具和最佳实践,催生相关咨询和认证服务。

  • Prompt 工程平台/服务: 专门为 SR 或科研领域提供 Prompt 设计、管理和优化服务的平台或公司。

6. Critical Thinking: 不足与存疑之处

  1. 缺乏实证数据: 如前所述,最大的不足是缺少对 AiReview 效果的量化评估。论文提出的效率节省 (Table 2) 仅是概念性假设 (conceptual estimation),未经证实。

  2. 偏见问题未深入: 虽然提到了偏见风险与效率的权衡,但对其具体表现、影响程度以及 AiReview 的透明度设计是否足以有效管理偏见,缺乏深入分析和证据。

  3. LLM 局限性讨论不足: 对 LLM 可能存在的幻觉、对 PICO 标准理解的细微偏差、以及在处理边缘或非典型研究时的表现等问题讨论较少。

  4. Prompt 工程的挑战: 平台效果在很大程度上取决于用户能否编写出高质量的 Prompt(尤其是纳入标准)。对于非技术用户,这可能仍是一个挑战。平台是否提供足够的指导或模板来帮助用户?

  5. 可扩展性与成本: 对于需要筛选数十万文献的大型 SR,平台的性能、稳定性和 LLM API 成本可能会成为问题,论文对此未作讨论。

  6. “开源”的实际门槛: 虽然代码开源,但部署和维护一个包含数据库、消息队列、Web 服务器和 LLM API 集成的系统,对于没有 IT 支持的个人研究者或小型团队仍有技术门槛。

  7. 对比的公平性: 在与商业工具比较时,指出其不透明,这可能是事实,但也需考虑商业工具可能在内部进行了大量优化和测试。



–EOF–
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

No comments: