一、商业信息查询介绍

首先来介绍一下商业信息查询的应用场景。

• 商务合作：评估合作伙伴的资质和规模，判断合作潜力。
• 销售展业：快速获取目标企业的有效联系方式，加速业务推进。
• 成本控制：通过了解供应商的成本结构和心理底价，运用博弈策略优化采购价格，实现成本节约。
• 消费决策：“职业闭店人”泛滥，如何在办理各种消费卡时避免踩雷。
• 投资理财：如何选择股票，避免被“割韭菜”。

以上场景中，有些是现代商业决策的关键，有些则与我们个人生活息息相关。要解决这些问题，方案之一就是去查询这些企业的信息，其投资关系、供应链关系，这就是商业信息查询。

商业信息查询是一个职场多边手，能够助力我们的一些重要决策。

大部分商业信息查询服务，如天眼查、企查查、爱企查等，主要通过整合来自公开渠道、第三方平台和官方记录的海量数据，为用户提供全面、精准的信息服务。这些平台收集包括企业注册信息、财务数据、法律诉讼、行业动态等多元信息，将其产品化，以满足不同用户需求。

服务对象广泛，既面向 B 端企业，帮助企业进行市场调研、竞争对手分析、风险评估等，也惠及 C 端个人用户，在消费决策、投资理财、职业规划等方面提供数据支持。以百度旗下爱企查为例，其效果显著，为用户提供了高效、便捷的商业信息查询体验。通过这些平台，用户能够快速获取所需信息，做出更明智的商业和生活决策。

我们在去年底开始利用 Copilot 来助力爱企查转型升级，革新交互体验，提升商业效率。Copilot 的核心功能在于精准匹配供需双方，既满足买家的采购需求，又确保卖家的优质供给，通过高效撮合，促进了双方的深度交流与合作。

至今年 3 月，Copilot 系统展现出显著成效，具体表现为：

• 对话满意度提升 52%：通过智能匹配，对话质量显著提高，用户反馈更加积极。
• 对话开口率提升 54%：系统精准推荐，有效提高了双方沟通的针对性和效率。
• 日均留资量提升 329%：这一商业指标的大幅提升，意味着系统能够显著增加用户的活跃度和粘性，对于爱企查这样的通用平台而言，这意味着从免费用户到付费用户的转化率得到了显著提升。

Copilot 通过优化匹配机制，不仅提升了用户对话的满意度和效率，还直接促进了企业的收益增长，增强了用户体验。这一成果证明，Copilot 是企业数字化转型的有效工具。通过 Compiler，企业能够更加精准地触达目标客户，提高转化率，实现商业目标的同时，也为用户创造更多价值。

二、文心大模型构建商业智能助手的几种模式

接下来介绍我们如何利用文心大模型构建商业智能助手。

1. 检索增强技术（RAG）

第一种模式就是利用检索增强技术，即检索一些文档用做知识增强。然而，单纯依赖 RAG 在商业场景下的局限性逐渐显现，尤其是在面对庞大商业知识库和复杂企业关系时，直接的网络文档检索往往无法提供准确、深入的信息。这正是爱企查等商业信息查询平台存在的价值，它们拥有数亿条企业数据和数十亿条商业知识，远超普通搜索引擎的覆盖范围。

挑战与局限在于：

• 理解深度与广度的缺失：例如查询企业联系方式，RAG 往往返回客服电话，而对于销售或商务合作，这显然不够精准。再如腾讯投资案例，RAG 可能列出美团、拼多多，却忽略了这些公司与腾讯的间接投资关系，以及腾讯内部复杂的投资架构。
• 推理能力的局限：查询腾讯老板投资的公司，RAG 给出的仍是腾讯直接投资的企业，未能理解“腾讯老板”指代的是马化腾，且马化腾的个人投资与腾讯公司投资存在差异。

为克服上述挑战，我们提出了一种融合企业自建知识库与文心大模型的解决方案。

首先，对用户查询进行深度意图识别，明确查询目标是特定企业及所需属性（如电话、法人等）接着，利用企业知识库进行精准查询，将查询结果反馈给文心大模型，由其生成最终的、高度个性化的回答。

例如，查询腾讯的联系电话时，我们先识别出查询意图，然后在知识库中以“腾讯”为 key，“电话”为 value 进行查询，将结果交由文心大模型处理，生成精确回答。对于腾讯投资的公司，模型不再局限于表面关联，而是揭示了如华谊兄弟等与腾讯有实际持股比例的复杂关系。

又如，查询腾讯的法人投资了哪些公司。这时的意图识别变得更加复杂。为了解决这类复杂查询，我们提出了知识图谱检索方案。

在查询时，不再是简单地通过写一些规则去查，而是利用大模型的代码生成能力，生成 SQL 查询语句。然而直接生成代码的准确率初时较低，大约在 10% 左右，这主要是由于模型对具体数据库结构理解的不足。

为提高代码生成的准确率，我们采取了以下两步优化策略：

• 注入表结构知识：首先，我们向模型中注入数据库的表结构（schema）信息，帮助模型理解数据库字段，减少字段匹配错误。这一举措显著提升了代码的正确性，准确率可提升至 40% 左右。
• 样例学习：进一步，我们利用大模型的学习能力，通过提供具体场景下的样例查询，让模型在实际应用中学习和优化。这种 in-context learning（上下文学习）策略使得模型能够根据样例调整生成策略，准确率可进一步提升至 70% 到 80%，实现了质的飞跃。

然而，大模型上下文窗口是有限制的，当查询涉及多表、多字段的复杂数据库时，直接将所有表结构（schema）信息嵌入 prompt 中变得不切实际。为解决这一问题，我们采用了 schema linking 策略：

• 动态 schema 提取：首先，根据用户查询内容，动态识别所需查询的表及字段，避免一次性加载全部表结构。
• 缩减与优化：通过分析查询需求，仅将相关表的 schema 信息嵌入 prompt，实现对上下文窗口的有效利用。

最终，这一策略不仅解决了上下文窗口限制，还提升了查询效率，确保了大模型在复杂数据库查询场景下的实际可用性。

去年项目启动时，我们对零样本（zero-shot）和少量样本（few-shot）学习的效果进行了初步调研，比较了文心 ErnieBot、ChatGLM、ChatGLM 精调和 LLaMA-Chinese-alpaca 精调的表现。调研结果表明，尽管这些模型在服务效率上表现出了初步的实用性，但与实际应用落地的高要求相比，仍有不小差距。这一发现促使我们深入研究模型优化策略，特别是如何通过样例学习（in-context learning）和大模型的反思能力提升模型性能。

我们发现，通过给定特定场景下的样例，模型能够学习到更具体的查询模式，从而显著提升查询准确性。然而，模型在生成代码（如图数据库的查询语句）时，仍可能出现错误，这引发了外界对大模型能力的质疑。值得注意的是，大模型具备自我反思与修正的能力，这一特性为提升整体准确率提供了新的途径。

我们让模型在生成查询语句后，进行自我检查与修正。以图数据库为例，模型生成的图查询语句（GQL）可能包含边向性（in/out）错误，或存在点与边的匹配错误。通过让模型反思并修正这些错误，查询的准确性得到了显著提升。例如，查询“腾讯有哪些高管？”时，模型能够识别并修正边的向性错误，将错误的“out”改为正确的“in”。同样，对于“查询马化腾在腾讯的职位？”这一问题，模型能够识别并修正点到点、边到点的匹配错误，确保查询的准确性。

这一策略的应用，使得模型在复杂查询场景下的表现大幅提升，最终线上准确率超过 90%。

对于间接投资关系的查询，模型展现了强大的通用性。例如，查询“小米公司间接投资了哪些公司？”时，模型能够追踪复杂的多层投资链，揭示小米通过 A 公司间接投资 B 公司的关系，而无需依赖特定模板。这一能力仅通过大模型的代码生成与反思能力即可实现，展现了在复杂知识图谱游走与查询方面的强大潜力。

三、文心大模型构建商业智能助手进阶

在很多场景中，我希望答案通过图形可视化地呈现。

我们采用了开源工具 Apache ECharts。这一工具提供了很多不同种类的图表，其中的关系图非常契合商业信息查询的场景。

我们设计了一套利用大模型生成可视化图表的方案。首先，模型被定位为图表专家，而非传统的数据库工程师。用户提出需求，模型接收查询结果数据，最后生成图表。这一方案取得了非常令人满意的效果。

我们正在探索大模型在更深层次的应用——企业风险分析。这一领域关注企业的可靠性，评估其是否会突然终止运营。通过收集目标公司及其法定代表人的信息，结合关联公司状态，我们能够进行综合风险分析，为用户提供全面的公司评估。这一分析过程不仅涉及企业基本信息，还深入考察法定代表人的信用状况，包括是否被列入失信名单，以及其名下其他公司运营情况。通过整合这些数据，我们能够提供一个综合风险评分，帮助用户判断企业合作风险。

由于此类深度分析涉及高级商业数据，通常属于 VIP 服务范畴，我们当前产品的定位为服务于所有用户，因此这一高级功能尚未正式推出。尽管如此，我们已成功在其他场景中应用了这套风险评估系统，验证了其有效性和实用性。

四、商业智能助手的未来展望

展望未来，大模型的最终价值在于应用，尤其是如何切实提升我们的工作效率。

以会议场景为例，未来的智能助手将在会议上实现即时数据分析与市场调研，为决策提供数据支持。同时，它能主动思考会议中提出的问题，识别潜在商业机会，评估风险，为讨论提供详实数据，显著提升会议效率。

这一愿景展现了大模型在日常生活与生产中的最大作用——帮助企业提效。通过智能助手的介入，我们能将更多精力投入创新与决策，让技术真正服务于人，推动企业与社会的持续进步。

以上就是本次分享的内容，谢谢大家。

五、问答环节

Q1：刚才介绍的应用，除了在爱企查，还有拓展到其它场景吗？

A1：除了爱企查这一场景，大模型的应用在企业内部数据管理中也展现出广阔前景。基础工作围绕关系数据库展开，通过 SQL 查询，实现对内部复杂数据的高效管理。这一工具在公司内部得到广泛使用，无论是产品经理（PM）还是研发人员（RD），在面对临时的数据查询需求时，都频繁依赖这一工具。然而，由于涉及内部敏感数据，无法公开演示，但其背后的方法论与爱企查场景相似，即通过将自然语言查询转化为 SQL 代码，实现精确的数据检索。

Q2：Prompt 是依靠特定的模版吗？

A2：大模型的高效应用依赖于专业的 Prompt 工程。百度强调，未来的工作将从直接编写代码转向设计 Prompt，即如何将自然语言转化为大模型能理解的输入格式。这要求工程师具备将专业领域知识融入 Prompt 的能力，以确保大模型能够准确执行复杂任务，如数据分析、市场调研等。Prompt 设计成为连接人类需求与大模型能力的关键桥梁。

Q3：内部应用的效果如何？

A3：在企业内部使用大模型进行数据管理，效果显著。用户反馈表明，对于企业用户而言，问答体验的提升达到了 50% 以上，显著增强了数据查询的效率和准确性。此外，这一工具的应用还为企业带来了实质性的商业转化提升，转化率增长超过 30%，体现了大模型在企业内部数据管理与决策支持中的巨大价值。

大模型在企业内部的应用不仅限于爱企查等公开场景，其在内部数据管理与决策支持中展现出的强大能力，为企业带来了显著的效率提升和商业价值。通过专业的 Prompt 工程，大模型能够理解并执行复杂的数据查询任务，实现与知识图谱的深度融合，为企业内部数据的高效管理提供了全新的解决方案。

Q4：我们最开始在去同步整个数据效果的时候提到了对话满意度是 52%，这个满意度是怎么算出来的？通过什么方式监测出来的？

A4：满意度评估基于用户体验，如查询结果的准确性，无法回答的查询被视为不满意。目前，评估大模型效果主要依赖人工，通过随机抽样数据进行人工检查，以标签形式给出满意度指标。尽管自动化评估是研究方向，使用大模型评估大模型的效果存在可靠性争议，人依然是最可靠的评估者。当前的评估指标虽尝试利用大模型进行自我评估，但这种方法的自动化实现面临挑战，可靠性尚待验证。人工评估仍为确保大模型性能和服务质量的关键手段。

Q5：对话开口率是什么样的一个指标？反映的是什么问题？

A5：对话开口率反映用户与机器人互动的意愿，被视为用户留存的指标。百度研究院与爱企查平台合作，采用此指标评估用户满意度。若用户初次查询获得满意回答，次日可能再次互动；反之，不满意体验将降低再次提问的可能。通过量化对话开口率，可侧面反映问答效果，作为人工评估的补充，间接衡量大模型的性能与用户接受度。

Q6：如果把样例放到 prompt 里面，会不会造成提示词特别臃肿？

A6：大模型处理能力受限于长度，schema linking 成为关键，旨在优化内容，避免超长问题。样例选择与排序对结果影响重大，需精心挑选与布局。这深入到模型应用的复杂层面，远超简单操作，如 APP 构建工具的直觉使用。尤其在数据科学领域，如代码生成，精准查找要求极高，需大量工作优化样例与 schema 链接，确保模型在长度限制下仍能高效、准确地执行任务。这要求深入理解模型机制，精心设计以应对复杂查询需求。

Q7：微调的形式和注入样例的形式对比，有明显的差距吗？

A7：微调展现更优效果，因其能全面学习样本，克服样例过多导致的注意力分散问题。相比之下，样例注入虽便捷，但在效果上略逊一筹。微调虽效果显著，但开发周期与部署成本高昂，需重新部署模型，远超直接调用 API 的经济性。我们曾对比 400 条样例的 schema linking 与微调，微调效果更佳，但成本控制是关键考量。在性能提升与成本效益间找到平衡，是优化模型应用的核心。

Q8：Open AI V3.5 为它所有的大模型提供了微调的接口，百度有类似的吗？

A8：这个微调接口我们肯定是也有的。

百度千帆平台，作为百度的模型开发与微调平台，不仅支持自研的文献模型，还兼容多种开源模型，如 Lama 3，广泛应用于迁移学习等领域。平台提供从模型训练到评估，再到应用程序开发的全套服务，包括数据集管理、数据清洗、数据增强等功能。

用户可在千帆平台上进行模型微调、部署及应用程序开发，如构建 APP、模型部署或编写自定义 Agent。平台还支持模型评估，允许用户构建固定集合进行性能检验，确保模型质量。总之，千帆平台为开发者提供了一站式解决方案，覆盖模型开发全流程，全面助力 AI 模型的高效构建与应用。

Q9：微调用的样例，包括我们整个微调的过程，上就可以理解为是一种让大模型预学习，让他具备某个领域的能力，然后前置地去具备这样的能力，是这样吗？

A9：稍微有点不太准确。

在千帆平台中，模型层级被定义为 L0、L1、L2 三个阶段。L0 代表大模型预训练阶段，即基础的通用大模型。L1 则为领域对齐模型，通过将特定行业的文档纳入训练，使模型理解并掌握领域内的专有名词，提升行业知识理解能力。L2 阶段专注于特定任务的微调，如 SQL 生成、代码撰写、文档编写、续写或问答，这一阶段称为 task-specific fine-tuning（SFT），旨在让模型在理解领域知识的基础上，进一步精炼特定任务的执行能力。