It seems there is a post process that escape the backslash character. So the final stop sequence produces is incorrect.
Bug Summary:
It seems there is a post process that escape the backslash character. So the final stop sequence produces is incorrect.
Steps to Reproduce:
I am using VLLM Backend.
Open any model, and set stop token on every line break, example set: \n
Expected Behavior:
Stop token should be stay \n instead of becoming \\n
Actual Behavior:
The stop token shown in my inspection is escaped and added another backslash prefix.
Environment
Open WebUI Version: v0.1.121
Ollama Version 0.1.32
Operating System: POP OS 22.04]
Browser (if applicable): Chrome Version 123.0.6312.105 (Official Build) (64-bit)
Reproduction Details
I am using VLLM Backend.
Open any model, and set stop token on every line break, example set: \n
Confirmation:
I have read and followed all the instructions provided in the README.md.
I am on the latest version of both Open WebUI and Ollama.
I have included the browser console logs.
I have included the Docker container logs.
Logs and Screenshots
As we can see the system prompt has no problem handling line break into \n
But the stop sequence becomes \\n instead of just \n
Installation Method
Docker Method
Originally created by @ibndias on GitHub (Apr 25, 2024).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/1747
# Bug Report
Stop Sequence with Backslash '\' Does Not Work
## Description
It seems there is a post process that escape the backslash character. So the final stop sequence produces is incorrect.
**Bug Summary:**
It seems there is a post process that escape the backslash character. So the final stop sequence produces is incorrect.
**Steps to Reproduce:**
I am using VLLM Backend.
Open any model, and set stop token on every line break, example set: `\n`
**Expected Behavior:**
Stop token should be stay `\n` instead of becoming `\\n`
**Actual Behavior:**
The stop token shown in my inspection is escaped and added another backslash prefix.
## Environment
- **Open WebUI Version:** v0.1.121
Ollama Version 0.1.32
- **Operating System:** POP OS 22.04]
- **Browser (if applicable):** Chrome Version 123.0.6312.105 (Official Build) (64-bit)
## Reproduction Details
I am using VLLM Backend.
Open any model, and set stop token on every line break, example set: `\n`
**Confirmation:**
- [x] I have read and followed all the instructions provided in the README.md.
- [x] I am on the latest version of both Open WebUI and Ollama.
- [x] I have included the browser console logs.
- [ ] I have included the Docker container logs.
## Logs and Screenshots
As we can see the system prompt has no problem handling line break into `\n`
But the stop sequence becomes `\\n` instead of just `\n`
## Installation Method
Docker Method
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @ibndias on GitHub (Apr 25, 2024).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/1747
Bug Report
Stop Sequence with Backslash '' Does Not Work
Description
It seems there is a post process that escape the backslash character. So the final stop sequence produces is incorrect.
Bug Summary:
It seems there is a post process that escape the backslash character. So the final stop sequence produces is incorrect.
Steps to Reproduce:
I am using VLLM Backend.
Open any model, and set stop token on every line break, example set:
\nExpected Behavior:
Stop token should be stay
\ninstead of becoming\\nActual Behavior:
The stop token shown in my inspection is escaped and added another backslash prefix.
Environment
Ollama Version 0.1.32
Reproduction Details
I am using VLLM Backend.
Open any model, and set stop token on every line break, example set:
\nConfirmation:
Logs and Screenshots
As we can see the system prompt has no problem handling line break into
\nBut the stop sequence becomes
\\ninstead of just\nInstallation Method
Docker Method
@tjbck commented on GitHub (Apr 27, 2024):
Taking a look!
@tjbck commented on GitHub (Apr 28, 2024):
Should be fixed on our dev branch, let me know if the issue persists!