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

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

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

根据客户查询的分类，可以为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的服务了。

背景

通常默认公有云上的ECS远程连接，很容易断开，当你有什么事情被打断或者去操作别的机器同步做点其他事情，你会发现你SSH客户端登录窗口经常会断开掉，非常烦人，经常要重新登录。
如果用一些Windows下客户端软件比如XShell or CRT都会有超时时间和心跳检测次数设置，但是默认Mac下的终端 Or Linux下直接远程命令客户端是没有这个设置窗口的。
SSH Client会从以下途径获取配置参数:

1. SSH命令行参数；
2. 用户配置文件 (~/.ssh/config);
3. 系统配置文件 (/etc/ssh/ssh_config)。

方法1

1

ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=30 [email protected] -p22

方法2

1
2
3
4

$ vim ~/.ssh/config #添加如下内容
Host *
 ServerAliveInterval 60
 ServerAliveCountMax 30

方法3

1
2
3
4
5
6

$ vim /etc/ssh/ssh_config # 在Host *下面添加：

Host *
       SendEnv LANG LC_*
       ServerAliveInterval 60
       ServerAliveCountMax 30

如果三个都设置了，读取顺序是 方法1 —> 方法2 —> 方法3

比特币：一个点对点的电子货币系统

11 结论

11 Conclusion
We have proposed a system for electronic transactions without relying on trust. We started with the usual framework of coins made from digital signatures, which provides strong control of ownership, but is incomplete without a way to prevent double-spending. To solve this, we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power. The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.

我们已经提出了一种不依赖信任的电子交易系统。我们从通用的数字签名货币体系开始，这体系提供了强有力的所有权控制，但由于缺乏防止双重支付的方法而不完善。为解决这个问题，我们提出一种使用工作量证明来记录公共交易历史的点对点网络，只要诚实节点控制了多数的 CPU 算力，对于攻击者，交易历史将很快变得在计算上不可更改。网络因其结构简洁性而强大。节点只需很少的协调就能同时工作。它们不需要被认证，因为信息不会被发送到某个特殊的位置，只需被尽力传播。节点可以随时离开和重新加入网络，只需接受工作量证明链作为它们离开时发生事件的证据。节点使用 CPU 算力来投票，通过致力于延长有效区块来表达对其接受，通过拒绝在无效区块上工作来表达对其抵制。任何需要的规则和激励都可通过这个共识机制来加强。

【关注点】：

• rules and incentives, 都会有哪些规则和激励？

比特币：一个点对点的电子货币系统

11 计算

We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain. Even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air or taking money that never belonged to the attacker. Nodes are not going to accept an invalid transaction as payment, and honest nodes will never accept a block containing them. An attacker can only try to change one of his own transactions to take back money he recently spent.
The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk. The success event is the honest chain being extended by one block, increasing its lead by +1, and the failure event is the attacker’s chain being extended by one block, reducing the gap by -1. The probability of an attacker catching up from a given deficit is analogous to a Gambler’s Ruin problem. Suppose a gambler with unlimited credit starts at a deficit and plays potentially an infinite number of trials to try to reach breakeven. We can calculate the probability he ever reaches breakeven, or that an attacker ever catches up with the honest chain, as follows [8]:
p = probability an honest node finds the next block
q = probability the attacker finds the next block
qz = probability the attacker will ever catch up from z blocks behind

npm run serve basically is just saying “npm please run the command I defined under the name serve in package.json” the same happens with npm run dev.

Given this the commands can do the exact same thing, similar things, or very different things. Usually they are a shorthand for running a dev server on localhost, but it’s not a rule, only a convention.

So you’ll need to check in your package.json file and look for

1
2
3
4

"scripts": {
    "serve": "[list of commands here]",
    "dev": "[list of commands here]"
},