Teng Tu

输出Markdown

5

- [x] 尽可能地复用了原始的UI - [x] 生成.md文件 - [x] 下载保存的文件 - [ ] 足够多的测试以保证各个平台的可用性： - [x] Window - [x] Linux, MacOS - [ ] Docker - [ ] HuggingFace

Merge To tt/argparse

4

相比于 @Keldos-Li 帮忙merge的版本，解决了一些bug 该PR的主要更改： ```python parser.add_argument("--authentication", type=bool, default=False, help="是否开启登录") parser.add_argument("--input_key", type=bool, default=True, help="是否由用户输入API-Key") parser.add_argument("--share", type=bool, default=False, help="是否创建gradio公开链接") parser.add_argument("--use_stream", type=int, default=2, choices=[0, 1, 2], help="0一次性返回答案，1实时传输回答，2在ui中增加传输模式选项") parser.add_argument("--timeout_all", type=int, default=200, help="非流式对话时的超时时间") parser.add_argument("--max_token_all", type=int,...

前置总结，保留最近的对话

1

**仅讨论该PR是否有必要，目前仅经过了简单测试，不着急merge** 很多Issue里都提到了一些关于token超出上限的特殊情况，因此这里给出另一套实现思路： - 在predict函数中，首先统计history的长度，如果history超出某一个上限~3000，那么先行进行精简 - 非流式地生成精简结果后，从头扫描一遍history，直到token达到~2000，删除这部分history，并以固定地Prompt替换： user：[ChatGPT刚刚给出的结果]（刚刚我们谈到了……），你了解了吗？ assistant: 我了解了。 user: [原来的2000~3000聊天内容] 相比原来的实现，具有以下优势： - 更加稳定，当前情况下，是在生成后再精简，如果用户本段token太长，除非用户先手动精简，否则将在触发一次“error”后被动地触发精简，用户体验差。 - 精简必将损失一些信息，用户对于最近的信息的精确性要求比聊天最开始的信息精确性要求更高 - 利于用户继续进行追问，否则上一条信息中的细节将因精简而消失，且由于该精简为被动触发，用户完全没有机会避免。 具体实现在utils.py 的以下函数中： ``` def silent_summarize(openai_api_key, system_prompt, history, temperature, top_p, selected_model, all_token_counts) ```

A Fork request

23

I have no development experience in the open source community before, so I don't dare to make trouble for you. I forked the project and made some changes to it...

接受多张图片作为输入

1

InstructBLIP 论文中指出，即使他们没有针对视频进行训练和微调，他们在VideoQA测试集上，将Video切帧后直接拼接输入Q-Former，亦有一定的理解能力。想问VisualGLM是否进行过类似实验？