⚙️ 3. 让大模型能够回答私域知识问题

回到最初的挑战：
答疑机器人无法回答“我们公司项目管理用什么工具”这类内部问题。
根本原因在于，大模型的知识来源于其训练数据，这些数据通常是公开的互联网信息，不包含任何特定公司的内部文档、政策或流程。

你可以把大模型想象成一台刚出厂的超级计算机：
它的 CPU（推理能力）极其强大，硬盘（模型权重）里也预装了海量的通用知识。
但对于你公司的“内部资料”，它的硬盘里是空白的。

面对这个问题，最直观的解决思路就是：
在运行时，把公司的内部知识临时告诉它。

3.1 初步方案：在提示词中“喂”入知识

你可以来验证这个思路：将公司项目管理工具的说明文档，直接添加到给模型的指令（System Prompt）中，作为背景知识提供给它。

user_question = "我是软件一组的，请问项目管理应该用什么工具"

knowledge = """公司项目管理工具有两种选择：
  1. **Jira**：对于软件开发团队来说，Jira 是一个非常强大的工具，支持敏捷开发方法，如Scrum和Kanban。它提供了丰富的功能，包括问题跟踪、时间跟踪等。

  2. **Microsoft Project**：对于大型企业或复杂项目，Microsoft Project 提供了详细的计划制定、资源分配和成本控制等功能。它更适合那些需要严格控制项目时间和成本的场景。

  在一般情况下请使用Microsoft Project，公司购买了完整的许可证。软件研发一组、三组和四组正在使用Jira，计划于2026年之前逐步切换至Microsoft Project.
"""

response = get_qwen_stream_response(
  user_prompt=user_question,
  # 将公司项目管理工具相关的知识作为背景信息传入系统提示词
  system_prompt="你负责教育内容开发公司的答疑，你的名字叫公司小蜜，你要回答学员的问题。" + knowledge,
  temperature=0.7,
  top_p=0.8
)

for chunk in response:
  print(chunk, end="")

模型输出：

你好呀，我是公司小蜜～欢迎来咨询！

你是软件一组的小伙伴对吧？目前你们组还在使用 **Jira** 进行项目管理，这是当前阶段允许的，因为你们属于正在使用 Jira 的研发团队之一（软件研发一组、三组、四组）。

不过要悄悄告诉你一个小目标：**公司计划在2026年之前逐步从 Jira 切换到 Microsoft Project**。后续会根据安排推进工具统一，所以未来可能会开始过渡使用 Microsoft Project。

现阶段你继续用 Jira 没问题，但如果有新项目试点或培训通知，记得关注哦，我们会提前安排支持和培训，确保大家顺利切换～

如果现在就想了解 Microsoft Project 的基本操作，我也可以帮你找资料哟！😊

加油工作，小蜜随时在线～

实验成功了！
在提示词中加入相关的背景知识，大模型确实能够准确回答关于公司内部工具的问题。
这个发现令人振奋，似乎你已经找到了解决私域知识问答的钥匙。

然而，当你试图将更多的公司文档（例如几十页的员工手册、上百页的技术规范）都用这种方式“喂”给大模型时，一个新的、更严峻的挑战出现了。

3.2 核心瓶颈：有限的上下文窗口

大模型接收我们输入（包括指令、问题和背景知识）的地方，被称为上下文窗口（Context Window）。
你可以把它理解为计算机的“内存（RAM）”——它的容量是有限的。
你无法将整个公司的知识库（成百上千份文档）一次性塞进这个有限的窗口里。
一旦输入内容超过模型的最大限制，就会导致错误。
这引出了一个核心问题：你需要对放入上下文窗口的内容进行筛选和管理。

3.3 解决之道：上下文工程 (Context Engineering)

简单粗暴地将信息塞进上下文，除了会超出窗口限制外，还会带来一系列“隐性”问题：

1. 效率低：
   上下文越长，大模型处理所需的时间就越长，导致用户等待时间增加。
2. 成本高：
   大部分模型是按输入和输出的文本量计费的，冗长的上下文意味着更高的成本。
3. 信息干扰：
   如果上下文中包含了大量与当前问题无关的信息，就像在开卷考试时给了考生一本错误科目的教科书，反而会干扰模型的判断，导致回答质量下降。

你一定会意识到，成功的关键不在于“喂”给模型多少知识，而在于“喂”得有多准。

如何在正确的时间，将最相关、最精准的知识，动态地加载到大模型有限的上下文窗口中？
——这门系统性地设计、构建和优化上下文的实践，就是上下文工程（Context Engineering）。

从这个角度看，许多大模型应用的失败，并非模型本身不够智能，而是“上下文”的失败。
上下文工程正是释放大模型潜力的关键所在。

那么，上下文工程具体包含哪些技术呢？
你可以通过下面这张概念图来快速了解它的核心版图：

💡 上下文工程 (Context Engineering) 的核心技术
它是构建可靠、高效大模型应用的一系列关键技术的总和，主要包括：

• RAG (检索增强生成)：
  从外部知识库（如公司文档）中检索信息，为模型提供精准的回答依据。

• Prompt (提示词工程)：
  通过精心设计的指令，精确地引导模型的思考方式和输出格式。

• Tool (工具使用)：
  通过精心设计的指令，精确地引导模型的思考方式和输出格式。

• Memory (记忆机制)：
  通过精心设计的指令，精确地引导模型的思考方式和输出格式。

你可能已经注意到，这里出现了一些新名词。
别担心，你不需要立刻掌握所有细节。
这里展示这张图的目的是为了让你建立一个整体认知：
接下来要学习的几个知识，都是上下文工程的一部分。

为了让你更容易理解和吸收，在后续的课程中，这些概念将作为独立的主题，逐一详细拆解和实践。

现在，你需要聚焦于当前最紧迫的问题——如何解决私域知识问答。
在这个技术版图中，RAG 是最直接、最有效的解决方案。
接下来，你将深入学习它。