赞
踩
最近一周在公司总部参加大模型培训,之后总部组织了参培人员的交流发言,让大家谈谈大模型产品在省侧落地应用和AI人才发展的意见和建议。下面是我重新组织的当时的发言内容,共提了三个建议,主要是自己在做大模型过程中的一些反思。
1、第一个建议,就是做大模型,一定要以业务导向,选择有主动意愿,一把手推动力很强的的业务部门来合作。
去年以来我们做了不少大模型,例如ChatBI,ChatOA等,但都不能算成功。然而,在个别场景中,如公文核稿方面,还是取得了一定进展,这主要得益于业务部门的主动推动。目前,靠IT部门独立去推动大模型研发、建设和应用,难度还是很大的,而且不少工作非IT所长。
近期我们在推财务的智乎大模型,由财务部一把手主推,全省上百号好财务人员共同参与测试,1周提的问题数就超过3000个,这样我们跟业务的交互非常频繁,模型的按周迭代就真的能做起来,现在准确率做到了90%左右,离实用已经比较接近了。
在做财务的智乎大模型过程中,我们发现最有价值的工作恰恰是那些看似笨拙、但却朴实无华的工作,特别是要重视FAQ的完整搜集,然后去做针对性的提升,这样会事半功倍。
例如,为每个地市设立一个独立的向量库,就能很大程度解决大模型水土不服的问题,但如果没有业务人员持续的反馈这个问题,我们不会将其列入大模型的优化列表。
但要让业务部门帮你做大规模测试,并且要持续很长一段时间,代价其实很大,这个极大依赖业务部门一把手的认识、主动的意愿、实际资源的投入和业务部门的创新文化,比如我们财务部门还专门搞了劳动竞赛来驱动这个事情,这真是莫大的支持。
同时,我们公司的业务重点跟业界的普遍关注点可能有所不同,因此在场景选择上更需要业务的牵引,不能跟风,更要抑制技术上的冲动,因为我们的资源有限。当然,必要的亮点还是需要,但做盆景的和做风景的,还是要区分开。
2、第二个建议,考虑到当前受限的开源大模型能力,我们还是要从小做起,要努力寻找最合适的,最细分的业务切片场景。
做企业的垂类模型,开始的时候,一定是场景越细越好,从当前的生产流程中去嵌入,先要做到+AI,再考虑AI+,这个主要受限于我们当前的数据能力和开源基础大模型的能力,场景越细,对数据和开源模型要求越低,准确率就越可能达到商用的水平。
什么叫场景越细越好呢?举个例子,比如做智能办公,这个题目太大了,我们其实是做不动的,可以找一个细分赛道,例如文档核稿,但这个还是太粗,可以再细分为通用字纠错、专业名词纠错、叠词纠错等类别,然后针对每个细分类别建独立的模型,这样大模型的构建难度就降下来了。
我们现在特别需要在一个点上获得突破,建立起信心,然后才能玩下去,积累了足够的经验后,再考虑模型的泛化和通用性。
为什么先期不建议去做通用性比较大的领域模型呢?比如ChatBI,因为我们企业的业务特性太明显了,大模型理解不了企业的领域术语。
我们前期在做ChatBI,发现难度很大,一个核心问题就是领域的语义理解。比如我问ChatBI:“杭州分公司的武林网格各渠道的放号情况如何”,这个大模型能回答,但一线去测试时,问:杭分的武林网格渠道的放号情况如何,大模型就理解不了了,因为“杭分”是我们业务部门对杭州分公司的简称,大模型是无法理解的。
类似的问题就太多了,比如公司分管领导,业务支撑中心主任,力量大厦,和教育,亲情网,诸如此类,这些专有名词都具有明显的领域特点,基础大模型无法理解。
理论上,我们做领域大模型,第一步是选择一个基础大模型,然后基于行业术语做一个行业大模型,然后在行业大模型的基础上再去做领域大模型,但现在我们往往是从基础大模型一步跨域去做领域大模型,但没有行业大模型的基础,没有行业语料的积淀,领域大模型的效果很难让一线满意,因此需要画大量的时间去微调,而微调大多也是领域语料的问题。
例如,为了做ChatBI,我们要把公司数据分析领域的业务术语,指标口径都搜集一遍,整理好了,才有可能做出一个真正可用的ChatBI,但这种基础性工作,现在是没人做的,或者没有人体系化的去做。
因此,大多情况下,一个资源有限的大模型项目团队很难做出产品级的ChatBI,退而求其次,它只能去做一个及其细分的数据分析场景,把这个细分场景的语料尽可能搜集清楚,让大模型重新理解特定场景语境,从而做出正确的推理,即TXT2SQL,这也是无奈之举。
因此,大模型语料作为基础的生产资料,需要引起公司的高度重视,现在公司已经有所动作,我觉得是非常正确的方向,但关于语料集的构建,有三点建议:
一要明确业务目标,无论是公开的,还是领域内的,至少要明确具体支撑哪类AI应用,跟哪个AI团队合作,否则容易做空,效果难以衡量。
二要加强非结构化数据的技术研究和数据治理,语料这这种非结构化数据的处理解析,大多传统企业缺乏人才和技术储备,也缺乏实际处理经验。比如大模型中的RAG,最关键的是语料的向量化处理,涉及语料数据如何高效分词、检索结果优先级排序、向量数据库的自动化更新等等技术,这些对我们都是挑战。
三是语料数据的处理和解析是苦活累活,工作量很大,前期很难看得到成绩,需要资源的保障和一定的激励。
3、第三个建议,现在企业大模型人才什么都缺,但最缺的是AI产品经理,其次是语料工程师。
AI人才规划是个系统性问题,涉及各类岗位,如AI架构师、AI项目经理、AI产品经理、算法工程师、数据科学家、数据工程师、平台工程师等。但企业内搞AI,不是为了研究,更不是为了发论文,目标就是为了做出有价值的、能有人买单的产品。
个人认为,公司当前最缺的是AI产品经理。一个公司的最重要的产品经理可能就是各位领导和管理者。
我自己做大模型的感觉就是,很多大模型问题不是靠单一的算法维度能暴力解决的(一方面开源大模型能力还不够,另一方面企业也没足够的资源)。例如,一线人员可能会提出模棱两可的问题,大模型再厉害也理解不了,但这类问题其实可以转化成产品设计的问题,然后巧妙的解决。在这个过程中,好的产品经理是关键。例如,我们在产品设计上,可以通过增加多轮问答和结构化确认过程来确保一线问题的完整性。
同时因为AI产品涉及的要素特别多,除了算法、算力及数据,还包括需求、场景、架构、UI/UE等等。企业内一定要有人能把这些资源协同起来,盘活起来,但难点就在于这些资源在公司内还是按条线配置的。例如,CRM这边有产品经理,但数据工程师则大多在大数据团队。因此大模型也是需要治理的,组织保障是重中之重,需要让各个团队协同起来,发挥各自所长。
还有一点就是我们以前的数据工程师都是跟着数据仓库成长起来的,擅长于做结构化数据的ETL和数据处理,但对于语料这种非结构化数据,明显缺乏技术储备和处理经验。
我记得在做错别字纠正的时候,语料数据的准备就花了3个月,代价非常大。还有一次在做语料数据准备的时候,去隐私化太多,导致微调的效果非常差,这都是我们缺乏积累和经验造成的。
后来我去研究了下,发现语料数据的处理其实是一个庞大的技术体系,至少包括公司语料数据的归集(含人财物等)、数据清洗(含去除重复文本、处理文本编码、拼写纠正等)、数据预处理(含分词、词形还原、词干提取、文本标准化等)、数据增强(同义词替换、随机插入、回译、噪声注入、数据扩充、生成对抗数据等)、数据标注(词性标注、命名实体识别、意图识别、主题标注等)及数据准备(语料分割、语料编码、语料补齐及语料存储等),当然还有针对大模型的提示词工程,这些全是朴实无华但对大模型至关重要的基础工作。
在新的时期,公司需要培养新一代的数据工程师,大数据处理团队需要与时俱进,正如当年的数据仓库建模一样,语料数据的处理将成为数据工程师的核心竞争力。
很多领导和同事都提到要加强人才引入和培养,我认为这很重要,但远水解不了近渴,我们需要在现有条件下去创造最有可能的实施条件,例如进行工作内容的结构性调整,当然这考验管理者的智慧。
AI产品经理和语料工程师,由于对业务、数据的理解要求较高,一般还是需要公司自己培养。但数据科学家、算法工程师等岗位,由于技能的通用性,可以采取外部人才引入的方式解决。
同时希望公司有个AI专家的共享复用机制,因为现在公司各个实施团队都在进行大模型应用的探索,碰到了大量的算法调优问题,比如幻象和RAG,现在只能靠本地找资源解决,效率很低。我们需要有一种集中化AI专家的市场化征调机制,就像合作伙伴做的那样。当然这可能涉及到市场结算啥的,但真能解决问题的专家,相信大家都愿意付钱。
就讲这三点,谢谢大家!
我在一线互联网企业工作十余年里,指导过不少同行后辈。帮助很多人得到了学习和成长。
作为一名热心肠的互联网老兵,我意识到有很多经验和知识值得分享给大家,也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑,所以在工作繁忙的情况下还是坚持各种整理和分享。
但苦于知识传播途径有限,很多互联网行业朋友无法获得正确的资料得到学习提升,故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
所有资料 ⚡️ ,朋友们如果有需要全套 《LLM大模型入门+进阶学习资源包》,扫码获取~
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。