在人工智能领域，继提示工程和“氛围编码”之后，一个新的概念——上下文工程——正逐渐崭露头角。它并非关于让大模型（LLM）“思考”，而是关于如何更有效地利用它们处理信息的能力。本文将深入探讨上下文工程的核心概念，并结合一个蓝领招聘平台的案例，阐述它如何重塑搜索用户体验，提升效率和用户满意度。尤其是在大模型技术日新月异的今天，理解并应用上下文工程对于构建更智能、更人性化的应用程序至关重要。
上下文工程：核心概念与重要性
上下文工程的核心在于精确地定义进入大模型上下文窗口的内容、顺序和结构。我们可以将大模型想象成一台CPU，它无法读取整个硬盘的数据，只能处理内存（RAM）中的信息。同理，大模型也只能处理你输入到上下文窗口中的信息。如果框架不当或关键信息缺失，即使模型再“智能”，输出结果也毫无价值。简单来说，上下文工程就是一种精心设计提示（Prompt）的过程，旨在让大模型能够更好地理解用户的意图，并给出更准确、更有用的回答。
在传统的搜索引擎中，用户需要通过猜测关键词、选择下拉菜单和应用筛选器才能找到所需信息。对于不熟悉技术或者目标不明确的用户来说，这无疑是一种繁琐且低效的体验。而上下文工程的出现，为解决这一问题提供了新的思路。通过精心构建输入到大模型的上下文信息，我们可以让用户以自然语言表达需求，并直接获得所需的结果，无需进行复杂的筛选和调整。
蓝领招聘平台案例：自然语言搜索的实践
一个为蓝领工人打造的招聘平台就是一个极佳的例子。传统求职模式对于蓝领工人来说并不友好，他们常常面临目标不明确、语言表达非正式以及工作环境嘈杂等问题。与其让他们在复杂的界面中摸索，不如直接让他们用自然语言描述需求，例如“寻找在Whitefield附近，薪资高于15k的夜班工作”。
该平台采用了一种简洁明了的技术栈：用户使用自然语言输入查询语句，前端（React）将查询发送到后端（FastAPI），后端再将查询传递给大模型。大模型负责提取用户的意图、关键词和约束条件，并构建一个结构化的搜索查询。这个结构化的查询随后被发送到Typesense，利用模糊匹配和相关性评分在职位数据库中进行搜索。Typesense返回最接近的匹配结果——真实的职位信息，而非泛泛的建议。最后，大模型审查搜索结果，突出显示最佳匹配项，分析其优缺点，并添加诸如薪资范围或市场洞察等上下文信息。前端将最终结果渲染为职位卡片，包含职位名称、公司、薪资、地点、班次和职位描述等信息。
从用户的角度来看，整个过程就像魔法一样：只需输入需求，就能获得切合实际的结果。这其中没有复杂的筛选器、猜测和下拉菜单，只有清晰的上下文输入和准确的答案输出。这种用户体验的提升，得益于上下文工程的巧妙应用。
后端数据处理：构建干净的上下文基础
要实现精准的搜索结果，后端数据处理至关重要。原始的职位数据往往是杂乱无章的，以CSV格式存储，格式各异，字段缺失，薪资格式不一致，字符串混乱。因此，数据清洗是必不可少的一步。
首先，需要去除空格，标准化薪资格式（例如，将“每月15k”或“1.8LPA”转换为一致的月薪数字），并处理缺失数据，可以选择智能填充或删除不可用的行。清洗后的数据会被转换成符合Typesense模式的JSON对象，包含职位名称、公司、薪资、地点、班次和职位描述等字段。然后，将清洗后的记录分批（每批100条）导入Typesense，使用upsert操作更新现有条目并添加新条目。
Typesense负责繁重的工作：它为全文搜索建立索引，处理模糊匹配、拼写容错和基于字段的过滤。这些功能都由Typesense自动处理，无需手动管理，这归功于对Typesense模式的精心定义。最终结果是一个干净、可实时搜索的集合，为大模型提供精准、结构化的数据，从而更好地理解用户意图。
上下文窗口的设计与优化：提升模型性能
上下文窗口的大小是影响大模型性能的关键因素之一。更大的上下文窗口意味着可以输入更多的信息，从而让模型更好地理解用户的意图。然而，过大的上下文窗口也会增加计算成本和推理时间。因此，如何有效地利用有限的上下文窗口，成为上下文工程的重要课题。
一种常见的做法是采用检索增强生成（Retrieval Augmented Generation，RAG）。RAG技术可以将外部知识库的信息动态地添加到上下文窗口中，从而增强模型的知识储备。例如，在蓝领招聘平台的案例中，可以将用户的地理位置信息、技能信息以及历史求职记录等信息添加到上下文窗口中，从而让模型更好地理解用户的需求。
另一种做法是使用链式提示（Chain-of-Thought Prompting）。链式提示是指将一个复杂的问题分解为多个简单的子问题，并让模型逐步解决这些子问题。通过这种方式，可以引导模型进行更深入的思考，并给出更准确的答案。例如，在蓝领招聘平台的案例中，可以将用户的需求分解为“寻找地点”、“寻找薪资范围”、“寻找班次”等子问题，并让模型分别解决这些子问题，最终整合所有子问题的答案，生成最终的搜索结果。
案例分析：不同上下文工程策略的对比
假设用户搜索“离家近，工资高的焊工工作”，以下对比几种不同的上下文工程策略：
策略1：简单关键词提取
- 上下文：焊工，工资高，离家近
- 问题：模型难以理解“离家近”的具体含义，以及用户对“工资高”的具体期望。搜索结果可能不够精准。
策略2：加入用户画像的RAG
- 上下文：
- 焊工，工资高，离家近
- 用户画像：居住地：XX小区，期望工资：8000-12000
- 优势：模型可以根据用户居住地计算通勤距离，并结合用户的期望工资范围进行搜索，结果更精准。
- 不足：用户画像需要提前准备，且可能存在信息不完整或不准确的情况。
策略3：链式提示分解问题
- 上下文：
- 问题1：用户居住地在哪里？（回答：XX小区）
- 问题2：用户期望的最低工资是多少？（回答：8000）
- 问题3：用户想找什么类型的焊工工作？（回答：普通焊工）
- 优势：通过逐步提问，模型可以更准确地理解用户的意图，并排除歧义。
- 不足：需要进行多次交互，可能影响用户体验。
通过对比可以看出，不同的上下文工程策略各有优缺点，需要根据具体的应用场景进行选择和调整。
未来展望：上下文工程的持续演进
随着大模型技术的不断发展，上下文工程也将持续演进。未来的发展方向可能包括：
- 自适应上下文工程：根据用户的历史行为和偏好，自动调整上下文窗口的内容和结构，从而提供更个性化的服务。
- 多模态上下文工程：将文本、图像、音频等多种模态的信息融合到上下文窗口中，从而让模型更好地理解用户的意图。
- 基于知识图谱的上下文工程：利用知识图谱来增强模型的知识储备，从而提供更准确、更全面的答案。
例如，未来的蓝领招聘平台可以结合用户的语音输入和摄像头拍摄的简历照片，自动提取关键信息，并将其添加到上下文窗口中，从而让模型更好地理解用户的需求。此外，还可以利用知识图谱来识别用户的技能和经验，并推荐与其技能匹配的职位。
结论：拥抱上下文工程，重塑用户体验
上下文工程不仅仅是一种技术，更是一种设计理念，它强调以用户为中心，通过精心构建输入到大模型的上下文信息，从而提供更智能、更人性化的服务。在蓝领招聘平台的案例中，我们看到了上下文工程如何重塑搜索用户体验，让用户以自然语言表达需求，并直接获得所需的结果，无需进行复杂的筛选和调整。
随着大模型技术的不断发展，上下文工程将在各个领域发挥越来越重要的作用。拥抱上下文工程，深入理解其原理和应用，将有助于我们构建更智能、更高效、更友好的应用程序，最终提升用户满意度和业务价值。在未来的大模型时代，上下文工程将成为用户体验设计的关键驱动力，引领我们走向更加智能化的未来。