节前，我们组织了一场算法岗技术&面试讨论会，邀请了一些互联网大厂朋友、今年参加社招和校招面试的同学。
针对大模型技术趋势、算法项目落地经验分享、新手如何入门算法岗、该如何准备面试攻略、面试常考点等热门话题进行了深入的讨论。
总结链接如下：
喜欢本文记得收藏、关注、点赞。更多实战和面试交流，也欢迎与我们交流
最近一周在公司总部参加大模型培训，之后总部组织了参培人员的交流发言，让大家谈谈大模型产品在省侧落地应用和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,数据,模型,ChatBI,语料,我们 From： https://blog.csdn.net/m0_59596990/article/details/139969997