自然语言查询、分析数据(NL-TO-SQL)的尝试
让查数据这件事,不再是高高在上、遥不可及的技能,而是人人都能玩得转,妙趣横生的小技巧。比如“我的店上周赚了多少钱?哪个商品即将售罄?这个月卖的最多的商品是啥?”,下一秒,答案就像变魔术一样蹦出来。直接看效果
流程如下,
- 前端使用gradio,采集麦克风声音
- 后端收到声音,使用openai的speech-to-text
- 文字通过dbgpt(链接各种自定义模型),转换为sql进行数据库查询
- 返回对应数据
关键代码
让查数据这件事,不再是高高在上、遥不可及的技能,而是人人都能玩得转,妙趣横生的小技巧。比如“我的店上周赚了多少钱?哪个商品即将售罄?这个月卖的最多的商品是啥?”,下一秒,答案就像变魔术一样蹦出来。直接看效果
流程如下,
关键代码
需求如下,产品团队高频要求翻译团队给出符合标准的翻译件,比如翻译产品文档,其中又有大量的术语,比如3D结构光、扫码头、主屏、客显屏、立式等(在公司内有统一的标准叫法),使用市面通用的翻译产品需要自己修改。看效果
原理如图
openai负责文档Retrieval,flowise负责功能补充,同时做了一次封装,gradio负责提供展示页面,方便用户交互
gradio_run.py
import gradio as gr
import requests
import json
def call_api(question):
url = "https://xxxx.com/api/v1/prediction/asdasce1-5a7b-4d9e-9ed6-21a9aaaab2"
headers = {"Content-Type": "application/json"}
data = {"question": question}
response = requests.post(url, headers=headers, data=json.dumps(data))
return response.json().get("text", "No response text found.")
iface = gr.Interface(
fn=call_api,
inputs="text",
outputs="text",
)
iface.launch()
一直有个需求,企业内私有知识库RAG,“陪产假怎么申请?”,“公司发票抬头是啥?”等问题,解放行政、人事的部分人力。偶然发现钉钉“智能员工”非常契合。零代码开发、配置简单。看效果,支持单聊群聊。目前免费!
配置方式,登录钉钉开发者-数字员工,类似flowise编辑langchain的每个环节,别担心,有模板只需要简单修改!在知识库贴钉文档的链接。文档准备需要注意以下几点
产品名: No English - 不学英语 https://chat.openai.com/g/g-kkrKOWa1E-no-english
产品概览: No English - 您的个人化英语学习伙伴
产品定位:
在语言学习的长河中,No English 站在了技术与教育的交汇点,提供了一个创新的、用户友好的英语学习解决方案。我们的平台运用最新的人工智能技术,致力于提升英语学习效率,同时保持学习过程的趣味性和参与度。
核心功能:
知识资源库:
No English 配备了一系列的英语学习文件,涵盖商务英语和各类英语测试标准,如TEM-8、CET-4和CET-6,可供用户根据个人需要下载并学习。
技术能力:
用户动作与互动:
用户询问当日新闻时,会从指定接口请求,本app使用京东的汇聚新闻接口。
使用推荐:
No English 针对希望在移动设备上学习的用户进行了优化设计,特别推荐使用手机应用来体验我们的语音互动特性,这能够为用户提供更加沉浸式的学习环境。 手机端前两天还支持,现在已经不行了
相信大家或多或少体验过大模型的魅力,有一定门槛的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")
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
😅未验证,原理可行- -
在对内部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,测试下来不生效
一、一直自诩是柔性的管理者,讲情怀、谈感情、不涉及原则问题都是友善提醒。谈谈近期遇到的一位伙伴小王,他是一个月前加入,原本负责网络的同学匆忙离开。积压的问题越来越多,小王在上手之后不太能搞定,我经常提醒不要成为“沟通黑洞”,发包过去一声不吭。无奈,离开
二、会议效率降低怪象
对待故障要敬畏,要追根因。惩罚机制要恰到好处,避免大家不敢动,更应该把故障看成一份宝贵的经验包;对待历史问题不逃避。我反对把责任甩的一干二净。
正因为我这种“大包大揽”的责任感,质量部门经常莫名其妙定责给我。前天一次故障,其部门自行维护的服务单点宕机,事故前多次反复提醒仍不整改。坑惨一波又一波接任者
三、越来越像项目经理,技术上已得不到成长,离我的“专家”目标渐远
遇到一种场景,某前端服务部署在kubernetes中,有偶发的服务故障。想着健康探针重启就行,忽然想到,如果是重要的线上服务宕机,不查出来心里憋得慌,怎么让服务恢复的同时又能保留现场呢
改当前pod的标签,这样deployment会认为副本消失,自动创建。完美实现老容器保留,业务也及时恢复
kong中默认有安全插件,黑白名单限流等,限制UA暂时没找到。可以自己开发一个
-- handler.lua
local BasePlugin = require "kong.plugins.base_plugin"
local MyPluginHandler = BasePlugin:extend()
MyPluginHandler.VERSION = "1.0.0"
MyPluginHandler.PRIORITY = 10
function MyPluginHandler:new()
MyPluginHandler.super.new(self, "block-user-agent")
end
function MyPluginHandler:access(conf)
MyPluginHandler.super.access(self)
-- 检查 User-Agent 请求头
local user_agent = kong.request.get_header("User-Agent")
for i, ua in ipairs(conf.blocked_user_agents) do
if user_agent == ua then
-- 如果 User-Agent 被阻止,使用 kong.response.exit 返回响应并停止处理
return kong.response.exit(conf.response_code, { message = conf.response_message })
end
end
end
-- schema.lua
local typedefs = require "kong.db.schema.typedefs"
return {
name = "block-user-agent",
fields = {
{ consumer = typedefs.no_consumer },
{ config = {
type = "record",
fields = {
{ blocked_user_agents = { type = "array", default = {}, elements = { type = "string", }, }, },
{ response_code = { type = "number", default = 403 }, },
{ response_message = { type = "string", default = "Forbidden" }, },
},
},
},
},
}
docker启动时注意修改kong/constants.lua,在插件底部加入UA_block
docker stop kong-gateway
docker rm kong-gateway
docker run -d --name kong-gateway \
--network=kong-net \
-e "KONG_DATABASE=postgres" \
-e "KONG_PG_HOST=kong-database" \
-e "KONG_PG_USER=kong" \
-e "KONG_PG_PASSWORD=kongpass" \
-e "KONG_PROXY_ACCESS_LOG=/dev/stdout" \
-e "KONG_ADMIN_ACCESS_LOG=/dev/stdout" \
-e "KONG_PROXY_ERROR_LOG=/dev/stderr" \
-e "KONG_ADMIN_ERROR_LOG=/dev/stderr" \
-e "KONG_ADMIN_LISTEN=0.0.0.0:8001" \
-e "KONG_ADMIN_GUI_URL=http://localhost:8002" \
-v /data/UA-block:/usr/local/share/lua/5.1/kong/plugins/UA-block \
-v /data/constants.lua:/usr/local/share/lua/5.1/kong/constants.lua \
-p 8000:8000 \
-p 8443:8443 \
-p 8001:8001 \
-p 8444:8444 \
-p 8002:8002 \
-p 8445:8445 \
-p 8003:8003 \
-p 8004:8004 \
kong/kong-gateway:2.6.1.0-alpine
近一周安全问题频发,明显是针对性的精准渗透行为,钓鱼邮件、ERP服务器被拿下、线上kubernetes集群被拿到部分权限成功部署反弹shell。从入侵轨迹来看,未做破坏但有明显的扫描内网行为,对方对安全、运维都有比较深入的了解。与政府组织的“磐石行动”时间点吻合,推测是对我们的白帽行为
云安全中心提醒还是很精准的,以容器中被运行反弹shell为例。从kubernetes审计日志,“黑客”使用被泄露账号通过暴露在公网的k8s api server进来,在进行了一系列尝试后发现有A命名空间的管理权限,具有onl的namespace 权限,查看了cm发现免密登陆,推送镜像,创建deployment ,镜像中传输数据。已关服务,wifi api server取消外网监听
过程中用到的命令
pstree -p -a #查看
docker inspect #查看pod信息
docker run -it --entrypoint /bin/sh xxxxx #启动疑似容器
查看kubernetes 审计日志
kubernetes get rolebinding -n xxx -o yaml
最新战报:
内部员工已中招,对方社工客服运行了可执行文件,导致在OA内向其他用户发送病毒文件
ERP服务器沦陷,有扫描内网的行为
CRM服务器中毒
🏳️
在家隔离的2个多月,重新捡起了运维开发工作
已实现or改进:
待实现or改进
附几张效果图
今天在排错时遇到个奇怪的现象,相同名称添加多条A记录超过512字节时,就会影响部分递归DNS的记录同步。
测试域名 liyang.sunmi.com 添加了36条A记录,大小610字节
必现部分递归DNS无法更新、解析失败
1.查阅了DNS的RFC1035,udp包有512字节的长度限制,超出部份会被截断 原文
2.超过限制后使用tcp协议进行解析
3.公共DNS中,只有114.114.114.114会把超长结果截断在509字节,其他DNS都会原样返回
近期接到个古怪需求,历史原因有部分设备在代码中访问废弃接口uat.api.xxx.com,现有接口为 api.uat.xxx.com(顺序变化)。老设备升级rom版本较繁琐,网关不想动了,在外侧加了台nginx转发
# 通过rewrite301跳转
server {
listen 80;
server_name uat.api.xxx.com;
location / {
root /usr/share/nginx/html;
if ( $host ~* uat.api.xxx.com ){
rewrite .* http://api.uat.xxx.com$request_uri permanent;
}
}
}
# 方法2
在location中加,更优
proxy_set_header Host api.uat.xxx.com;
proxy_pass https://api.uat.xxx.com;
背景:海外用户投诉我们一个边缘功能失效,定位到程序假死。随着各种复盘会,把这件小事无限放大。
难点:探针改造复杂,尽管已经有了基础的http接口检测,但针对服务连接各种中间件等场景无法一一覆盖
在研发根治此问题前,使用“熔断”来降低此类故障的影响
熔断,是创建弹性微服务应用程序的重要模式。熔断能够使您的应用程序具备应对来自故障、潜在峰值和其他未知网络因素影响的能力
中间方案,通过网关日志,假死会有504超时的信息,SLS已支持触发各种钩子,逐个重启故障服务的pod
更优istio方案,使用VirtualService配合DestinationRule对超时或者错误重试,并将故障pod踢出
环境:
from flask import Flask
import time
app = Flask(__name__)
@app.route("/", methods=["GET"])
def index():
time.sleep(5)
return "Hello World Pyvo 2!"
istio中配置如下
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: backend-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: vs-backend-flask
spec:
hosts:
- "*"
gateways:
- backend-gateway
http:
- match:
- uri:
prefix: /flask
rewrite:
uri: /
route:
- destination:
host: backend-flask
port:
number: 80
retries:
attempts: 3
perTryTimeout: 2s
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: dr-backend-flask
spec:
host: backend-flask
trafficPolicy:
outlierDetection:
consecutive5xxErrors: 1
interval: 10s
baseEjectionTime: 30s
效果如图,访问出现上游服务超时错误后,在30秒内不会再调度到故障节点