为什么要内网穿透

内网穿透，也即 NAT 穿透，进行 NAT 穿透是为了使具有某一个特定源 IP 地址和源端口号的数据包不被 NAT 设备屏蔽而正确路由到内网主机。 说人话就是我们想在不连接家里的wifi的情况下访问我们家里面的电脑和其他设备时，由于家庭宽带没有固定的公网ip使得我们无法向访问云服务器一样 直接访问，这时候我们就需要使用到内网穿透技术，让我们在其他网络下也能访问到处于内网环境的设备。而内网穿透的工具也有很多如： - 花生壳 - nat123 - ngrok - frp，本文主要讲FRP的搭建和使用，这个方案基本免费，仅需要一个有公网IP的服务器。我用的是腾讯云的服务器。

什么是FRP

Frp (Fast Reverse Proxy) 是比较流行的一款。FRP 是一个免费开源的用于内网穿透的反向代理应用，它支持 TCP、UDP 协议， 也为 http 和 https 协议提供了额外的支持。你可以粗略理解它是一个中转站， 帮你实现 公网 ←→ FRP(服务器) ←→ 内网 的连接，让内网里的设备也可以被公网访问到。仓库地址

安装FRP

有时很难确定一个改变（例如，新的指示或新的设计）是使系统变得更好还是更糟。通过查看一些示例可能可以暗示哪个更好，但是对于小样本量来说，很难区分是真正的改进还是随机运气。也许这个改变对某些输入的性能有所帮助，但对其他输入的性能有所损害。
评估程序（或“评估”）对于优化系统设计是有用的。好的评估具备以下特点：

• 代表真实世界的使用情况（或至少具备多样性）
• 包含许多测试案例以获得更大的统计能力（请参考下表以获取指导方针）
• 易于自动化或重复执行

输出的评估可以由计算机、人类或二者结合来进行。计算机可以通过客观标准（例如，具有单一正确答案的问题）自动化评估，也可以通过一些主观或模糊标准进行评估，其中模型的输出由其他模型查询来评估。OpenAI Evals是一个开源软件框架，提供了创建自动评估的工具。
基于模型的评估在存在一系列可能的输出，且这些输出在质量上被认为是相等的情况下（例如，对于需要长答案的问题）是有用的。基于模型的评估与需要人类进行评估的情况之间的界限是模糊的，并且随着模型能力的提升，这个界限不断变化。我们鼓励进行实验，以确定基于模型的评估在您的用例中的效果如何。

通过与黄金标准答案对比评估模型输出结果

假设我们已知问题的正确答案应该涉及到一组特定的已知事实。然后我们可以使用模型查询来计算答案中包含的必要事实的数量。

例如，使用以下系统消息：

使用基于嵌入的搜索实现高效的知识检索

有时候，当我们明确指示模型在得出结论之前从基本原理进行推理时，我们可以获得更好的结果。例如，假设我们希望模型评估学生对一个数学问题的解答。最直接的方法是简单地问模型学生的解答是否正确

如果提供外部信息作为模型输入的一部分，模型可以利用这些信息。这可以帮助模型生成更具见解和最新的回答。例如，如果用户问一个关于特定电影的问题，将关于电影的高质量信息（如演员、导演等）添加到模型的输入中可能会很有用。可以使用嵌入（embeddings）来实现高效的知识检索，以便在运行时动态地将相关信息添加到模型输入中。

文本嵌入是可以衡量文本字符串之间关联性的向量。相似或相关的字符串之间的距离比不相关的字符串更近。这一事实，加上存在快速向量搜索算法，意味着可以利用嵌入来实现高效的知识检索。具体而言，可以将文本语料库分割成多个块，然后对每个块进行嵌入和存储。然后，可以对给定的查询进行嵌入，执行向量搜索以找到与查询最相关的文本块（即在嵌入空间中最接近的文本块）。

在OpenAI Cookbook中可以找到示例实现。参考“指示模型使用检索到的知识来回答查询”策略，了解如何使用知识检索来最大程度地减少模型捏造不正确事实的可能性的示例。

使用代码执行进行更准确的计算或调用外部API

GPT模型本身不能可靠地执行算术或长时间计算。在需要进行这类计算的情况下，可以指示模型编写和运行代码，而不是进行自己的计算。特别是，可以指示模型将需要运行的代码放入指定的格式，例如三个反引号（triple backtics）。在生成输出后，可以提取并运行代码。最后，如果需要的话，可以将代码执行引擎（例如Python解释器）的输出作为下一个查询的模型输入。

另一个代码执行的良好用例是调用外部API。如果向模型传授API的正确使用方法，它可以编写使用该API的代码。通过向模型提供API的文档和/或代码示例，可以告诉它如何使用该API。

指示模型在草率得出结论之前自己解决问题

有时候，当我们明确指示模型在得出结论之前从基本原理进行推理时，我们可以获得更好的结果。例如，假设我们希望模型评估学生对一个数学问题的解答。最直接的方法是简单地问模型学生的解答是否正确

但学生的解答实际上是不正确的！我们可以通过提示模型首先生成自己的解答来成功让模型注意到这一点。

使用意图分类来识别用户查询的最相关指令

对于需要处理不同情况的大量独立指令的任务，首先对查询类型进行分类，并使用该分类确定所需的指令，可以带来一些好处。这可以通过定义固定的类别和硬编码与处理给定类别任务相关的指令来实现。该过程还可以递归应用于将任务分解为一系列阶段。这种方法的优点在于每个查询只包含执行任务的下一个阶段所需的指令，这可能导致与使用单个查询执行整个任务相比较低的错误率。这还可以降低成本，因为较大的提示运行成本更高（请参阅定价信息）。

例如，假设对于客户服务应用程序，查询可以有以下有用的分类方式：

根据客户查询的分类，可以为GPT模型提供一组更具体的指令来处理下一步操作。例如，假设客户需要“故障排除”的帮助。

指示模型使用参考文本回答问题

如果我们能够向模型提供与当前查询相关且可信的信息，那么我们可以指示模型使用提供的信息来组织回答。

考虑到GPT模型的上下文窗口有限，为了应用这个策略，我们需要一种动态查找与所提问题相关的信息的方法。嵌入可以用来实现高效的知识检索。有关如何实施这一策略的详细信息，请参阅“使用基于嵌入的搜索来实现高效的知识检索”策略。

指示模型使用参考文本中的引用进行回答

如果输入已经补充了相关知识，可以要求模型通过引用提供的文献中的段落来添加引用。请注意，可以通过在提供的文献中进行字符串匹配来对输出中的引文进行程序验证。

在查询中包含详细信息以获得更相关的答案

（Include details in your query to get more relevant answers****）****

为了获得高度相关的回答，请确保请求提供任何重要的细节或背景信息。否则，你就让模型去猜你的意思了。

要求模型采用特定的人设

（Ask the model to adopt a persona）
系统消息可以用来指定模型在回复中所使用的人设。

背景

GPT官方推出了一个使用方法介绍：网址，挺有意思，搬运过来，并做一些归纳。
有6种方法可以得到更好的结果：

一、写出明确的指引（Clear Instructions）

GPT无法读取您的思维。如果它们的输出太长，请要求简洁回答。如果它们的输出过于简单，请要求专家级的写作。如果您不喜欢格式，请展示您想要看到的格式。GPT越少猜测您的需求，您得到的结果就更有可能符合您的期望。

策略：

• 在查询中包含详细信息以获得更相关的答案
• 要求模型采用特定的人设
• 使用分隔符清楚地标示输入的不同部分
• 明确指定完成任务所需的步骤
• 提供示例
• 指定期望的输出长度

背景

练习Django的时候发现它的类视图很神奇，很少的代码就能实现功能，研究了一下，发现这个教程，写得比较详细，转载一下，加深印象。

类视图与函数视图

Django的视图可以分为：

• 函数视图FBV：def index(request):
• 类视图CBV：class AboutView(TemplateView):

早期，人们在视图开发中发现了一些常见的习语和句式，也就是重复性代码和工作。于是引入了基于函数的视图来抽象这些模式，便于一般情况下的视图开发。

基于函数的视图的问题在于，尽管它们覆盖了简单的情况，但是除了一些简单的配置选项之外，没有办法扩展或定制它们，限制了它们在许多现实应用中的实用性。

基于类的通用视图与基于函数的视图的目标相同，都是想让视图开发更容易。但由于类视图可以使用MIXIN等一些面向对象的方法和工具包，使得基于类的视图比基于函数的视图更具扩展性和灵活性。

基于类的视图：

• 通过HTTP请求方法的不同，将代码分隔在不同的类方法中，比如GET和POST，而不是类函数中的条件判断。
• 可以使用面向对象的技巧，比如混入。
• 类具有封装和继承的特性，方便代码复用、分发和重构。

两种视图可以实现同样的功能，本质上是一个东西，没有谁好谁坏之分，只是适用场景不同而已：

• 简单逻辑、快速处理，请用FBV
• 代码复用、功能封装，请用CBV

用法

Django 提供了很多适用于各种应用场景的基本视图类，我们一般不从头自己写起，这些类视图都继承django.views.generic.base.View类。比如RedirectView 用于 HTTP 重定向，TemplateView 用于渲染模板。

类视图有很多简单的用法，甚至不需要去views.py中编写代码，比如下面的例子：

1
2
3
4
5
6

from django.urls import path
from django.views.generic import TemplateView

urlpatterns = [
    path('about/', TemplateView.as_view(template_name="about.html")),
]

重点关注：

• TemplateView类视图
• as_view()方法
• template_name参数

更通用的使用方法是继承Django提供的各种视图类，所以上面的例子的一般性写法如下：

1
2
3
4
5

# some_app/views.py
from django.views.generic import TemplateView

class AboutView(TemplateView):
    template_name = "about.html"

但是，由于类不是函数，所以需要在URLconf中使用as_view()这个类方法将一个基于类的视图转换成函数形式的接口。

1
2
3
4
5
6
7

# urls.py
from django.urls import path
from some_app.views import AboutView

urlpatterns = [
    path('about/', AboutView.as_view()),
]

背景

我在运上搭建了Django的服务器环境，这样就不能用 http://127.0.0.1:8000 来访问Django的服务了，那如何解决呢？

解决方案

在启动服务的时候，加一些参数：

1

python3 [manage.py](http://manage.py/) runserver 0.0.0.0:8000

同时，修改 setting.py，将远端的服务器ip加到ALLOWED_HOSTS参数里：

1

ALLOWED_HOSTS = ['xxx.xxx.xxx.xxx']

注：其中’xxx.xxx.xxx.xxx’是你远程服务器的外网ip

这样，就可以用 http://xxx.xxx.xxx.xxx:8000 访问Django的服务了。