sillsdev / sillsdev/silnlp

Can we reliably improve the output of Back Translations by sending the drafts to an LLM for correction.

Open
#576 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

research
Dominant language
Python
Stars
39
Forks
7
Avg merge
1d 9h
Merged PRs (30d)
5

Description

We could try a prompt like this, where language is the language of the Back Translation.

Prompt:
"You are a Bible editor. The text below is marked up with USFM and I would like some minimal corrections made.
Please fix only the following errors:

  1. The names of people and places. (e.g. Ensure that the biblical names match common translations)
  2. Factual errors (e.g., if wrong person is identified as author)
  3. Missing or incorrect key theological terms.
    Do not make any changes to:
  4. The language style.
  5. Vocabulary choices unless clearly wrong.
  6. The explanatory notes that are in parentheses.
  7. The USFM markup and layout
    Make only necessary corrections and keep everything else unchanged."

We could also ask the LLM to mark changes and offer examples in the prompts.
"For all changes add # marks around the incorrect part and { } around the correction. Here are examples of markup:

Input:
\v 4 When the \nd Lord\nd* saw that he had gone over to look, God called to him from within the bush, “Peter! Peter!”
Output:
\v 4 When the \nd Lord\nd* saw that he had gone over to look, God called to him from within the bush, “#Peter#{Moses}! #Peter#{Moses}!”

This relies on the LLM knowing the correct name and obviously has the downside that it might correct some names that are incorrect in the translation. There's a tradeoff. The better the output of the AI drafting the less need there is for further correction. This might be useful where names or numbers are very poor in the draft.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or entry points are named. Start by identifying where back translations are produced and how USFM is preserved, then evaluate an LLM correction flow against the listed limits on names, factual errors, theological terms, markup, and change marking.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
machine-learning
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.