技术不是万能的，但没有技术却可能是万万不能的，对于大模型可能也是如此。基于大模型的应用设计需要聚焦于所解决的问题，在自然语言处理领域，大模型本身在一定程度上只是将各种NLP任务统一成了sequence 到 sequence 的模型。利用大模型， 我们是在解决具体的生产和生活中的问题，产品和技术上的设计仍然不可或缺。
那么，如果大模型正在重新构建软件工程的未来，我们是否应该遵循一些基本原则呢？
如果模型能够完成任务，就没必要写代码；模型会不断进化，但代码却不会
在当今时代，模型的价值越来越凸显。与传统的编程方法不同，现在的开发思路更倾向于"模型优先"。这意味着，当我们面临一个问题或任务时，我们首先要考虑是否可以利用现有的模型来解决它，而不是立即着手编写代码。因为代码是固定的，而模型具有巨大的发展空间。随着时间的推移，模型具有强大的学习和适应能力，能够通过不断迭代自我优化和进步。因此，我们的首要任务是挖掘模型的潜力，让它成为我们解决问题的利器
整个系统的目标是利用LLM的规划和理解意图的能力，以构建高效的项目。在这个过程中，我们可能会受到诱惑，想要回到那种命令式的思维模式，为程序的每个细节编写代码。但是，我们必须抵制这种诱惑，在一定程度上，现在可以让模型可靠地做一些事情，随着模型的发展，它会变得更好、更健壮
利用权衡杠杆换取精准，使用交互来缓解模糊。使用LLM进行编码时的正确心态不是“让我们看看我们能让跳舞的熊做什么”，而是从系统中获得尽可能多的杠杆作用。例如，可以构建非常通用的模式，如“从数据库构建报告”或“教授一年的科目”，这些模式可以通过纯文本提示进行参数化，从而轻松产生非常有价值和差异化的结果。
在保持高准确度的追求中，我们需要权衡其与其他因素之间的关系。为了达到这种平衡，我们可以采用交互的方式，以消除可能出现的歧义和误解。这一策略不仅提高了准确性，还增加了操作的灵活性和效率
在使用LLM进行编码的过程中，关键的心态应该是思考如何从系统中获得最大的杠杆效应，而不是“试试看能做什么”。这意味着，我们不应该仅仅满足于简单的功能实现，而是要深入挖掘系统的潜力，让其为我们创造更大的价值
实际应用中，我们可以构建一些通用的模式。比如，“从数据库生成报告”这样的模式，它具有很强的适应性，可以通过简单的文本提示进行参数调整，从而应对各种需求。再例如，“教一年的深度学习课程”这样的模式，它整合了丰富的教育资源，同样可以通过交互方式轻松调整，满足个性化的教学需求。
通过这些通用模式的应用，不仅提高了工作效率，还能轻松产生有价值、与众不同的结果。这种权衡精准性与交互消歧的策略，无疑是基于大模型应用设计中的重要思维方式。
在现代编程领域，代码和模型之间的分工变得越来越明确。简单来说，代码主要负责实现语法和过程，而模型则专注于生成和解读语义和意图。在实际应用中，这种分工有多种表达方式，但核心思想是一致的：代码用于执行特定指令和流程，而模型用于推理、生成和理解语言的深层含义和目标
从根本上说，模型在推理语言的意义和目标时表现出色，相形之下，当它们被要求执行特定的计算和过程时，往往表现得不如代码。例如，一个高级模型可能很容易为求解数独编写代码，但如果让它自己亲自去解数独，可能就会变得相对困难。
每个代码都有其独特的优势，关键是选择最适合特定问题的工具。语法和语义之间的界限，正是大型模型应用设计面临的主要挑战。在这种背景下，我们需要更深入地了解代码和模型各自的优缺点，以便更有效地利用它们来解决问题
在构建任何系统时，一个不可忽视的事实是，系统的整体强度往往由其最脆弱的部分决定。这一观点不仅适用于传统的软件系统，对基于大模型的应用同样适用
在追求系统的灵活性和高效性时，应该尽量避免硬编码的方式。硬编码指的是直接在代码中写入特定的数值或逻辑，而不考虑未来可能的变化或扩展。虽然这种做法可能在短期内带来方便，但从长远来看，会导致代码僵化，难以维护。因此，我们应该在编写代码和算法时注重推理和灵活性的加入
当设计提示语和交互时，应该尽量让其包含足够的信息和逻辑，以便系统能够自主地进行决策和推理，而不是简单地执行预定义的命令。通过这种方式，不仅可以减少硬编码的使用，还能更好地利用LLM的能力，让系统更加智能、更加灵活。
大型模型确实展现出了非凡的能力，就像“受过良好教育的”个体一样，但在实际应用中，它们仍然缺乏一些背景和主动性
简单来说，如果你向这些模型提出一个简单或开放式的问题，它们会给你一个简单或通用的答案。这种答案可能缺乏深度或细节，无法满足所有需求。如果希望得到更为详尽和深入的答案，那么提问的方式和策略就需要更为明智。
这其实是“Garbage in，Garbage out”原则在人工智能时代的一种体现。无论技术有多么先进，输入的数据质量仍然至关重要。如果输入的数据是模糊、不准确或不完整的，那么模型输出的答案也可能同样如此。
为了确保LLM模型能够给出高质量、有深度的答案，需要确保输入的数据准确、详尽且上下文丰富。这也意味着数据质量仍然是最重要的。只有重视并确保数据的质量，才能期望从这些先进的模型中获得真正有价值、有深度的信息
每当模型遇到不确定的情况，我们不能简单地忽略它或给出一个模糊的答案。相反，我们应该依赖于与用户的互动意图来澄清这种不确定性。
在程序设计中，当一组嵌套的提示中存在不确定性时——比如一个提示的结果可能有多种解读，我们应采取一种类似于“异常抛出”的策略。这意味着，应该将这种不确定性传递到堆栈中的更高级别，直到到达一个可以与用户交互或澄清不确定性的层级。
通过这样的设计策略，程序可以在面对不确定性时做出适当的响应，从而提供更准确和可靠的结果
文本已经成为一种普遍的协议，这主要归功于LLM在解析自然语言、意图和语义方面的出色能力。因此，文本成为了在提示语、模块和基于LLM的服务之间传递指令的首选格式
尽管自然语言在某些应用场景下可能略显不精确，但相较于其他结构化语言（如XML），其优点在于简洁、直观且易于人类理解。当然，对于那些需要高度精确和结构化的任务，仍然可以少量地采用结构化语言进行辅助。但多数场景下，自然语言在传递指令和意图方面表现得相当出色。
值得一提的是，随着这些基于LLM的技术的普及和进步，文本作为一种“未来证明”的自然交互方式，将进一步促进不同系统、不同提示之间的互通与理解。如果两个完全不同的LLM服务都能够理解和响应相同的文本指令，那么它们之间的协作和交互将变得如同人类之间的沟通一样自然、流畅
将内容进行改写的目的是为了不改变原始意思，而将语言改写为中文
当面对一个复杂问题时，不仅对人来说是一个挑战，对大模型而言也同样如此。在实际应用中，如果我们直接将复杂问题的提示语作为程序的一部分，可能会遇到问题，因为我们真正需要的只是推理的结果
为了解决这个问题，一种有效的方法是使用“元”提示。这种提示不仅可以给出问题，还能提供详细的答案，然后要求模型从中提取关键信息。这种方法的效果会很好，因为它实际上是将一个复杂的认知任务转化为了一个相对简单的任务。想象一下，如果给一个人一个“阅读这篇文章并找出答案”的任务，即使该用户没有相关领域的专业知识，他也很有可能完成这个任务，因为自然语言的力量是巨大的。
在设计基于大模型的应用时，有一些需要注意的事项。普通人觉得困难的事情，在模型中也可能同样困难。面对这种情况，最好的策略是将复杂的问题或任务分解成更简单的步骤。这样可以降低处理的难度，同时提高答案的稳定性和准确性
模型不仅是一种工具，它也可以成为我们对抗自身错误的利器。很多时候，我们容易将LLM（大语言模型）的运作想象成一个“头脑”的内部过程。然而，必须认识到，尽管模型与人类思维在某些方面有相似之处，但二者之间仍存在许多有意义的差异。
这其中有一个特点尤为重要：模型在短时间的交互中往往缺乏持久记忆。这意味着，模型在从一分钟到下一分钟的交互中，不太可能记住所有的细节。这一特点为我们提供了某种控制的可能性。
这种控制不仅局限于代码审查。实际上，模型还可以充当代码的安全监视器，确保代码的安全运行；它还可以作为测试策略的一个组成部分，帮助我们制定更有效的测试方案；甚至可以充当内容过滤器，协助我们生成高质量的内容
因此，只要我们对模型进行适当的控制和引导，它就能成为我们工作中得力的“助手”。而这种控制的基础，就是我们对模型内部机制和特点的深入了解和掌握。
大语言模型的能力确实令人惊叹，它们可以处理和解析大量的文本数据，生成有逻辑和连贯性的文本，甚至在某些任务上超越了人类的表现。然而，这并不意味着我们应该盲目崇拜这些大模型，认为它们无所不能。
大型模型实际上仍然存在许多限制和局限。尽管它们能够处理大量的文本数据，但它们并不能像人类一样真正理解语言和语境的微妙差异。此外，它们的表现也受训练数据和算法选择的限制，可能会出现一些偏见和错误
因此，我们在使用大模型时，应该保持理性和谨慎的态度，既要欣赏它们所带来的便利和进步，也要警惕它们的局限性和潜在风险。这样，才能更好地利用这些模型，推动基于大模型应用的健康发展。
以上是大模型应用设计的十个思考的详细内容。更多信息请关注PHP中文网其他相关文章！
