openai科技春晚
- GPT-4 Turbo模型登场,将上下文长度提升至128k,知识库更新到2023年4月!
- function call 提供线性调用
- 新增“seed” parameter,确保模型每次返回固定答案!
- 原生支持基于文档的知识“投喂”
- TTS中的所有音色都提供API
- 多模态,同一会话中集成dalle、Advanced Data Analysis、插件等
- GPT4支持微调,响应更快,费用更低
- 预示AI将能执行愈加复杂的任务,全民“技术平权”的时代到来
相信大家或多或少体验过大模型的魅力,有一定门槛的chatGPT(包含各种套壳的chat_bot),还有文心、通义千问等等。我总结有以下小缺陷
打个比方大模型是大脑,AI agent给了模型“双手”。常见的autoGPT、babyGPT、本文介绍来自微软的autogen (https://microsoft.github.io/autogen/)
代码执行
先看效果,“请求https://www.baidu.com 50次,2秒间隔,记录每次的状态码、网络延迟,结果记录下来。并且生成图片,保存到当前目录下”
近期在尝试大数据在企业内的应用,两个需求:
两种方向:向量库+大模型、模型微调。
以下给出openai模型微调的详细过程,目前官方推荐gpt-3.5-turbo,gpt4的微调将在年底推出
{"messages": [{"role": "system", "content": "Marv is a factual chatbot that is also sarcastic."}, {"role": "user", "content": "What's the capital of France?"}, {"role": "assistant", "content": "Paris, as if everyone doesn't know that already."}]}
{"messages": [{"role": "system", "content": "Marv is a factual chatbot that is also sarcastic."}, {"role": "user", "content": "Who wrote 'Romeo and Juliet'?"}, {"role": "assistant", "content": "Oh, just some guy named William Shakespeare. Ever heard of him?"}]}
{"messages": [{"role": "system", "content": "Marv is a factual chatbot that is also sarcastic."}, {"role": "user", "content": "How far is the Moon from Earth?"}, {"role": "assistant", "content": "Around 384,400 kilometers. Give or take a few, like that really matters."}]}
我的数据源是csv,第一列问题,第二列答案,用以下脚本处理
import pandas as pd
import json
def convert_csv_to_jsonl(input_csv, output_jsonl):
# Read the CSV file
df = pd.read_csv(input_csv)
with open(output_jsonl, 'w', encoding='utf-8') as f:
for _, row in df.iterrows():
jsonl_data = {
"messages": [
{"role": "system", "content": "SunSun is an internal knowledge base communication robot."},
{"role": "user", "content": row['Generated Questions']},
{"role": "assistant", "content": row['source']}
]
}
f.write(json.dumps(jsonl_data, ensure_ascii=False) + '\n')
# Usage
# convert_csv_to_jsonl('path_to_your_csv_file.csv', 'desired_output_file.jsonl')
if __name__ == "__main__":
convert_csv_to_jsonl('/Users/jixing/Downloads/export_result0925.csv',
'/Users/jixing/Downloads/export_result0925.jsonl')
import openai
# 替换你的key
openai.api_key = "sk-40LIdYxxxxxxx"
training_file = openai.File.create(
file=open("export_result0925.jsonl", "rb"),
purpose='fine-tune'
)
# 记录文件id,下一步需要使用
print(training_file.id)
import openai
# 你的key
openai.api_key = "sk-40LIdYIwxxxxx"
# 刚才的文件id
openai.FineTuningJob.create(training_file="file-0ACDKAM7xxxxxx", model="gpt-3.5-turbo")
最近在看大模型和运维行业的关联,初步想法是标记监控数据,配合混沌工程,给出故障数据进行多元线性回归,根据最佳曲线来预测故障。实际进行过程中发现困难重重,还在尝试标记数据。
最近有个很火的词儿叫“数字孪生”,又叫数字骨灰盒:),大意是通过大量的文字痕迹训练已有模型,让模型从“扮演”到“重塑”你。受启发于 https://greatdk.com/1908.html,并做了些许优化,效果还是挺好玩的,或许这才是数字世界的你?!😄
看疗效!
思路步骤:
优化项目:
python清洗脚本
import os
import re
import json
# 定义源文件夹和目标文件
source_folder = '/Users/jixing/Downloads/wechat_history'
output_file_path = '/Users/jixing/Downloads/0811output.txt'
# Regular expression patterns for extracting dates, usernames, and messages
date_pattern = re.compile(r"\((\d{4}-\d{2}-\d{2}) \d{2}:\d{2}:\d{2}\)")
user_msg_pattern = re.compile(r"^(.+?) \(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}\):(.+)$")
# 遍历文件夹中的所有.txt文件
for filename in os.listdir(source_folder):
if filename.endswith('.txt'):
with open(os.path.join(source_folder, filename), 'r', encoding='utf-8') as source_file:
content = source_file.readlines()
# Parsing the chat data
conversations = []
current_date = None
current_convo = []
for line in content:
# Check for date
date_match = date_pattern.search(line)
if date_match:
date = date_match.group(1)
if current_date != date and current_convo:
conversations.append(current_convo)
current_convo = []
current_date = date
# Extracting user and message
user_msg_match = user_msg_pattern.match(line)
if user_msg_match:
user, msg = user_msg_match.groups()
if current_convo and current_convo[-1][0] == user:
current_convo[-1][5] += f",{msg.strip()}"
else:
current_convo.append([user, msg.strip()])
# Adding the last conversation if any
if current_convo:
conversations.append(current_convo)
# Formatting conversations
adjusted_conversations = []
for convo in conversations:
history = []
for i in range(0, len(convo) - 1, 2): # Increment by 2 to ensure one question and one answer
prompt = convo[i][6]
response = convo[i + 1][7] if i + 1 < len(convo) else None
if response: # Only add to the list if there's a response
adjusted_conversations.append({
"prompt": prompt,
"response": response,
"history": history.copy()
})
history.append([prompt, response])
# Appending the results to output.txt, one object per line
with open(output_file_path, 'a', encoding='utf-8') as output_file:
for convo in adjusted_conversations:
json.dump(convo, output_file, ensure_ascii=False)
output_file.write('\n')
清洗后数据,可以看到已经有非常完整的逻辑关系了
我在训练时使用了70%的训练集,30%作为测试集。3000条数据在我的2080显卡需要10小时!都去试试看效果吧:)
OPA是一种开源通用策略引擎,可在整个堆栈中实现统一的、上下文感知的策略实施。该项目于2018年4月被CNCF沙箱接受,2021年2月4日正式毕业于CNCF。来自大约 30 个组织的 90 多人为 OPA 做出了贡献,维护者来自包括 Google、Microsoft、VMware 和 Styra。
简单来说,是在服务上抽象一层,统一控制、审计,本文讨论仅限在Kubernetes中的gatekeeper,对容器创建进行安全约束,确保符合运维规范。
上次的数据库故障余波未平。老服务整改周期内仍有可能增高,有没什么方法限制单个pod只能建立一定数量的数据库连接,把事故控制在一定范围内
陷入僵局,最笨用iptables限制,但还能实时发现pod的重启更换IP,难道要复杂化,监控结合脚本的方式吗?忽然灵光一闪,initContainers阶段不是可以做很多事情嘛
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
initContainers:
- name: init-iptables
image: my-iptables-image
command: ['sh', '-c', 'iptables -A OUTPUT -p tcp --dport 3306 -m connlimit --connlimit-above 20 -j REJECT']
containers:
- name: my-container
image: my-image
😅未验证,原理可行- -
某日读写分离中间件报警,有大量非业务IP连接涌入,新连接无法建立。查询数据库连接有大量的”unauthenticated user 1.2.3.4:37414 NULL Connect NULL Reading from net NULL”。一时间大量用户报障,“登录失效”、“设备断连”、“影响产线生产”等等
解决过程倒不复杂,跳过中间件恢复。售后工程师承认是中间件设计问题,释放连接逻辑bug,也提到了有大量连接时可能触发!
反观自身,架构设计阶段把过多的压力放在主库,19年上线的读写分离中间件就是“业务迭代优先,没时间基础设施改造”、“历史包袱”背景下的缓兵之计。阿里云的问题有几点
1.中间件控制台无法显示真实IP,故障后对方研发回复“日志因升级规格消失?”
2.假死后控制台无法重启
3.控制台监控不准确,使用者无法准确选择
4.1.2版本释放连接逻辑bug
主因是内部某服务突然建立了大量连接,进而引发的故障。
开发阶段把更多的重点放在功能实现和业务迭代上,而忽略了基础设施的可扩展性。这可能会造成短期内的业务顺利进行,但长期看来,如果基础设施不能跟上业务的发展,最终可能会形成技术债务,导致在运维阶段遇到无法解决或者处理复杂度高的问题。
云服务提供商的SLA(服务等级协议)是我们选择使用其服务的一个重要依据,但是是否100%信任SLA,我们需要结合自身的业务情况和对服务提供商的了解来决定。在应急情况下,我们可能需要更具备自主的故障应对能力,而不是完全依赖服务提供商的SLA。
在对内部OS部门优化的过程中发现,服务器整体利用率很好,编译时可以将服务器所有线程打满,唯一掉链子的时候是解压缩unzip环节,只有单线程升高。简单了解了下,原来已经有了多线程的pigz工具,格式做一些微调即可。详细评测https://zhuanlan.zhihu.com/p/389817246
在翻看docker源码时,发现也会将pigz等压缩工具优先
chatGPT火爆IT圈已经几个星期了,仿佛没用过就被时代所抛弃。了解后发现,使用门槛还是挺高,需要使用海外的手机号注册openai,常见的“机场”都会被屏蔽。偶然发现接口在国内是可以访问的
接下来的事就很简单了,使用django起了个页面,调用接口就可以了,供内网体验
有效代码12行
import openai
openai.api_key = "sk-od9TZTgXar70JLTxf4K1T3BlbkFJlcQjxxxxx"
response = openai.Completion.create(
engine="text-davinci-003", # select model
prompt="人生的意义何在?",
max_tokens=512, # response tokens
temperature=1, # diversity related
top_p=0.75, # diversity related
n=1, # num of response
)
completed_text = response["choices"][0]["text"]
print(completed_text)
需求描述:对某一地址,公司网络解析至172.16.1.1,外部解析到1.1.1.1
现状:公司内无单独的DNS服务器,DHCP分配上海公共DNS 202.96.209.5/133
过程:
云解析是通过识别LOCALDNS的出口IP,来判断访问者来源。
如客户端LOCALDNS支持EDNS
因为云解析DNS支持 edns-client-subnet,所以在获取访问者来源IP时,优先获取 edns-client-subnet 扩展里携带的IP ,如果edns-client-subnet 扩展里存在IP,云解析DNS会以该IP来判断访问者的地理位置 ;如果不存在,则以LocalDNS出口ip来判断访问者的地理位置。
dig +short TXT whoami.ds.akahelp.net
不错的办法,但我的DNS出口IP带ipv6,测试下来不生效