基于LLM Graph Transformer的知识图谱构建技术研究:LangChain框架下转换机制实践

本文涉及的产品
检索分析服务 Elasticsearch 版,2核4GB开发者规格 1个月
智能开放搜索 OpenSearch行业算法版,1GB 20LCU 1个月
实时计算 Flink 版,5000CU*H 3个月
简介: 本文介绍了LangChain的LLM Graph Transformer框架,探讨了文本到图谱转换的双模式实现机制。基于工具的模式利用结构化输出和函数调用,简化了提示工程并支持属性提取;基于提示的模式则为不支持工具调用的模型提供了备选方案。通过精确定义图谱模式(包括节点类型、关系类型及其约束),显著提升了提取结果的一致性和可靠性。LLM Graph Transformer为非结构化数据的结构化表示提供了可靠的技术方案,支持RAG应用和复杂查询处理。

文本到图谱的转换是一个具有技术挑战性的研究领域,其核心任务是将非结构化文本数据转换为结构化的图谱表示。这种技术虽然由来已久,但随着大型语言模型(LLMs)的发展,其应用范围得到了显著扩展,并逐渐成为主流技术方案之一。

上图展示了信息抽取过程中文本到知识图谱的转换。图左侧展示了包含个人与公司关系描述的非结构化文本文档;图右侧则展示了相同信息在知识图谱中的结构化表示,清晰地呈现了人员与组织之间的工作和创立关系。

文本信息的结构化表示具有重要的应用价值,特别是在检索增强生成(RAG)系统中。虽然在非结构化文本上直接应用文本嵌入模型是一种可行方案,但在处理需要理解多实体间关联的复杂查询,或需要进行过滤、排序、聚合等结构化操作时,这种方法往往难以满足要求。通过将文本信息转换为知识图谱,不仅可以实现更高效的数据组织,还能构建一个支持复杂实体关系理解的框架。这种结构化方法显著提升了信息检索的精确性,扩展了系统可处理的查询类型。

在过去一年中,LangChain已经将知识图谱的构建以LLM Graph Transformer的形式整合到了框架中。本文是LangChain的一个代码贡献者编写的文章,将对这些内容进行详细介绍,文章最后还包含了作者提供的源代码

Neo4j环境配置

本实现采用Neo4j作为图数据存储系统,其内置的图形可视化功能为分析提供了直观支持。推荐使用Neo4j Aura的免费云实例快速开始实验。也可以通过安装Neo4j Desktop应用程序在本地部署数据库实例。

 fromlangchain_community.graphsimportNeo4jGraph  

 graph=Neo4jGraph(  
     url="bolt://54.87.130.140:7687",  
     username="neo4j",  
     password="cables-anchors-directories",  
     refresh_schema=False  
 )

LLM Graph Transformer技术架构

LLM Graph Transformer被设计为一个可适配任意LLM的图谱构建框架。鉴于当前市场上存在大量不同的模型提供商和模型版本,实现这种通用性是一个复杂的技术挑战。LangChain在这里发挥了重要作用,提供了必要的标准化处理。LLM Graph Transformer采用了双模式设计,提供了两种相互独立的运行模式。

LLM Graph Transformer实现了两种不同的文档图谱生成模式,分别针对不同场景下的LLM应用进行了优化:

  1. 基于工具的模式(默认模式): 适用于支持结构化输出或函数调用的LLM,该模式通过LLM的内置with_structured_output功能实现工具调用。工具规范定义了标准化的输出格式,确保实体和关系提取过程的结构化和规范化。该实现方式在图左侧展示,包含了Node和Relationship类的核心代码实现。
  2. 基于提示的模式(备选模式): 针对不支持工具或函数调用的LLM设计的备选方案。该模式通过少样本提示技术定义输出格式,引导LLM以文本方式提取实体和关系。通过自定义解析函数将LLM输出转换为标准JSON格式,随后用于构建节点和关系。这种模式完全依赖提示引导而非结构化工具。图右侧展示了示例提示和对应的JSON输出结果。

这种双模式设计确保了LLM Graph Transformer可以适配不同类型的LLM,无论是通过工具直接构建还是通过文本提示解析来生成图谱结构。

即使使用支持工具/函数的模型,也可通过设置

_ignore_tools_usage=True_

参数启用基于提示的提取模式。

基于工具的提取实现

选择基于工具的提取方法作为主要实现方案的原因在于,它能够最大程度地减少对复杂提示工程和自定义解析函数的依赖。在LangChain框架中,

with_structured_output

方法支持通过工具或函数进行信息提取,输出格式可以通过JSON结构或Pydantic对象定义。基于可维护性考虑,作者选择了Pydantic对象作为定义方式。

首先定义节点类

Node

 classNode(BaseNode):  
     id: str=Field(..., description="Name or human-readable unique identifier")  # 名称或可读的唯一标识符
     label: str=Field(..., description=f"Available options are {enum_values}")  # 可用的标签选项
     properties: Optional[List[Property]]  # 可选属性列表

节点类包含

id

label

和可选的

properties

字段。描述id为可读的唯一标识符具有重要意义,因为某些LLM可能会将ID属性理解为传统的随机字符串或递增整数形式。而在本实现中,我们期望使用实体名称作为id属性。通过在

label

描述中明确列出可用选项来限制标签类型。对于支持

enum

参数的LLM(如OpenAI的模型),我们也利用了这一特性。关系类

Relationship

的定义如下:

 classRelationship(BaseRelationship):  
     source_node_id: str  # 源节点标识符
     source_node_label: str=Field(..., description=f"Available options are {enum_values}")  # 源节点标签
     target_node_id: str  # 目标节点标识符
     target_node_label: str=Field(..., description=f"Available options are {enum_values}")  # 目标节点标签
     type: str=Field(..., description=f"Available options are {enum_values}")  # 关系类型
     properties: Optional[List[Property]]  # 可选属性列表

这是

Relationship

类的第二个迭代版本。在初始版本中,源节点和目标节点采用嵌套的

Node

对象表示,但实践表明这种结构降低了提取过程的准确性和质量。因此,在当前版本中,我们将源节点和目标节点分解为独立字段,如

source_node_id

source_node_label

以及

target_node_id

target_node_label

。同时,在描述中明确定义了节点标签和关系类型的有效值,以确保LLM严格遵循指定的图谱模式。

基于工具的提取方法支持为节点和关系定义属性。属性类的定义如下:

 classProperty(BaseModel):  
     """单个属性由键值对构成"""
     key: str=Field(..., description=f"Available options are {enum_values}")  # 属性键的可用选项
     value: str  # 属性值
Property

采用键值对形式定义。这种设计虽然具有灵活性,但也存在一些技术限制:

  • 无法为各个属性提供独立的描述
  • 无法指定必需属性和可选属性的区分
  • 属性定义采用全局共享方式,而非针对特定节点或关系类型单独定义

系统还实现了详细的系统提示来指导提取过程。但经验表明,函数和参数描述通常比系统消息对提取质量的影响更大。

当前LLM Graph Transformer框架的一个局限在于,缺乏简便的函数或参数描述自定义机制。

基于提示的提取实现

考虑到当前只有少数商业LLM和LLaMA 3支持原生工具功能,我们为不支持工具的模型实现了备选方案。即使在使用支持工具的模型时,也可以通过设置

ignore_tool_usage=True

来启用基于提示的提取方式。

基于提示方法的主要提示工程实现和示例由Geraldus Wilsen贡献。在这种方法中,输出结构直接在提示中定义。以下是系统提示的核心部分:

 你是一个专门用于结构化信息提取的高性能算法,用于构建知识图谱。你的任务是从给定文本中识别用户提示指定的实体和关系,并生成JSON格式的输出。输出应为JSON对象列表,每个对象包含以下字段:

 -**"head"**: 提取的实体文本,必须匹配用户提示中指定的类型
 -**"head_type"**: 提取的头部实体类型,从指定类型列表中选择
 -**"relation"**: "head"与"tail"之间的关系类型,从允许的关系列表中选择
 -**"tail"**: 关系尾部实体的文本表示
 -**"tail_type"**: 尾部实体类型,从提供的类型列表中选择

 要求:
 1.最大化提取实体和关系信息
 2.确保实体表示的一致性:同一实体的不同表述(如"John Doe"可能表现为"Joe"或代词"他")应统一使用最完整的标识符
 3.输出应仅包含结构化数据,不包含任何额外说明或文本
 ```基于提示的方法与基于工具的方法存在几个关键差异:
 1.仅提取关系而不提取独立节点,因此不会产生_孤立节点_
 2.考虑到缺乏原生工具支持的模型通常性能较低,不支持属性提取,以简化输出结构

 以下是典型的少样本示例实现:

 ```python
 examples= [  
     {  
         "text": (  
             "Adam is a software engineer in Microsoft since 2009, "  # Adam自2009年起在Microsoft担任软件工程师
             "and last year he got an award as the Best Talent"  # 去年获得最佳人才奖
         ),  
         "head": "Adam",  
         "head_type": "Person",  
         "relation": "WORKS_FOR",  
         "tail": "Microsoft",  
         "tail_type": "Company",  
     },  
     {  
         "text": (  
             "Adam is a software engineer in Microsoft since 2009, "  
             "and last year he got an award as the Best Talent"  
         ),  
         "head": "Adam",  
         "head_type": "Person",  
         "relation": "HAS_AWARD",  
         "tail": "Best Talent",  
         "tail_type": "Award",  
     },  
 ...  
 ]

当前实现中,无法添加自定义少样本示例或补充指令,唯一的定制方式是通过

prompt

属性修改整体提示内容。扩展自定义功能是未来的重要开发方向。

图谱模式定义

在使用LLM Graph Transformer进行信息提取时,完善的图谱模式定义对于构建高质量的知识表示至关重要。规范的图谱模式明确了需要提取的节点类型、关系类型及其相关属性,为LLM提供了明确的提取指导框架。

为了验证实现效果,我们选取了玛丽·居里维基百科页面的开篇段落作为测试数据,并在末尾添加了一条关于罗宾·威廉姆斯的信息:

 fromlangchain_core.documentsimportDocument  

 text="""  
 Marie Curie, 7 November 1867 – 4 July 1934, was a Polish and naturalised-French physicist and chemist who conducted pioneering research on radioactivity.  
 She was the first woman to win a Nobel Prize, the first person to win a Nobel Prize twice, and the only person to win a Nobel Prize in two scientific fields.  
 Her husband, Pierre Curie, was a co-winner of her first Nobel Prize, making them the first-ever married couple to win the Nobel Prize and launching the Curie family legacy of five Nobel Prizes.  
 She was, in 1906, the first woman to become a professor at the University of Paris.  
 Also, Robin Williams.  
 """  
 documents= [Document(page_content=text)]

实验中采用GPT-4作为基础模型:

 fromlangchain_openaiimportChatOpenAI  
 importgetpass  
 importos  

 os.environ["OPENAI_API_KEY"] =getpass.getpass("OpenAI api key")  

 llm=ChatOpenAI(model='gpt-4o')

首先分析未定义图谱模式时的信息提取效果:

 fromlangchain_experimental.graph_transformersimportLLMGraphTransformer  

 no_schema=LLMGraphTransformer(llm=llm)

使用异步函数

aconvert_to_graph_documents

处理文档。在LLM提取场景中,异步处理的优势在于支持多文档并行处理,可显著提升处理效率和吞吐量:

data = await no_schema.aconvert_to_graph_documents(documents)

LLM Graph Transformer返回的图文档结构如下:

[  
    GraphDocument(  
        nodes=[  
            Node(id="Marie Curie", type="Person", properties={}),  
            Node(id="Pierre Curie", type="Person", properties={}),  
            Node(id="Nobel Prize", type="Award", properties={}),  
            Node(id="University Of Paris", type="Organization", properties={}),  
            Node(id="Robin Williams", type="Person", properties={}),  
        ],  
        relationships=[  
            Relationship(  
                source=Node(id="Marie Curie", type="Person", properties={}),  
                target=Node(id="Nobel Prize", type="Award", properties={}),  
                type="WON",  
                properties={},  
            ),  
            Relationship(  
                source=Node(id="Marie Curie", type="Person", properties={}),  
                target=Node(id="Nobel Prize", type="Award", properties={}),  
                type="WON",  
                properties={},  
            ),  
            Relationship(  
                source=Node(id="Marie Curie", type="Person", properties={}),  
                target=Node(  
                    id="University Of Paris", type="Organization", properties={}  
                ),  
                type="PROFESSOR",  
                properties={},  
            ),  
            Relationship(  
                source=Node(id="Pierre Curie", type="Person", properties={}),  
                target=Node(id="Nobel Prize", type="Award", properties={}),  
                type="WON",  
                properties={},  
            ),  
        ],  
        source=Document(  
            metadata={"id": "de3c93515e135ac0e47ca82a4f9b82d8"},  
            page_content="\nMarie Curie, 7 November 1867 – 4 July 1934, was a Polish and naturalised-French physicist and chemist who conducted pioneering research on radioactivity.\nShe was the first woman to win a Nobel Prize, the first person to win a Nobel Prize twice, and the only person to win a Nobel Prize in two scientific fields.\nHer husband, Pierre Curie, was a co-winner of her first Nobel Prize, making them the first-ever married couple to win the Nobel Prize and launching the Curie family legacy of five Nobel Prizes.\nShe was, in 1906, the first woman to become a professor at the University of Paris.\nAlso, Robin Williams!\n",  
        ),  
    )  
]

图文档包含

nodes

relationships

source

三个主要部分,分别对应提取的节点、关系及源文档信息。使用Neo4j Browser可以直观地可视化这些输出结果。

上图展示了对同一段玛丽·居里文本的两次独立提取结果。这里使用了支持基于工具提取的GPT-4模型,该模式允许生成孤立节点。由于未定义图谱模式,LLM在运行时自主决定提取的信息内容,这导致了输出结果的不确定性。即使是相同的输入文本,不同提取过程的结果在细节上也存在差异。例如,左图将Marie标注为诺贝尔奖的

WINNER

,而右图则使用

WON

表示获奖关系。

对于支持工具的模型,可以通过设置

ignore_tool_usage

参数启用基于提示的提取模式:

no_schema_prompt = LLMGraphTransformer(llm=llm, ignore_tool_usage=True)  
data = await no_schema.aconvert_to_graph_documents(documents)

让我们同样对这种方式的两次独立执行结果进行可视化分析。

基于提示的方法不会生成孤立节点,这是它与工具模式的一个显著区别。但与之前的情况类似,由于缺乏明确的模式约束,不同运行之间的输出结构仍存在变异性。

接下来,我们将探讨如何通过定义合适的图谱模式来提升输出的一致性。

节点类型定义

约束图谱结构是提升信息提取质量的关键技术手段。通过精确定义图谱模式,可以引导模型聚焦于特定的实体类型和关系模式,从而提升提取结果的一致性和可预测性。规范的模式定义不仅确保了提取数据的标准化,还能有效避免关键信息的遗漏和非预期元素的引入。

首先通过

allowed_nodes

参数定义预期的节点类型:

allowed_nodes = ["Person", "Organization", "Location", "Award", "ResearchField"]  
nodes_defined = LLMGraphTransformer(llm=llm, allowed_nodes=allowed_nodes)  
data = await nodes_defined.aconvert_to_graph_documents(documents)

上述代码定义了五种核心节点类型。为了评估其效果,我们对比分析两次独立执行的结果:

通过节点类型的预定义,提取结果的一致性得到了明显提升。但仍存在一些细节层面的差异,例如第一次运行将"radioactivity"识别为研究领域,而第二次运行则未能捕获这一信息。

由于未对关系类型进行约束,关系提取的结果在不同运行间仍表现出较大的变异性。同时,不同运行捕获的信息粒度也存在差异。例如,Marie和Pierre之间的

MARRIED_TO

关系并未在两次提取中都被识别出来。

关系类型定义

为了解决关系提取的不一致问题,需要引入关系类型的定义机制。最基础的方法是通过可用类型列表来规范化关系:

allowed_nodes = ["Person", "Organization", "Location", "Award", "ResearchField"]  
allowed_relationships = ["SPOUSE", "AWARD", "FIELD_OF_RESEARCH", "WORKS_AT", "IN_LOCATION"]  
rels_defined = LLMGraphTransformer(  
  llm=llm,   
  allowed_nodes=allowed_nodes,  
  allowed_relationships=allowed_relationships  
)  
data = await rels_defined.aconvert_to_graph_documents(documents)

分析两次独立执行的结果:

预定义节点和关系类型条件下的两次提取结果对比。作者提供。

节点和关系类型的双重约束显著提升了提取结果的一致性。例如,Marie的获奖信息、配偶关系以及在巴黎大学的工作关系在不同运行中都得到了稳定的提取。然而,由于关系定义采用了通用列表的形式,没有对关系的连接节点类型进行限制,仍然存在一些变异性。比如,

FIELD_OF_RESEARCH

关系可能连接

Person

ResearchField

,也可能连接

Award

ResearchField

。由于未定义关系的方向性,提取结果在关系方向上可能出现不一致。

为了进一步提升关系提取的准确性,我们引入了更精细的关系定义方式:

allowed_nodes = ["Person", "Organization", "Location", "Award", "ResearchField"]  
allowed_relationships = [  
    ("Person", "SPOUSE", "Person"),  
    ("Person", "AWARD", "Award"),  
    ("Person", "WORKS_AT", "Organization"),  
    ("Organization", "IN_LOCATION", "Location"),  
    ("Person", "FIELD_OF_RESEARCH", "ResearchField")  
]  
rels_defined = LLMGraphTransformer(  
  llm=llm,   
  allowed_nodes=allowed_nodes,  
  allowed_relationships=allowed_relationships  
)  
data = await rels_defined.aconvert_to_graph_documents(documents)

这里采用三元组形式定义关系,分别指定源节点类型、关系类型和目标节点类型,从而实现了更严格的关系约束。让我们分析采用三元组关系定义后的提取结果:

三元组方式的关系定义为提取过程提供了更严格的模式约束,显著提升了跨运行的一致性。然而,考虑到LLM本身的特性,提取的细节完整度仍可能存在差异。例如,右侧图中显示了Pierre获得诺贝尔奖的信息,而左侧图中则未能捕获这一细节。

属性定义机制

对图谱模式的最后一层优化是节点和关系的属性定义。系统提供了两种属性定义方式:

第一种方式是将

node_properties

relationship_properties

设置为

true

,允许LLM自主决定要提取的属性:

allowed_nodes = ["Person", "Organization", "Location", "Award", "ResearchField"]  
allowed_relationships = [  
    ("Person", "SPOUSE", "Person"),  
    ("Person", "AWARD", "Award"),  
    ("Person", "WORKS_AT", "Organization"),  
    ("Organization", "IN_LOCATION", "Location"),  
    ("Person", "FIELD_OF_RESEARCH", "ResearchField")  
]  
node_properties=True  
relationship_properties=True  
props_defined = LLMGraphTransformer(  
  llm=llm,   
  allowed_nodes=allowed_nodes,  
  allowed_relationships=allowed_relationships,  
  node_properties=node_properties,  
  relationship_properties=relationship_properties  
)  
data = await props_defined.aconvert_to_graph_documents(documents)  
graph.add_graph_documents(data)

分析提取结果:

启用LLM的自主属性提取能力后,系统成功捕获了多个重要属性。例如,玛丽·居里的出生和死亡日期、她在巴黎大学的教授职位信息,以及多次获得诺贝尔奖的成就等。这些补充属性显著增强了图谱的信息密度。

第二种方式是通过显式定义来指定需要提取的节点和关系属性:

allowed_nodes = ["Person", "Organization", "Location", "Award", "ResearchField"]  
allowed_relationships = [  
    ("Person", "SPOUSE", "Person"),  
    ("Person", "AWARD", "Award"),  
    ("Person", "WORKS_AT", "Organization"),  
    ("Organization", "IN_LOCATION", "Location"),  
    ("Person", "FIELD_OF_RESEARCH", "ResearchField")  
]  
node_properties=["birth_date", "death_date"]  
relationship_properties=["start_date"]  
props_defined = LLMGraphTransformer(  
  llm=llm,   
  allowed_nodes=allowed_nodes,  
  allowed_relationships=allowed_relationships,  
  node_properties=node_properties,  
  relationship_properties=relationship_properties  
)  
data = await props_defined.aconvert_to_graph_documents(documents)  
graph.add_graph_documents(data)

属性通过两个独立的列表进行定义。检查提取结果:

在预定义属性模式下,系统准确提取了人物的出生和死亡日期。此外,还成功捕获了玛丽在巴黎大学任教的开始时间信息。

虽然属性提取显著丰富了图谱的信息内容,但当前实现存在以下技术限制:

  1. 属性提取仅支持基于工具的模式
  2. 所有属性值都被统一处理为字符串类型
  3. 属性定义采用全局方式,无法针对特定节点标签或关系类型进行定制
  4. 缺乏属性描述的自定义机制,无法为LLM提供更精确的提取指导

严格模式实现

尽管我们通过精心设计的提示工程努力确保LLM遵循预定义的模式,但实践表明特别是对于性能较弱的模型,要实现完全的指令遵从仍具有挑战性。所以我们引入了

strict_mode

作为后处理机制,用于过滤不符合预定义图谱模式的提取结果,从而确保输出的规范性。

strict_mode

默认开启,可通过以下配置关闭:

LLMGraphTransformer(  
  llm=llm,   
  allowed_nodes=allowed_nodes,  
  allowed_relationships=allowed_relationships,  
  strict_mode=False  
)

关闭严格模式后,LLM可能会生成预定义模式之外的节点或关系类型,这种灵活性可能导致输出结构的不确定性。

图文档数据库导入

LLM Graph Transformer提取的图文档可通过

add_graph_documents

方法导入Neo4j等图数据库,以支持后续的分析和应用。系统提供了多种导入选项以适应不同场景需求。

基础导入实现

最简单的导入方式如下:

graph.add_graph_documents(graph_documents)

此方法直接导入图文档中的所有节点和关系数据。本文前述示例均采用此方式进行结果展示。

基础实体标签机制

图数据库通常使用索引优化数据导入和检索性能。以Neo4j为例,索引只能针对特定的节点标签建立。由于无法预知所有可能的节点标签,系统通过

baseEntityLabel

参数为每个节点添加统一的次级标签,从而实现索引的高效利用:

graph.add_graph_documents(graph_documents, baseEntityLabel=True)

启用该参数后,每个节点都会获得额外的

__Entity__

标签。

源文档关联机制

系统还支持导入实体的源文档信息,便于追踪实体的文本来源。通过

include_source

参数启用此功能:

graph.add_graph_documents(graph_documents, include_source=True)

导入结果示例:

图中蓝色节点表示源文档,通过

MENTIONS

关系与提取的实体建立连接。这种设计支持结构化和非结构化检索的混合应用。

总结

本文深入探讨了LangChain的LLM Graph Transformer框架及其文本到图谱转换的双模式实现机制。作为主要技术路线的基于工具模式利用结构化输出和函数调用能力,有效降低了提示工程的复杂度,并支持属性提取。而基于提示模式则为不支持工具调用的模型提供了备选方案,通过少样本示例引导模型行为。

研究表明,精确定义的图谱模式(包括节点类型、关系类型及其约束)能显著提升提取结果的一致性和可靠性。无论采用何种模式,LLM Graph Transformer都为非结构化数据的结构化表示提供了可靠的技术方案,有效支持了RAG应用和复杂查询处理。

本文代码在这里,有兴趣的自行查看:

https://avoid.overfit.cn/post/d673e2dec79b4df9823113e60d110ceb

作者:Tomaz Bratanic

目录
相关文章
|
4天前
|
弹性计算 双11 开发者
阿里云ECS“99套餐”再升级!双11一站式满足全年算力需求
11月1日,阿里云弹性计算ECS双11活动全面开启,在延续火爆的云服务器“99套餐”外,CPU、GPU及容器等算力产品均迎来了全年最低价。同时,阿里云全新推出简捷版控制台ECS Lite及专属宝塔面板,大幅降低企业和开发者使用ECS云服务器门槛。
|
22天前
|
存储 弹性计算 人工智能
阿里云弹性计算_通用计算专场精华概览 | 2024云栖大会回顾
阿里云弹性计算产品线、存储产品线产品负责人Alex Chen(陈起鲲)及团队内多位专家,和中国电子技术标准化研究院云计算标准负责人陈行、北京望石智慧科技有限公司首席架构师王晓满两位嘉宾,一同带来了题为《通用计算新品发布与行业实践》的专场Session。本次专场内容包括阿里云弹性计算全新发布的产品家族、阿里云第 9 代 ECS 企业级实例、CIPU 2.0技术解读、E-HPC+超算融合、倚天云原生算力解析等内容,并发布了国内首个云超算国家标准。
阿里云弹性计算_通用计算专场精华概览 | 2024云栖大会回顾
|
4天前
|
人工智能 弹性计算 文字识别
基于阿里云文档智能和RAG快速构建企业"第二大脑"
在数字化转型的背景下,企业面临海量文档管理的挑战。传统的文档管理方式效率低下,难以满足业务需求。阿里云推出的文档智能(Document Mind)与检索增强生成(RAG)技术,通过自动化解析和智能检索,极大地提升了文档管理的效率和信息利用的价值。本文介绍了如何利用阿里云的解决方案,快速构建企业专属的“第二大脑”,助力企业在竞争中占据优势。
|
2天前
|
人工智能 自然语言处理 安全
创新不设限,灵码赋新能:通义灵码新功能深度评测
自从2023年通义灵码发布以来,这款基于阿里云通义大模型的AI编码助手迅速成为开发者心中的“明星产品”。它不仅为个人开发者提供强大支持,还帮助企业团队提升研发效率,推动软件开发行业的创新发展。本文将深入探讨通义灵码最新版本的三大新功能:@workspace、@terminal 和 #team docs,分享这些功能如何在实际工作中提高效率的具体案例。
|
8天前
|
负载均衡 算法 网络安全
阿里云WoSign SSL证书申请指南_沃通SSL技术文档
阿里云平台WoSign品牌SSL证书是由阿里云合作伙伴沃通CA提供,上线阿里云平台以来,成为阿里云平台热销的国产品牌证书产品,用户在阿里云平台https://www.aliyun.com/product/cas 可直接下单购买WoSign SSL证书,快捷部署到阿里云产品中。
2162 6
阿里云WoSign SSL证书申请指南_沃通SSL技术文档
|
1天前
|
安全 数据建模 网络安全
2024阿里云双11,WoSign SSL证书优惠券使用攻略
2024阿里云“11.11金秋云创季”活动主会场,阿里云用户通过完成个人或企业实名认证,可以领取不同额度的满减优惠券,叠加折扣优惠。用户购买WoSign SSL证书,如何叠加才能更加优惠呢?
803 1
|
20天前
|
编解码 Java 程序员
写代码还有专业的编程显示器?
写代码已经十个年头了, 一直都是习惯直接用一台Mac电脑写代码 偶尔接一个显示器, 但是可能因为公司配的显示器不怎么样, 还要接转接头 搞得桌面杂乱无章,分辨率也低,感觉屏幕还是Mac自带的看着舒服
|
27天前
|
存储 人工智能 缓存
AI助理直击要害,从繁复中提炼精华——使用CDN加速访问OSS存储的图片
本案例介绍如何利用AI助理快速实现OSS存储的图片接入CDN,以加速图片访问。通过AI助理提炼关键操作步骤,避免在复杂文档中寻找解决方案。主要步骤包括开通CDN、添加加速域名、配置CNAME等。实测显示,接入CDN后图片加载时间显著缩短,验证了加速效果。此方法大幅提高了操作效率,降低了学习成本。
5395 15
|
14天前
|
人工智能 关系型数据库 Serverless
1024,致开发者们——希望和你一起用技术人独有的方式,庆祝你的主场
阿里云开发者社区推出“1024·云上见”程序员节专题活动,包括云上实操、开发者测评和征文三个分会场,提供14个实操活动、3个解决方案、3 个产品方案的测评及征文比赛,旨在帮助开发者提升技能、分享经验,共筑技术梦想。
1170 152
|
22天前
|
存储 缓存 关系型数据库
MySQL事务日志-Redo Log工作原理分析
事务的隔离性和原子性分别通过锁和事务日志实现,而持久性则依赖于事务日志中的`Redo Log`。在MySQL中,`Redo Log`确保已提交事务的数据能持久保存,即使系统崩溃也能通过重做日志恢复数据。其工作原理是记录数据在内存中的更改,待事务提交时写入磁盘。此外,`Redo Log`采用简单的物理日志格式和高效的顺序IO,确保快速提交。通过不同的落盘策略,可在性能和安全性之间做出权衡。
1586 14