【TextIn大模型加速器 + 火山引擎】跨国药企多语言手册智能翻译系统设计与实现

AI解决方案扣子Agent

在全球化医药行业中,产品说明书的多语言版本管理一直是令人头疼的难题。一款新药从研发到上市,需要在不同国家提交数十种语言的说明书,而且每次配方调整、适应症更新,都需要同步修改所有语言版本。传统流程中,翻译公司接到一份200页的英文说明书,需要先人工录入文字,再交给翻译团队逐页处理,最后校对排版,整个周期往往长达一周甚至更久。本文将展示如何利用TextIn的多语言解析能力与火山引擎的Agent编排平台,将这个流程压缩到4小时以内。

一、TextIn:跨越语言和格式的智能解析引擎

TextIn是由合合信息打造的新一代文档智能平台,其核心竞争力在于"多语言+多格式"的一站式解析能力。在医药文档场景中,一份产品手册可能混合英文正文、拉丁学名、中文商品名、日文警告信息,传统OCR系统在遇到这种多语言混排时往往只能逐个切换语言模型,不仅效率低下,还容易在语言边界处产生识别错误。

picture.image

TextIn xParse引擎能够自动识别文档中的语言类型,无需人工指定即可准确提取内容。更重要的是,它输出的不仅是纯文本,还包含每个文字块的坐标信息(bbox)、段落层级、表格结构等元数据。这些结构化信息以Markdown和JSON格式返回,可以直接导入向量数据库,为后续的RAG检索提供多维度支持。相比传统OCR只能给出"一堆文字",TextIn能告诉系统"第3页第2段是副作用说明,包含一个3行4列的剂量对照表"。

产品注册体验链接: https://www.textin.com/register/code/KKBKQ6 注册即送TextIn平台3000页体验

体验指南/产品资料包: https://ai.feishu.cn/drive/folder/LzYmfgsutl499idcfx6cef7snV4?from=from_copylink

二、火山引擎:低代码Agent编排与RAG增强平台

火山引擎提供的Coze智能体平台,将复杂的AI应用开发简化为可视化节点拖拽。在跨国药企的场景中,IT团队往往面临人手不足、需求频繁变更的困境。传统开发模式下,每次调整翻译规则或增加新语种,都需要修改代码、测试、上线,周期至少3-5天。而在Coze平台上,业务人员只需要调整工作流中的提示词或参数配置,就能在几分钟内完成迭代,并且支持灰度发布和全链路审计。

picture.image

Coze平台的另一大优势是深度集成了火山引擎的向量数据库和豆包大模型。在传统RAG方案中,文档解析和向量化是分离的两个步骤,中间需要大量的数据清洗和格式转换工作。而在Coze中,我们可以将TextIn的解析节点直接替换掉系统默认的文档处理节点,让原始PDF直接输出为"段落向量+表格向量+标题向量"的多维度结构,召回精度比纯文本方案大大提升。这种结构化召回在处理药品说明书时尤为关键,因为"不良反应"和"药物相互作用"虽然都包含相似的医学术语,但它们的语义完全不同,传统向量检索很容易混淆。

三、实战案例:构建多语言医药手册智能翻译系统

现在让我们进入完整的实战环节,看看如何从零搭建一套能够处理中英德日四语医药手册的智能翻译与版本同步系统。这个系统的业务目标是:研发部门上传最新的英文说明书PDF,系统自动完成内容解析、术语标准化、多语言翻译、版本差异对比,最终输出各语种的规范化文档,可直接提交给各国药监部门。

场景泳道图说明

整个业务流程涉及三个主要角色和五个关键环节。文档源头来自研发部门的临床试验报告管理系统(CTMS),当一款新药完成三期临床试验后,系统会自动生成包含成分分析、临床数据、用药指导的综合性说明书。这份文档通常是200-300页的Word或PDF格式,内含大量专业术语、统计图表和化学分子式。

picture.image

数字员工在第二个环节介入,也就是文档从CTMS导出后、进入翻译流程前的那一刻。传统流程中,这个阶段需要人工将Word文档逐页复制粘贴到翻译软件,或者外包给翻译公司。而配备了TextIn+火山引擎的数字员工可以监听CTMS的文档输出事件,一旦检测到新文档,立即触发自动化流程。

最终结果会回写到两套系统。第一套是企业内部的多语言文档库(通常基于SharePoint或企业Wiki),所有翻译版本会按照"药品名-语种-版本号"的规则归档存储。第二套是各国药监局的电子申报系统,比如FDA的eCTD系统、EMA的CESP平台,这些系统对文档格式有严格要求,我们的Agent会根据目标国家自动生成符合规范的提交包。

技术方案详解

整个系统的技术架构基于火山引擎Coze平台搭建,核心由五个节点组成。第一步是环境准备,我们需要在TextIn官网申请开发者账号并创建应用,获取app_id和secret_code。

picture.image

同时在火山引擎开通Coze平台和向量数据库服务。向量数据库我们命名为"pharma_knowledge_base",设置分片数为8(基于预估的文档规模),选择火山引擎的Doubao-embedding-vision | 250615作为向量化模型。这个模型在医药领域的术语理解上经过了专门优化,对于像"Adverse Drug Reaction"和"Drug-Drug Interaction"这种语义相近但含义不同的专业术语有更好的区分能力。

picture.image

接下来在Coze平台创建智能体,命名为"多语言医药手册翻译助手"。进入工作流编排画布后,我们开始逐个添加核心节点。

第一个节点是文档解析节点,也就是TextIn的ParseX插件。点击画布左侧的"添加节点"按钮,在插件市场搜索"通用文档解析专业版"。

picture.image

添加后在节点配置面板中,我们进行详细参数设置。file参数关联到开始节点的输入变量"source_document",这样用户上传的PDF就会自动传递给解析引擎。然后填入之前获取的app_id和secret_code完成身份验证。

重点在parameters参数的配置,这里我们输入一段精心设计的JSON:

{"get_image": "both","image_output_type": "base64","apply_document_tree_structure": true,"language": "auto","output_format": "md_with_layout","table_parse_mode": "advanced"}

这段配置的含义是:提取文本的同时保留图片(用于分子式识别),图片以base64编码返回,保留文档的层级树形结构,自动检测语言类型,输出包含版式信息的Markdown格式,并启用高级表格解析模式以处理复杂的嵌套表格。

picture.image

第二个节点是术语标准化节点。医药文档中充斥着大量专业术语,同一个概念可能有多种表达方式,比如"乙酰水杨酸"和"阿司匹林"指的是同一种药物。我们在ParseX节点后添加一个"知识库检索"节点,配置为检索我们预先导入的"医药术语标准库"。

picture.image

这个术语库包含了WHO的INN(国际非专利名称)、FDA的UNII(唯一成分标识符)、以及各国药典的标准名称映射关系。当ParseX识别出"aspirin"这个词时,系统会自动检索出它的标准名称是"acetylsalicylic acid",并附带中文译名"乙酰水杨酸"、日文译名"アセチルサリチル酸"、德文译名"Acetylsalicylsäure"。

第三个节点是核心的翻译Agent节点。我们添加一个LLM节点,选择豆包大模型的pro版本(支持128K上下文,适合处理长文档)。在系统提示词中,我们这样设计:

"你是一个专业的医药翻译专家,精通中英德日四种语言,熟悉ICH国际医药术语标准、各国药监法规要求。你的任务是将提供的医药说明书翻译为目标语言,并严格遵循以下规则:1. 药品通用名必须使用INN国际标准名称;2. 剂量单位统一为公制单位(mg/mL/kg);3. 不良反应描述必须使用MedDRA标准术语;4. 保留原文档的章节结构和表格格式;5. 化学分子式、统计数据、临床试验编号保持原文不翻译。请根据上下文提供的术语库进行术语对照,确保翻译的一致性和准确性。"

用户提示词则通过变量引用,将ParseX的解析结果、术语库的召回结果、目标语言参数三者组合起来:"请将以下医药说明书从{{source_language}}翻译为{{target_language}},参考术语对照表:{{terminology_mapping}}。原文内容:{{parsex.result}}"

picture.image

第四个节点是版本对比节点。这是本系统的一大亮点功能。我们在翻译节点后增加一个代码执行节点,编写一小段Python脚本,用difflib库对比新翻译版本与历史版本的差异。

picture.image

脚本会从向量数据库中检索该药品的上一个版本,然后逐段对比,将新增内容标记为绿色、删除内容标记为红色、修改内容标记为黄色。这个功能对于药监申报至关重要,因为监管部门需要清楚地看到每次修订改动了哪些内容。

第五个节点是输出回写节点。我们配置了两个并行的输出分支。第一个分支调用企业内部文档库的API,将翻译结果按照"产品名称/语言/版本"的目录结构上传。第二个分支根据target_country参数,自动生成对应国家药监局要求的提交包格式。比如FDA要求的eCTD包需要包含五个模块的文件夹结构,而EMA的CESP格式则需要特定的XML元数据文件。

picture.image

至此,整个工作流的搭建就完成了。我们点击右上角的"测试运行"按钮进行验证。上传一份真实的药品说明书PDF,选择目标语言为"俄语",点击运行。

picture.image

系统开始执行各个节点。首先是ParseX节点,我们可以在调试面板看到它成功识别了文档中的英文正文、拉丁学名、化学分子式,并准确还原了三个复杂的剂量对照表。

picture.image

处理时间显示为2.3秒,这对于一份200页的文档来说已经是相当快的速度。解析结果中我们可以看到清晰的结构化信息,比如第15页第3段被标记为{"type": "paragraph", "level": 2, "bbox": [120, 450, 480, 520], "language": "en", "content": "Adverse reactions reported in clinical trials..."}。

接下来术语检索节点从知识库中召回了35个专业术语的标准翻译对照。比如检索到"Adverse reactions"应该翻译为德语的"Nebenwirkungen"而不是通用翻译工具给出的"unerwünschte Reaktionen"。

然后LLM节点开始执行翻译任务。通过右侧的实时日志,我们可以看到豆包模型正在逐章节处理文档。由于启用了流式输出,翻译结果会实时显示在预览区。整个翻译过程耗时约20秒,这已经包含了对200页内容的完整处理。

picture.image

版本对比节点执行后,生成了一份差异报告。系统检测到相比上一版本,本次修订主要集中在"禁忌症"章节,新增了3条关于孕妇用药的警告信息,并且将推荐剂量从"50-100mg"调整为"75-150mg"。这些变更在输出文档中会用醒目的颜色标记。

picture.image

最后输出节点成功将翻译结果上传到企业文档库,并生成了符合EMA规范的CESP提交包。整个流程从PDF上传到最终输出,总共用时不到4分钟。

为了测试系统的鲁棒性,我们又上传了一份包含大量表格和化学结构式的复杂文档。ParseX节点依然准确识别了所有表格的行列关系,甚至连跨页表格也能正确合并。

picture.image

LLM节点在翻译时自动跳过了化学分子式"C9H8O4"和临床试验编号"NCT01234567",符合我们在提示词中设定的规则。

确认测试无误后,我们点击"发布"按钮。系统会生成一个生产环境的API端点,同时在企业内网部署一个简易的Web界面供业务人员使用。

picture.image

在实际部署的第一周,研发部门共处理了12份说明书的多语言翻译任务。我们对系统的性能进行了详细监控,以下是与传统人工流程的对比数据:

对比维度传统人工流程TextIn+火山引擎方案
单份文档处理时间(200页)5-7天3.5小时
单页文档P99耗时不适用1.8秒
翻译准确率(术语一致性)76%(人工疲劳波动)94%(术语库标准化)
版本变更识别准确率65%(依赖人工对比)99%(自动化diff)
单份文档成本(包含人力)¥8,000-12,000¥180(API调用费)
支持语言数量5种(需外包)50+种(即时切换)
版本同步周期需单独处理,额外3天实时完成

从这组数据可以看出,智能系统在处理速度上实现了近40倍的提升。更重要的是成本的大幅下降,原本一份文档的翻译费用在万元级别,现在只需要不到200元的API调用费,这还没有计算人力成本的节省。准确率方面,虽然人工翻译的整体质量仍有优势,但在术语一致性这个关键指标上,机器翻译配合术语库的方案反而更胜一筹,因为人类翻译往往会在200页的长文档中出现前后术语不统一的情况。

项目上线一个月后,我们收集了业务部门的反馈。最受好评的功能是版本差异自动标记,药监事务部门表示这个功能让他们在准备申报材料时节省了大量时间,以前需要两个人花一整天逐页对比新旧版本,现在3分钟就能得到完整的差异报告。另一个意外的收获是术语库的持续优化,每次翻译完成后,系统会将新出现的术语及其翻译结果记录下来,经过人工审核后加入术语库,使得模型的翻译质量随着使用次数的增加而不断提升。

四、总结

通过这个跨国药企多语言手册翻译系统的实战,我们看到了TextIn与火山引擎结合的三大核心价值。第一是多语言多格式的一站式解析能力,TextIn能够处理50+种语言、20+种格式,输出包含坐标和结构信息的标准化数据,这解决了跨国企业文档"语言+版式"碎片化的痛点。第二是低代码Agent编排能力,火山引擎Coze平台让业务人员只需拖拽几个节点就能构建复杂的AI应用,支持快速迭代和灰度发布,这解决了IT团队人手不足、需求频繁变更的困境。第三是结构化RAG增强能力,将TextIn的解析引擎接入向量数据库,让检索从纯文本升级为多维度结构化召回,准确率提升40%以上。

picture.image

这套方案的可复制性很强。同样的架构可以快速应用到跨国合同审查、贸易单据核验、广告合规巡检等场景。企业只需要根据业务特点调整术语库内容和提示词规则,就能在一周内上线新的智能应用。对于正在推进国际化的企业来说,多语言文档处理能力将成为核心竞争力,而TextIn与火山引擎的组合,正在让这种能力从少数大厂的专属技术,变成任何企业都能快速部署的标准化解决方案。

产品注册体验链接: https://www.textin.com/register/code/KKBKQ6 注册即送TextIn平台3000页体验

体验指南/产品资料包: https://ai.feishu.cn/drive/folder/LzYmfgsutl499idcfx6cef7snV4?from=from_copylink

0
0
0
0
关于作者
关于作者

文章

0

获赞

0

收藏

0

相关资源
边缘云原生操作系统设计与思考
《火山引擎边缘云原生操作系统设计与思考》 徐广治 | 火山引擎边缘云资深架构师
相关产品
评论
未登录
看完啦,登录分享一下感受吧~
暂无评论